Security Tips Ghost_Rider (ghostrider@boxnetwork.net) Written for Blackbox Ezine (http://blackbox.box.sk) Intro ----- While writing this text I'm thinking that you already know how to install linux and you also know the basic commands, in other words I assume that you already know how to mess with linux. If you think this is a step by step document your are wrong, here are given ideas and thoughts that will help you to secure your box. When you end this text you'll have a secure box/network, but, remember that nothing is 100% secure, be paranoid. You won't be treated as a newbie to all this, because I'm assuming you aren't. The only 3 things you need to keep going through: - Brain (I guess there's no problem with this one) - Linux Knowledge - Coffee or something with caffein So let's start this shall we? :) "To protect yourself you need to see your system from the attackers eyes" <-- Your mission Mr. Sysadmin is Securing your box --> ------------------------------------------------------- The first step on securing a box is re-installing your system. Your are probably asking why? Well if we really want to secure a system, we need to have 100% sure that it wasn't compromised before you started implementing security measures, otherwise it can just be a complete waste of time. Lets suppose that you have just finished installing again your favorite linux distro, and you are ready to secure it. Selecting services ------------------ Log in as root. First thing is to check what daemons are running as default, we can use netstat for that. # netstat -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:ftp *:* LISTEN tcp 0 0 *:ssh *:* LISTEN tcp 0 0 *:telnet *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 *:finger *:* LISTEN tcp 0 0 *:www-http *:* LISTEN tcp 0 0 *:pop3 *:* LISTEN tcp 0 0 *:shell *:* LISTEN raw 0 0 *:icmp *:* 7 raw 0 0 *:tcp *:* 7 # Well for what I'm checking I can tell that this is a newbie linux version, probably RedHat or Mandrake. Why do I say that? Because those distros come with plenty of active daemons, this way if the user need it don't need to try to configure it. Unfortunately the default configurations aren't what we can call secure so let's get working. Finger and shell daemons should be shuted ASAP. Why? - Finger daemon gives away info to everyyone that requests it, even if it's not much, it gives valid usernames for brute force attempts. - Shell daemon, is one of the so called the r* services, the characteristic in all of this services is that no authentification is needed. It's all based in trusted host. If you still wanna run those be sure you set kerberos identification. - r* services running without kerberos oor any other kind of auth method: There's a file (.rhosts) where the trusted IPs are and if the IP trying to login matches with the ones of the file, you get access to the box. So an IP Spoffing attack would do the job, and you would get your box in trouble. Now we still have the following services running: - ftp (File Transfer Protocol) - ssh (Secure Shell) - telnet (actually this one should also be shuted after all we have ssh) - smtp (Simple Mail Transfer Protocol) - www-http (Web server) - pop3 (Post Office Protocol 3) Now you have to ask yourself a question. What do I pretend to do with my box? - If you want to do a shell provider, yoou probably want to leave ftp daemon so users can upload things to their shells, ssh open, and unfortunately telnet too because there are many people (mostly windows users wanting to get a *nix shell) that don't know what ssh is and don't have clients for it. - If you want a mail server, you probablly would close every port besides smtp, and pop3. NOTE: If the smtp daemon that you are using is sendmail, check if it's the latest version, actually you should do this with every daemon, but specially with sendmail. Why? Well because sendmail daemon is a massive coding with over 80.000 lines of code. So as you can imagine it's heaven for exploit writers. In the past there actually was the joke "So what's this week sendmail vulnerability?". If you really need a smtp daemon also think in changing from sendmail to qmail (www.qmail.org). - If you want a web server you should leeave www-httpd daemon and ftp daemon. Or even better if you have physical access to the web server and you can access it regurally shut the ftp daemon too, and when there's need to upload things just log locally. - If you want a standalone box, just forr you why not to close every single port you have. But let's say that you want to play around in your box trying to exploit the services, but you don't want nobody to access them besides you, so it's still a standalone box but for everyone else besides you. The solution is to set a firewall with deny policy, we'll have a little discussion about that later. WHAT YOU ALREADY SHOULD NOW: To open/close ports you need to edit the file /etc/inetd.conf. If the service you wanna close isn't listed there check init scripts that can be found in the /etc/rc.d directory or /etc/init.d deppend on what initialization system your distro uses. IMPORTANT: Remember it's really important that you will ALWAYS running the latest daemons versions. Subscribe BugTraq mailing list (http://www.securityfocus.com) to know about the latest exploits and patches. If deamons allow, drop user permissions to normal users that just own that deamon. Create new users for each deamon you are running. Avoiding to get in trouble -------------------------- Well in the last section I gave 4 examples of what you could want to make with your box: - shell provider - Mail server - Web server - Standalone box Well in this section the standalone option won't be discussed by obvious reasons. Let's first see what measures we could take about in the shell provider. Shell provider -------------- In this kind of server you'll have plenty of people around the server, probably even giving passwords to friends for their shells, it can be a really dark environment for the sysadmin. Services Running: - FTP - SSH - TELNET Tips: - Do not allow root to login remotely - Remove, or at least change passwords from default accounts. - Do not allow anonymous ftp users to login, nor root, nor any user has to much power to login by ftp, bin, daemon, and other pseudo users from root. - Check all files with SUID bit, and check their man page, if they say that they can run without SUID bit just take it out. Files like at, mount, umount should always be without the SUID bit..If they have it in your system just take it out - Chroot() user in is own home directory when login by ftp. - Use shadow passwords - Delete su from your system and get sudo instead, if you really want to be secure or your the only sysadmin remove both - Don't allow normal users to use commands like, mount, umount, uname, netstat, w, who, and others that can give some kind of info from your machine not actually needed - Use npasswd instead of passwd, or use vpass with passwd - Install Crack (remember to set permission to rwx------) and once a week run a check in passwords of your system. Remember that it can take hours or even days if your system as many users, but you also have to remember that it can make your box secure. Set cron to run it and report by mail. - If you want secure passwords, and crypt() accepts long passwords use ppgen (password generator) that will generate passwords for users, instead of being them to give passwords - Warn users about possible social engineer attacks. - Make users change their pass often - Always display something like "This host logs everything you do, break in attempts will be punished by law" at the login prompt and motd. It's always good to do this, it won't secure your box but might put some script kiddie think twice. URLs: sudo (ftp://ftp.courtesan.com/pub/sudo/) npasswd (ftp://ftp.cc.utexas.edu/pub/npasswd/) ppgen (ftp://coast.cd.purdue.edu/pub/tolls/unix/ppgen/) crack (http://www.users.dircon.co.uk/~crypto/) Mail server ----------- Actually we can think that this kind of servers won't be in such danger as a Shell provider, but that's not true, a Mail server is sometimes in MORE danger that a shell provider. Why? Well because sendmail daemon is really buggy, POP3 can be brute forced to get passwords from users, and even if this host doesn't allow any kind of remote login, the passwords of the users should be the same in other hosts of the same network right? So you starting to imagine a chaos environment, that's good, your opening your eyes to the reality. Services Running: - SMTP - POP3 Tips: - Give a try with qmail daemon instead oof sendmail one. - Check if the commands vrfy and expn, tthey probably are, but if they aren't disable them. - In POP3, if possible, set lock accountt so that if in an amount of time there's a large number of failed login attempts. Remember to get an auto-unlock mechanism too, something like, after 30 minutes unlock account. If there's no such option you can alway login into the account that is being attack, and nobody can login again until you logout (I'm are talking about pop3 login). Web server ---------- Web servers are the ones that are most attack by script kiddies, everything they wanna do is their "31337 defacings" saying things like "I 0wN yOuR AsS bItCh", using exploits gotten from bugtraq which they have no fucking clue on what they do. For the Web Server this kiddiots are one of the biggest danger, but remember they will just sucefull if you are lazy and don't upgrade and patch holes otherwise they don't have a clue on what to do. Still there's always the dark cenario of a DoS attack comming for a kiddie that is almost crying because after trying the 1000 exploit he had that hadn't nothing to do with services running he didn't manage to crack security. Solution --> FIREWALL Services running: - www-http - ftp (most of the times) IMPORTANT: If you have a web server with ftp daemon and you let people people upload to a world writable directory, REMEMBER chroot() ftp and chroot() http IN DIFFERENT DIRECTORIES, that can't be accessible each other. Otherwise scripts can be uploaded to root your server. Tips: - If you use CGI scripts check if you doon't have vulnerable CGI scripts, if you have them delete them. - If using a world writable ftp directorry like /incoming check it reguraly, like each 3 days, or each week, don't get it more than 1 week, after that period of time delete everything in that directory, if some package should be preserved change them to a dir where only you can write and other can just read. If you don't do this your server will become the newest warez spot, in the place, in no time. - Never run http daemon as root, you proobably saying that ports lower than 1023 (standard ones) they have to ran as root, well friend they have to be STARTED as root, but they can drop permissions like apache does. Use a unique user for httpd, set /bin/false and shell of that user and put his name on the /etc/ftpusers file. List of vulnerable CGI script ---------------------------- NOTE: This isn't by any means a complete list. - phf - htmlscript - view-source - Count.cgi - pfdisplay - campas - test-cgi - perl.exe - nph-test-cgi - php.cgi - wwwboard.pl - handlers - www-sql - webgais - service.pwd - websendmail - users.pwd - webdist.cgi - aglimpse - faxsurvey - man.sh Maintaining FileSystem Integrity -------------------------------- Maintaining FileSystem Integrity? What's that? Well basically it's the act of maintaining files unchanged against our wish. But hey, I'm not talking about corrupted files, but about trojanned files. Ever heard of something called root kits? Well those kits have most used *nix commands, but trojanned, some of them are ps, ls, netstat.... There's an excellent tool to do this checking it's called Tripwire and u can find it at http://www.tripwiresecurity.com. What it does is when installed gets a mathematical fingerprint of each file and store it in a database, each time you run Tripwire a check between the database fingerprint and the present fingerprint, if they match it's everything ok, if it don't the file has been changed. This was one of the reasons that I said that we should start re-installing the system, in this way we are sure that tripwire is generating fingerprint of the real files, instead of some bogus ones that we could already have without we knowing. Below is a diagram showing how tripwire works ------------------- -------------------- -------------- | new database | | Database generated | | tw.config | --------> | genarated using | | at tripwire | -------------- | tw.config file | | installation | ------------------- -------------------- | | | | | | ---------> <--------- | | --------------- | COMPARATION | --------------- | | --------------- | Apply Any | | Masks Needed | --------------- | | ------------------------ ------> | OUTPUT: Result Report | ------------------------ When we fire up tripwire just two files are used tw.config, where files that should be checked are listed and the database generated at installation that has the original fingerprints. A tw.config file entry looks like: /bin/mount +p+i+u+g+s+a This entry tells tripwire to check the permission bits, the inode number, the number of links, the user and group ID of owner, size of the file and access timestamp. This are the flags that are applied in the Apply Masks phase. For more info about flags check the information that comes with Tripwire. After changes or file adding that you want to keep Tripwiring you can add and update the database with the new fingerprints. Firewalls ---------- Knowing about firewalls is always a good thing, specially if you want to protect your LAN, from the pure chaos that internet can be. In this section we will talk a little about firewalls and some ways of setting them. Firewalls have two mainly functions: - Don't let the "guys" from outside get in. - Don't let the "guys" from inside get out. Yes, actually are both, not just the first as many users thinks. Well actually most of the people that are reading this probably already know it. One of the most known firewalls is our beloved ipchains firewall.As is said in the man page of ipchains: "Ipchains is used to set up, maintain, and inspect the IP firewall rules in the Linux kernel. These rules can be divided into 4 different categories: the IP input chain, the IP output chain, the IP forwarding chain, and user defined chains." Now as you read ipchains inspect the IP firewall rules in the Linux kernel, which means that you can handle every package in the most low level you can make, which is really good. You actually don't receive it process it and then send to firewall to analyze like it happens with some so called "firewalls" from windows. And as you can also see it talks about the 3 functions I told you, calling them IP input chain, this is where rules are set for all the incoming data IP output chain, this is where rules are set for all the outgoing data IP forwarding, this is where rules are set for routing and proxying data Let's now see some examples. Example 1 (standalone): --------------- /\/\/\/\/\/\/\ | Standalone |_________________| THE | | system | | INTERNET | ---------------- \/\/\/\/\/\/\/ If you are in a standalone system you don't need to have forwarding enable, it even would get you an high security risk. Why? Well let's see in this way you most have the ipchains rules for accept the loop back (lo), this means connection FROM your host TO your host. Now if you have ip forwarding enabled this means that someone can send data to forwarded in the firewall to your own host. In this case they are using the firewall as a router, this will be seen has a loop back and accepted. What you couldn't be accepted directly was accepted with a little routing trick. Example 2 (the oldie packet-filtering firewall): /\/\/\/\/\/\/\/\ ----------------- | THE |__________________| Router | | INTERNET | | (firewall) | \/\/\/\/\/\/\/\/ ----------------- | | | 00000000000000000 0 PROTECTED 0 0 LAN 0 00000000000000000 This example is the most basic packet filtering used by many companies who want to filter their LAN. As you can see in the diagram there's a router that connects the protected LAN to the internet, this can work under ip-masquerading if you have a dial-up system with dynamic ip having a private network all behind of the router. In this type of cases the traffic from the internet to the protected is all or at least some blocked, on the hand the LAN can access the entire internet, unless the sysadmin blocks sites like www.hotporn.com so employees don't waste time watching porn shit instead of working. Now, if the firewall allow at least outsider to enter the protected LAN, like SMTP daemon, companies often set up one, the entire network can be in danger, since attackers have a way in. Actually this kinds of attacks are discussed in the Firewall HOWTO, check it for more detailed explanation. In this kind of topologies there is, actually, a direct contact between the protected LAN and the internet, the router just does that it routes, it's a gateway but has the particularity that it sometimes blocks packages, still when it isn't blocking it's just another gateway like the many ones where the internet is based on. EXAMPLE 3 (DMZ system) /\/\/\/\/\/\/\/\ --------------- | THE |____________| Router | | INTERNET | | | \/\/\/\/\/\/\/\/ --------------- | | ----------- *********** | Router | * DMZ *---------| | *********** ------------ | | | 00000000000000000 0 PROTECTED 0 0 LAN 0 00000000000000000 WOW, kinda complex isn't it? Well at lets my ASCII skills are getting better and better just because of all this schemes:) But let's get back into this shall we. Well some of you are asking yourself what does DMZ means. Well DMZ stands for Demilitarized Zone, hum...nice name, but what in fact is a Demilitarized Zone aka DMZ, not in the word meaning because that we understand but in the network? The DMZ is a small network subnet, that as we can see in the diagram is between the two routers. Now the two routers have a filtering policy that the only thing that is accessible by the LAN and by the internet is the DMZ, this means no direct contact, the only network known to both is the DMZ. And what's in that subnet? All the hosts that have the services you want to be accessed by the internet, like DNS servers, DHCP server, etc. This kind of network if good configured is very secure, since it will become really difficult to an outsider redirect traffic to the protected that is in fact an HIDDEN LAN. Logging ------- You have to remember logs are one of your best friends when you are trying to find problems and intruders in your network. First thing you have to realize is that you don't just go check the logs when you start having a problem , you NEED to check the logs in a regular interval, like week to week, but what's the best is that as soon as you get a message problem you should get an alert message. Syslog ------- The syslog is a logging that comes with every linux distro. His configuration file it located at /etc/syslog.conf it's syntax his very simple: selector (composed by facility.priority) action The selector is what type of messages will trick that rule The action will tell where to log them Example: kern.warn /var/log/warn To create the file you need to touch it. Like: # cd /var/log # touch warn # chmod 750 warn To see all the facility and priority key names check syslog.conf man page. If a standalone box generates about 30kb of logs each day, a internet server may generate some megabytes each day. And isn't really easy to look for problems in a 100mb log. The solution for it is a tool called swatch. Swatch ------ As I already said, and you probably already know, Log checking if often ignore by sysadmins since tons of lines are generated by day, sysadmins prefer to check their logs just when they have already been compromised. This behaviour is totally wrong. Swatch has two fundamental uses, it can be an active monitor, checking for messages as they are being logged via syslog or it can also be for auditing, checking logs from the past. Swatch has been design for syslog but it can also monitor any log file like sulog, web access log, fail log... The developers of Swatch (Simple WATCHer), had in mind to write a program that would help the sysadmin to check the problems that their host(s) can be having, actually they had four goals which are: - Easy to use - Perform certain actions as response of certain messages - Support customization by users so they could define their actions - Be reconfigurable without being need to check the manual to know how to do it Swatch can trigger events if a expression match like "Filesystem Full", "Bad Login", "EVILCRACKER.org". Since you can configure the events, let's say that you have a cell phone that has a email address receiving emails as SMS, you could trigger and event like echo LOGGING ALERT | mail cellphone@phoneprovider.sms.org That you would know that you would have troubles. You can find swatch in http://www.stanford.edu/~atkins/swatch/ Maintining Security ------------------- Well now that you have taken all the measures said, installed tripwire, Swatch, subscribed Bugtrag... There's just one more thing that you should always do to insure a good security level. What's that you ask? Well check for security problems! If that can be hard and boring for some people it's not that hard and fun for others. But that's not we are discussing here. If you want to look up problems like misconfigurations, non-password accounts, mismatching permissions, and all those tiny details that can get your box in danger well be my guest, but for the ones that have to much things to do, or are just lazy, or dunnow where to start there's a really two good program for you, called COPS (Computer Oracle and Password System) and Tiger. COPS (Computer Oracle and Password System) ------------------------------------------ COPS is a vunerability testing program, it checks for common security problems that can happen in your box, like non-passworded accounts, or word-writable directories that shouldn't be. The list of what is specially checked is below. - danger permissions on important system files and directories - all files with SUID bit (like I always say SUID bit is a slut) - world-readable/writable file systems - Null passwords fields in /etc/passwd - guessability of account passwords - ilegitimate filesystem changes - users home directory isn't world writable - paths and files on crontab file again to see if they aren't world writable - paths and files on /etc/rc* same reason as last one This is in what COPS focus, still doesn't mean that it just searchs for this security problems. It may take some time to install COPS since it has to be configured specially to your system but after that it will spare you a couple of hours checking for problems that might affect the security. You can get COPS from ftp://coast.cs.purdue.edu/pub/tools/unix/cops/ For you all security experts out there (they are probably wishing to kill me right now), yes I know that COPS is not what people can get as the more up-to-date security program , STILL COPS rocks even if it was release for it's first time 11 years ago (1990). The program comes with extensive documentation, so I think no further explanations are needed. Ending Notes ------------ Well I hope that this text has give you some good orientation on how to secure your box or network agains crackers and script kiddiots. Any feedback is appreciated, and remember the golden rule "To protect yourself you need to watch your network from the attackers eyes" spend some time reading advisories, text about networks and newsgroups like comp.security.unix, comp.security.announce and comp.os.linux.security. You'll learn a lot with peoples problems, believe me.