Advanced Bio-Linux Dan Swan Setting up your printer

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) – Jet. Direct 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 - Jet. Direct • Most people we deal with are attempting to set up Jet. Direct 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/issue 59/nazario. htm l

Log files not to stress about • • • /var/log/gdm : gdm is the graphical login manager. • • /var/log/spooler : UUCP spools (no-one uses this anymore!) /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 My. SQL you might look! /var/log/pgsql : Postgre. SQL logs - as above. /var/log/rcd/* : Red. Carpet 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/up 2 date : Red. Hat update mechanism (unused). /var/log/wtmp : not human readable /var/log/Xfree 86. 0. log : If you have X errors this is the place to look.

What is with the. 1 files? • The first thing you notice about /var/log/ files is that you have – 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. 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. • 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.

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.

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 Bio-Linux 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.

RULE 1 • • • PICK GOOD PASSWORDS! • 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 re-use that password across multiple machines/accounts - you're technically 'owned'. • r 4 inb 0 w is not a good password, it is based on well known number/letter substitutions and does not mix case. • A good password is Ls 1 Tm. Il 1 L (Linux security 1 s The most Important lesson 1 Learned). 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.

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 post-it 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.

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 (anti-hacker measure), random (makes random numbers), rawdevices (for support of raw devices), rcd (red carpet updates), rhnsd (Red. Hat updates), sendmail (mail), sgi_fam (monitors file alterations), sshd (secure shell), syslog (logs system events), wine (windows compatibility layer), xfs (X windows font server).

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 -s. T localhost

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.

Take home message • To the casual observer Bio-Linux 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 My. SQL 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 X-windows, printer, smtp etc means they are not available for exploitation by hackers. • The question is - how is this all done?

Narc firewalls • Bio-Linux 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. conf • Narc is run at boot to generate iptables rules based on the conf. • If you want to make firewall changes edit narc. conf.

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 'portsentry'. • 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. blocked. atcp

• Portsentry is

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 Bio-Linux 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 re-used 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.

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 'ftp-like' 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 X-Windows connections! • We use Open. SSH a non-commercial implementation of SSH. • sshd (the program which allows you to connect to Bio-Linux via ssh) is the only point of entry to the Bio-Linux system and is currently considered secure.

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/Security-HOWTO/ • 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.