Advanced BioLinux

(1)

Environmental Genomics Thematic Programme Data Centre

http://envgen.nox.ac.uk

Advanced BioLinux

Dan Swan: Setting up your printer

(2)

Setting up the printer

• This process is known to be problematic for some people.

• There are 5 main types of printer:

– local (attached to the physical machine) – UNIX networked printer (lpd)

– Windows networked printer (SAMBA) – Novell networked printer (NCP)

– JetDirect networked printer (HP)

• It is important to determine which one you are using before you set it up! If the machine is connected via ethernet cable to a

network point it probably has an IP address. Make sure you

know it, and the correct model number of the printer.

(3)

Step by step JetDirect

• Most people we deal with are attempting to set up JetDirect printers attached to a LAN with an IP address.

• sudo printconf-gui

• “New”

• Follow the onscreen instructions!

• Queue name can be anything

• Printer IP: 192.171.160.227

• You must use the “Raw Print Queue” trust us that this works better than selecting a printer driver. YMMV with other printer setups. If you have trouble that your local IT staff can' t aid with contact the helpdesk and we will try and troubleshoot it.

• Print a postscript test page from the “Test” menu.

(4)

Advanced BioLinux

Dan Swan: Log files and log monitoring

(5)

What, where and why?

• Log files are files of ' useful' information that are written in an ongoing fashion by various programs on the system.

• Most (but not all) logs are stored in /var/log/

• Apache (webserver logs) are stored in /etc/httpd/logs/

• Logs are your first port of call for detecting things like upcoming hardware issues (such as disk drive failure), accounting visits (hits) on the webserver, detection of intrusion attempts,

detection of intrusions.

• Going over the log files is good practice, but for an inexperienced admin making sense of them is not always straightforward.

• We will try to demistify some of this process and show you how

to automate it.

(6)

Apache logs

(7)

Why check these logs?

• If you have opened up your web server to the outside world it will be probed by hackers. Apache has had a number of

vulnerabilities in the past but is generally considered to be good in terms of security.

• Things to look out for are huge entries trying to get filenames with thousands of characters these are attempted “buffer

overflow” exploits. Anything which contains more strings

like ../../../../../../../../../ is attempting to locate files outside of an improperly secured Apache set up. Any requests for

executable files, or cgi files that you did not put there are cause for concern.

• You can safely ignore anything looking for .com .exe files, these

are scans for Microsoft IIS vulnerabilities.

(8)

/var/log

• This containst the majority of the log files.

• Each one stores different information.

• It is important to keep an eye on these.

• Some can be viewed with a ' logchecker' to give the administrator essential information.

• It is important that as an administrator you learn to understand the information given in the logs.

• The only way is to look and learn. You will often not understand the entries, use Google to look them up if you are concerned.

• We will go through them one by one briefly.

(9)

(10)

(11)

dmesg

• less /var/log/dmesg

• keeps a log of printed kernel messages.

• Most often this will have information about the boot process, and it should be checked to keep an eye on the actual hardware as it can harbour warnings of upcoming problems.

• Whilst the system is running dmesg will print out any other

kernel messages, and will include items like firewall incidents etc.

• There is a great article demystifying the dmesg output (which can be quite cryptic) here:

• http://www.linuxgazette.com/issue59/nazario.html

(12)

(13)

Log files not to stress about

• /var/log/gdm : gdm is the graphical login manager.

• /var/log/httpd : the same as /etc/httpd/logs/

• /var/log/iptraf : it's empty!

• /var/log/kdm.log : another graphical login manager.

• /var/log/ksyms.* : kernel symbols logs (incomprehensible).

• /var/log/lastlog : Use the last command instead.

• /var/log/mysqld.log : Of course if you start using MySQL you might look!

• /var/log/pgsql : PostgreSQL logs as above.

