An approach to systematic network auditing ============================================ Security papers - members.tripod.com/mixtersecurity/papers.html In the past few years, people have learned that a well concepted network installation done by administrators with average knowledge of security could still very often be compromised due to the large amount of possibilities to attack and discovered vulnerabilities an intruder nowadays has at his disposal. This is the cause why recently security auditing and penetration testing has become popular for big companies, security-aware individuals and of course the security industry. Network auditing, or penetration tests can be seen as a systematic attempt to gain access to a network by discovering all points of access to it, and then analyzing those points for any known vulnerabilities, which a real intruder could use to gain further access. However, many companies are performing this kind of analysis in a manner, which is really not sufficient and systematic enough to spot all possible vulnerabilities. So, here is one possible approach, in a nutshell, that I would take to secure a network systematically. _______________________________________________________________________________ 1. Starting off with a secure network The main pre-requirement for having a secure network is to start off with installations of which you can be sure that no security intrusion has previously happened. Imagine a big company severely securing their resources, only to find they have been compromised a year before, and the attacker has changed the system kernel so he doesn't require any vulnerable program at all to gain access anymore. There hasn't even to be a permanently open tcp or udp port; if the intruder is clever, he had reprogrammed the system to watch for raw data containing secret activation code, and then give backdoor access for a very short period of time, that cannot be detected unless one knows the correct code. Take a look at the Q [1] remote shell, if you need an example. So, first of all, (re-) install your operating systems, making sure that there is are no binary executables left from old installations. Importing other kind of data from other systems generally creates no security risk. If you are open-minded enough to take an advice on what OS to use, then let me suggest anything except Windows NT. Systems like HPUX/AIX/IRIX are no good, either, because they are not open source. The problem is that you CANNOT trust systems that come without their source code to be secure at all. The vulnerabilities which exist in the software and kernel of commercial non- open-source systems are not worse than those in other systems, but they EXIST, and it is very hard for the security community to identify them, and it takes alot more time. For an example, SunOS / Solaris was always said to be very secure, until recently its creators decided to make the source code public (which was a good idea in long-time measures). Quickly, a huge lot of vulnerabilities that couldn't be detected before were found in Solaris, and some people still consider it to be extraordinary secure... this was the right step on becoming a secure operating system, but it will surely take a long time until virtually all vulnerabilities have been spotted. If you want a secure operating system, install a BSD derivate, such as OpenBSD. You can also use Solaris, or Linux if you have sufficient knowledge of securing it. The most problematic thing is, that it has become very easy to install even a complex UNIX system, and that many people only do enough to get it up and running. You should get a system that is at least one year old, or older, to make sure that most of the vulnerabilities present in the system have already been spotted - this is important, the people who always install the newest version of their systems, one day after they come out, put their security at risk worse than people who run outdated, but well-patched systems. Secondly, go to your vendors web site and inform yourself about which software packages you should update. Regarding security purposes, it is only important to update packages that are suid root, always run as root, and servers that you generally need and run. Next, disable any servers that run by default and that you won't explicitly require on your network! Browse through your files, looking for suid binaries: find / \( -perm -4000 -o -perm -2000 ! -type d \) -exec ls -ldb {} \; Remove the suid flag (chmod 755 each binary) on any of the programs that don't need to be run by non-root users / scripts with root privileges. Now you need to examine your system and server configuration, most of it is in the /etc directory. Get to know your operating systems security mechanisms, and also recompile your kernel. You should have basic knowledge of every server / daemon process that you run on your machines, and check the configuration for it. Once you have done all this, you can consider to have a system with basic stability and security present. Also consider doing this on one system and copying your partitions to other systems to save yourself some work. One more recommended thing is to block ICMP at your border router(s), to be safe from ICMP 'firewalking' and generic denial of service. To prevent 'smurf' and other flood attacks, specifically make sure your broadcast addresses do not reply to ICMP (IPs ending in .0 and .255), and (if you use IOS or something similar), make your routers detect 'flood' attacks and go into high-bandwidth or alternative-route modes if they detect a certain amount of packets in a specified amount of time. Connection-oriented routing can also be very useful. Finally, deny all other known and unknown IP protocols besides TCP, UDP and ICMP, in case you don't need them. _______________________________________________________________________________ 2. Creating reliable audit trails One simple precaution that everyone should take is to make sure that audit trails (in other words: logs) are present, and one instance of them cannot be altered. Compile a list of servers that you don't (!) and never will run on any of the machines on your network, and instruct your border routers that connect you with the rest of the world, to deny and log all incoming requests to those ports. Don't block port 20 unless you want to break active ftp transfers, and don't block ports above 1024 (non-privileged). You should have some instance of remote logging available, that each of your hosts uses. The easiest way is to configure syslog (see syslog.conf manpage) to log all messages to a remote loghost. A loghost is a dedicated, secured machine that runs only syslog and sshd (or not even sshd, so it is accessible only physically via console) and has enough disk space for all the logs. A good idea would also be a solution with digitally signed and/or encrypted logs to prevent manipulation and to ensure authenticity. Once you have done this, you can implement extra Intrusion Detection and firewalling services. This is recommended as extra security mechanism, but not required, if you have really secured your machines well, and a bit too much to cover it all in one article. Only this much: If you implement a firewall/IDS, then first perform step 3, install the firewall with a good rule set and perform step 3 again to audit your firewall rules and your IDS stability and logging capabilities. _______________________________________________________________________________ 3. Penetration testing I: gathering information Now, let us find every available service. If this step is performed before implementing a firewall, it should be performed from within the local network, to be as reliable as possible, else from behind the network border. You should use nmap [4] for port scanning, which is currently the most reliable and comprehensible way of port scanning available. Scan tcp port range 1 to 65535 and udp port range 1 to 65535 on every host, and save the results (open ports). This would look like, for example: nmap -sT -P0 -p1-65535 -I -n 10.0.0.0/24 >> results.txt nmap -sU -P0 -p1-65535 -I -n 10.0.0.0/24 >> results.txt (This would scan hosts 10.0.0.0 to 10.0.0.255.) Note: to audit firewall rules or IDS logging capabilities, re-run this scan with values like: -f, -sS / -sF / -sN and -g 20 / 53 / 80 The results should NOT show more than normal scans, and an eventually installed IDS should detect and log the stealth scanning tricks. _______________________________________________________________________________ 4. Penetration testing II: evaluating information Generally, the causes of remote network security problems can be classified into five groups: I. Problems due to buffer overflows (ex.: exploitable imap server) II. Problems due to generally insecure programs (ex.: insecure CGI scripts) III. Problems due to insecure configuration (ex.: default samba shares) IV. Problems due to lack of or insecure passwords (ex.: SNMP daemon) V. Backdoors and trojan horses (not applicable if you went through step 1.) Many people see a penetration check as an attempt to exploit any of these problems, if present, to gain access (hack) into a host and therefore prove that it is insecure. This is not sufficient to ensure the security in a systematical way, however, because one would omit the potential holes. One way to start off, is using a well-designed and reliable security scanner, like NSAT [5]. I don't only recommend it because of self-promotion ;), but because it scans for a lot of vulnerabilities and does not only report them, but rather a lot of information, versions, auditing results etc. out of which one can draw its own conclusions. In contrary to many other scanners, this enables NSAT to audit services at all times with maximum efficiency, while it doesn't need to maintain a very recent vulnerabilities database. Give NSAT a try and audit the services it scans for with it. However, if you run other uncommon services, that NSAT does not scan for, or you want to be 100% safe you should afterwards scan and examine them manually as well, using telnet, netcat, browser, etc. sessions. To actually identify all vulnerabilities, (you may have guessed it, this is the hardest part :)!), search archives of security mailing lists [8], security sites [9], and vendor sites for known security issues regarding the server, and also don't be afraid to write the author to ask if your version is vulnerable. If you find no exploits or advisories regarding your program at all, you can consider it to be secure. The better way is of course, to search updates for every server you run and install the latest versions. Retain from running anything if you don't fully understand how to configure and maintain it. In most cases, understanding a program up to the point where you know how to properly secure it, doesn't take too much work, as most GNU programs are generally well-documented and user friendly once you get to know them. There are a few examples, where you can not audit services satisfyingly by looking at the version or performing sample sessions, namely httpd, where you have to locally examine the CGI scripts. You can use very sophisticated and flexible CGI scanners to locate vulnerable CGI's, but you can never be sure to find all by doing a remote scan. You need to locally scan your cgi-bin/ directory and scripts that may reside somewhere else in your document root. A big security risk are self-written or uncommon CGI scripts, an intruder WILL scan and find those, if he tries hard enough. Always consider every executable script on your HTTP server as relevant to security as a separate server running with the privileges of your httpd. Another important subjects are services with password authentication. If possible, disable non-encrypted services and use kerberos-enabled mail servers, and ssh / sftp instead. It is crucial to your security to have all authentication mechanisms use strong, non-standard passwords that cannot be easily brute forced. Configuring your standard authentication not to take weak passwords at all is a good idea. If you are securing multi- user systems, you should always make secure passwords a central point in your security policy. (But designing an adequate security policy is another big, important topic besides network security.) BSD style MD5 and all DES passwords can and should be tested with John [6]; other issues with passwords exist in snmp, http auth, linuxconf, r-services, SQL and various other services. _______________________________________________________________________________ A small collection of related articles and programs [1] Q - stealth encryted remote shell and redirection server http://members.tripod.com/mixtersecurity/Q-0.9.tgz [2] Brian Martin: Why your network is still vulnerable http://www.hackernews.com/orig/whyvuln.html [3] David Curry: Improving your network by breaking into it http://www.rootshell.com/beta/docs/improving_security_sri.ps.gz [4] Nmap by fyodor http://www.insecure.org/nmap [5] Network security analysis tool http://members.tripod.com/mixtersecurity/nsat-1.09.tgz [6] John the ripper by Solar Designer http://www.false.com/security [7] Daniel V. Klein: Foiling the Cracker http://www.rootshell.com/beta/docs/passwords_klein.ps.gz [8] Security Focus / Bugtraq Mailing List archives http://www.securityfocus.com [9] Packet Storm Security http://packetstorm.securify.com _______________________________________________________________________________ Mixter http://members.tripod.com/mixtersecurity