• /var/log/rcd/* : RedCarpet logs only look if you have issues.

• /var/log/rpmpkgs : Same as running rpm qa

• /var/log/sa : output from sar command on cron job

• /var/log/scrollkeeper.log : GNOME messages, might be good to look at if you have a GNOME problem!

• /var/log/spooler : UUCP spools (noone uses this anymore!)

• /var/log/up2date : RedHat update mechanism (unused).

• /var/log/wtmp : not human readable

• /var/log/Xfree86.0.log : If you have X errors this is the place to look.

(14)

(15)

(16)

(17)

What is with the .1 files?

• The first thing you notice about /var/log/ files is that you have – file

– file.1

– file.2 etc.

• This is because logs are rotated weekly to make sure they do not clog up the disk.

• Rotation is handled by logrotate.sh in /etc/cron/cron.daily

• Each week file is moved to file.1, file.1 to file.2 etc. and file.4 is deleted as we work a 4 week cycle of logs.

• You can alter the behaviour of logrotate in /etc/logrotate.conf

(18)

Automated log checking

• Currently BioLinux machines are set to email the EGTDC your logs. Now you are all advanced users :) you can take the

responsibility for your own log checking. We wil advise you how to do this later.

• Log checking is done by a program called logcheck.sh

appropriately! This is run as a daily cron job and the results emailed to the defined manager. Currently this is channelled to the EGTDC account and forwarded to us. In future this should be sent to the manager account.

• This tries to pick out the most obvious security problems and

report them, although it still reports a lot of false positives it is

imperative you watch this file for curious actions on the system.

(19)

Advanced BioLinux

Dan Swan: Linux Security 101

(20)

Why care about security?

• Any machine on the internet is vulnerable to attack from a malicious individual.

• It doesn' t matter what OS the machine is running, how fast the computer is, if it' s a desktop or a mainframe, a good hacker will find a use for it.

• Your data is stored on these machines. Work data and personal data.

• You do not wish to compromise your personal security, nor jeapordise the integrity of your binary data.

• Anyone attempting to hack your machine is already lacking

scruples, so don' t expect them to play nice if they get in.

(21)

Why do people hack?

• There are three main types of hackers:

– The 'elite' a few individuals you simply are not going to stop.

Fortunately for you they're probably more interested in banks, oil

companies, governments and big business to worry about getting into your machine. They have a deep knowledge of network technologies and internet protocols.

– The 'curious' for who hacking machines is an intellectual challenge and the misappropriation of data is not a big pull. Many of these will be part of the 'white hat' community.

– The 'script kiddies' This is by far and away the largest and most active group of hackers. They leech from the curious and elite hackers and wantonly rip their way through the internet with little skill, and no idea exactly how they are doing it. They are most likely to be found on IRC bragging about their latest exploits. They are very dangerous simply because they are the most likely to cause data loss.

(22)

The sysadmin vs the hacker

• Some hackers see the fight as a challenge. They pit their latest techniques in intrusion of computer systems against the latest preventative measures of the worlds sysadmins. It becomes a game.

• There are some simple rules to follow to maintain the integrity of your machine.

• We have tried to make BioLinux as secure as possible.

• Any changes you make to the system have the potential to compromise the security of the machine.

• Think about what you are doing when you use the machine. Try

to develop some idea of what the hacker is thinking.

(23)

RULE 1

• PICK GOOD PASSWORDS!

• Why?

• Scenario 1: A computer hacker breaks into your machine and steals the

password file (/etc/password and /etc/shadow) as well as a list of machines that you have recently accessed.

• Using a dictionary based approach a hacker can test every word in a

dictionary against your stolen password file. If your password is 'rainbow' and being human, you reuse that password across multiple

machines/accounts you're technically 'owned'.

• r4inb0w is not a good password, it is based on well known number/letter substitutions and does not mix case.

• A good password is Ls1TmIl1L (Linux security 1s The most Important lesson 1 Learned).

(24)

Rules 2 and 3

• Change your password frequently. Once a month should do it.

Get into the habit of doing this on all systems you have accounts on, this is maximising your personal security.

• Never write your password down or give your password out. No postit notes with passwords stuck to your monitor, if a hacker was to visit your institution one day it might be the kind of thing they would pay attention to. You do not divulge it to your

friends, family, colleagues. If you can't remain tight lipped about

your passwords, you can' t expect them to either.

(25)

Rule 4

• Don't run unnecessary services on your machine.

• sudo /usr/sbin/setup

• Services running are: atd (handles timed commands), autofs (so you can mount NFS at boot), crond (already discussed), gpm (mouse services), ip(chains|tables) (firewalls), keytable (loads local keyboard settings and default font), kudzu (hardware

detection), lpd (printing), mysqld (database), network (network interface control), portsentry (antihacker measure), random (makes random numbers), rawdevices (for support of raw devices), rcd (red carpet updates), rhnsd (RedHat updates),

sendmail (mail), sgi_fam (monitors file alterations), sshd (secure

shell), syslog (logs system events), wine (windows compatibility

layer), xfs (X windows font server).

(26)

Not all services face the internet

• Some of the services are local to the machine. Not all of them present a danger from the point of view of an internet attacker.

• How can you find out what is open to attack on your machine?

• Use the same tools the hackers do! Run nmap against your machine.

• Do not wield this tool in anger, or curiousity against any machine you do not have explicit permission to scan. You will likely

breach the Computer Misuse Act and potentially antiterrorist legislation too.

• nmap -sT localhost

(27)

(28)

(29)

Getting sneaky with nmap

• With nmap we can do a lot more interesting things with

machines that appear to be down, or are blocking our probes.

(30)

Take home message

• To the casual observer BioLinux does not appear on the network.

• To the determined hacker, the machine only shows an sshd port open. We will discuss sshd in more detail later.

• The upshot of this is that your local MySQL database and your local installation of apache (the webserver) are only available to your local host (localhost/127.0.0.1).

• The hiding of ports such as Xwindows, printer, smtp etc means they are not available for exploitation by hackers.

• The question is how is this all done?

(31)

Narc firewalls

• BioLinux has a built in firewall which allows fine grained control of who can access what on your system.

• Currently the setup is (basically):

– Deny all incoming connections.

– Allow incoming ssh.

• Firewall rules are set up using iptables (or ipchains for older versions of Linux).

• We use Narc to make generating iptables rules simpler.

• Narc configuration is in /etc/narc/narc.conf

• Narc is run at boot to generate iptables rules based on the conf.

• If you want to make firewall changes edit narc.conf .

(32)

Portsentry

• If ever you can' t connect to a machine that you can usuall access, and the machine is not down it may be that someone has run

nmap against the machine from your own machine.

• You have most likely been blocked by 'p ortsentry' .

• If a machine scans you then further attempts to connect to it will be blocked. Permanently.

• If this happens in error:

• /sbin/route (any address with !H as a flag is blocked)

• /sbin/route del <ipaddress> reject

• This can also be checked in:

• /etc/portsentry/portsentry.blocked.atcp

(33)

• Portsentry is

(34)

Rule 5

• You do not set up telnetd or ftpd on the machine.

• In fact if you're really security concious you don't EVER use telnet or ftp to access ANYTHING!

• FTP and telnet are from the days when the internet was a safer place.

Importantly they transmit all their doings in plain text, across the network.

• Example: You are sat on your BioLinux machine and you telnet/ftp to a machine in the USA. Each keystroke passes through dozens of machines, any one of which could be compromised by a hacker, who is monitoring all traffic. You have reused your password on both machines. Hacker intercepts your username and password, sees where you are coming from, logs into your machine and you are owned. Simple.

(35)

Your alternative is SSH

• SSH = secure shell

• Replaces telnet with a secure, 2 way encrypted channel. No plain text is ever passed between the machines.

• SSH also allows file transfer using scp. You can get 'f tplike' scp clients if you really can' t deal with the command line.

• ssh <username>@host

• scp <file> <username>@host:

• ssh is even clever enough to tunnel XWindows connections!

• We use OpenSSH a noncommercial implementation of SSH.

• sshd (the program which allows you to connect to BioLinux via ssh) is the only point of entry to the BioLinux system and is

currently considered secure.

(36)

More security

• To see who is logged onto your system and where from : w

• To see what connections are currently being made to and from your machine : netstat | more

• tail -f /var/log/messages

• (hint try the above and then ssh localhost to see what happens)

• Read:

• http://www.ecst.csuchico.edu/LDP/HOWTO/SecurityHOWTO/

• Don't forget to physically secure the machine. Padlock the case, chain it to a desk. Universities are soft targets for thieves.

• Keep the machine patched and up to date. This, and not fiddling

with the firewall is the best way to keep your machine secure.

(37)

(38)

(39)

(40)

Advanced Bio­Linux

Advanced Bio­Linux

Dan Swan: Setting up your printer

Setting up the printer

• This process is known to be problematic for some people.

• There are 5 main types of printer:

– local (attached to the physical machine) – UNIX networked printer (lpd)

– Windows networked printer (SAMBA) – Novell networked printer (NCP)

– JetDirect networked printer (HP)

• It is important to determine which one you are using before you set it up! If the machine is connected via ethernet cable to a

network point ­ it probably has an IP address. Make sure you

know it, and the correct model number of the printer.

Step by step ­ JetDirect

• Most people we deal with are attempting to set up JetDirect printers ­ attached to a LAN with an IP address.

• sudo printconf-gui

• “New”

• Follow the onscreen instructions!

• Queue name can be anything

• Printer IP: 192.171.160.227

• You must use the “Raw Print Queue” ­ trust us that this works better than selecting a printer driver. YMMV with other printer setups. If you have trouble that your local IT staff can' t aid with contact the helpdesk and we will try and troubleshoot it.

• Print a postscript test page from the “Test” menu.

Advanced Bio­Linux

Dan Swan: Log files and log monitoring

What, where and why?

• Log files are files of ' useful' information that are written in an ongoing fashion by various programs on the system.

• Most (but not all) logs are stored in /var/log/

• Apache (webserver logs) are stored in /etc/httpd/logs/

• Logs are your first port of call for detecting things like upcoming hardware issues (such as disk drive failure), accounting visits (hits) on the webserver, detection of intrusion attempts,

detection of intrusions.

• Going over the log files is good practice, but for an inexperienced admin making sense of them is not always straightforward.

• We will try to demistify some of this process and show you how

to automate it.

Apache logs

Why check these logs?

• If you have opened up your web server to the outside world it will be probed by hackers. Apache has had a number of

vulnerabilities in the past but is generally considered to be good in terms of security.

• Things to look out for are ­ huge entries trying to get filenames with thousands of characters ­ these are attempted “buffer

overflow” exploits. Anything which contains more strings

like ../../../../../../../../../ is attempting to locate files outside of an improperly secured Apache set up. Any requests for

executable files, or cgi files that you did not put there are cause for concern.

• You can safely ignore anything looking for .com .exe files, these

are scans for Microsoft IIS vulnerabilities.

/var/log

• This containst the majority of the log files.

• Each one stores different information.

• It is important to keep an eye on these.

• Some can be viewed with a ' logchecker' to give the administrator essential information.

• It is important that as an administrator you learn to understand the information given in the logs.

• The only way is to look and learn. You will often not understand the entries, use Google to look them up if you are concerned.

• We will go through them one by one briefly.

dmesg

• less /var/log/dmesg

• keeps a log of printed kernel messages.

• Most often this will have information about the boot process, and it should be checked to keep an eye on the actual hardware as it can harbour warnings of upcoming problems.

• Whilst the system is running dmesg will print out any other

kernel messages, and will include items like firewall incidents etc.

• There is a great article demystifying the dmesg output (which can be quite cryptic) here:

• http://www.linuxgazette.com/issue59/nazario.html

Log files not to stress about

What is with the .1 files?

• The first thing you notice about /var/log/ files is that you have – file

– file.1

– file.2 etc.

• This is because logs are rotated weekly to make sure they do not clog up the disk.

• Rotation is handled by logrotate.sh in /etc/cron/cron.daily

• Each week file is moved to file.1, file.1 to file.2 etc. and file.4 is deleted as we work a 4 week cycle of logs.

• You can alter the behaviour of logrotate in /etc/logrotate.conf

Automated log checking

• Currently Bio­Linux machines are set to email the EGTDC your logs. Now you are all advanced users :) you can take the

responsibility for your own log checking. We wil advise you how to do this later.

• Log checking is done by a program called logcheck.sh ­

appropriately! This is run as a daily cron job and the results emailed to the defined manager. Currently this is channelled to the EGTDC account and forwarded to us. In future this should be sent to the manager account.

• This tries to pick out the most obvious security problems and

report them, although it still reports a lot of false positives it is

imperative you watch this file for curious actions on the system.

Advanced Bio­Linux

Dan Swan: Linux Security 101

Why care about security?

• Any machine on the internet is vulnerable to attack from a malicious individual.

• It doesn' t matter what OS the machine is running, how fast the computer is, if it' s a desktop or a mainframe, a good hacker will find a use for it.

Advanced BioLinux

Advanced BioLinux

network point it probably has an IP address. Make sure you

Step by step JetDirect

• Most people we deal with are attempting to set up JetDirect printers attached to a LAN with an IP address.

• You must use the “Raw Print Queue” trust us that this works better than selecting a printer driver. YMMV with other printer setups. If you have trouble that your local IT staff can' t aid with contact the helpdesk and we will try and troubleshoot it.

Advanced BioLinux

• Things to look out for are huge entries trying to get filenames with thousands of characters these are attempted “buffer

• Currently BioLinux machines are set to email the EGTDC your logs. Now you are all advanced users :) you can take the

• Log checking is done by a program called logcheck.sh

Advanced BioLinux

• We have tried to make BioLinux as secure as possible.

• Never write your password down or give your password out. No postit notes with passwords stuck to your monitor, if a hacker was to visit your institution one day it might be the kind of thing they would pay attention to. You do not divulge it to your

detection), lpd (printing), mysqld (database), network (network interface control), portsentry (antihacker measure), random (makes random numbers), rawdevices (for support of raw devices), rcd (red carpet updates), rhnsd (RedHat updates),

breach the Computer Misuse Act and potentially antiterrorist legislation too.

• To the casual observer BioLinux does not appear on the network.

• The hiding of ports such as Xwindows, printer, smtp etc means they are not available for exploitation by hackers.

• The question is how is this all done?

• BioLinux has a built in firewall which allows fine grained control of who can access what on your system.

• SSH also allows file transfer using scp. You can get 'f tplike' scp clients if you really can' t deal with the command line.