This is a collection of command line security auditing scripts for Linux/Unix.
Originally by Sean Boran in 2000, with a few improvements over the years.
Auditing the security of an existing Solaris system can be time-consuming, and often requires on-site visits. There are several commercial tools and a few free ones that help, but they can be complicated and require local compilation or configuration.
So a tool was developed with the following aims:
This script automates the gathering of the information only. Of course, the difficult part is the interpretation of results and deciding what countermeasures to take
These tools are OpenSource. The GPL v2 applies. Please share any fixes/improvements you make, if possible. Or help with documentation.
The tool consists of two main scripts, both of which look at the system, but do not make any modifications.
svn checkout http://lusas.googlecode.com/svn/trunk/If you require commit access, convince us by getting involved! :-)
These scripts are meant for system administrators. Read the headers in each script and checkout the configuration settings at the top of the script, for example:
# Don't examine these filesystems
$exclude ='/backup|/dir2'; # Don't examine these filesystems
# do not search these directories
$exclude_dirs='^\/home\/data|^\/home\/buff';
$group_rw = ''; # '1'=Report group-writeable files (often a huge list we don't care about)
$debug =''; # '1'=debug (useful), ''=no debug (quiet)
$debug2='0'; # '1'=print results to terminal also
# (default is to write to file only)
$email_results='0'; # '0'=write to file, don't email
$user='root'; # send email to him/her
$aggressive = '0'; # '1'=Immediately DELETE baddies
# DO NOT DO THIS unless you
# have reviewed these sources and tested on a
# non-production machine first..
For the other auditing scripts, please read the script headers, they were developed for specific projects and many need tuning for your environment.
I had a project this week to audit 50 Linux/Unix systems, so after making some improvements to the scripts I re-wrote the documention for my auditing scripts: see http://sean.boran.com/audit
It was required to also check SSH private key files and list those that had no passphrases. A search of the net found two solutions, when were added to the audit SVN respository above.
Trivial Unix passwwords also had to be investigated, the old favourite 'john' http://www.openwall.com/john still works really well (compiled with 'generic' on Suse11/i386).
The need: How can firewall port rules be verified? There are scanning tools available, but they are slow and noisy.
The OpenSource tool ‘fester’, by Andrea Barisani at Inversepath, seems up to the task:
"The tool consists of two perl scripts, a packet injector (ftest) and the listening sniffer (ftestd). The first script injects custom packets, defined in ftest.conf, with a signature in the data part while the sniffer listens for such marked packets. ....
Features: ... simulation of real tcp connections for stateful inspection firewalls and IDS, connection spoofing, IP fragmentation / TCP segmentation, IDS evasion techniques"
http://dev.inversepath.com/trac/ftester
http://dev.inversepath.com/ftester/
http://www.tisc-insight.com/newsletters/56.html (I only notice this paper after I had done the tests below, and it provides several examples...)
An example test run of ftester is described below.
Other OpenSource tools of relevance: linet, tcpdump, ifconfig, nmap, hping, nemises, scapy.
Installation: The ftester components are perl scripts so they can be executed on any platform with a recent version of perl (at least 5.6.1 is recommended) and the three perl modules Net::RawIP, Net::PcapUtils, NetPacket. On Ubuntu 8.04, try
apt-get install libpcap0.8 pcapUtils libnet-pcap-perl libpcap-dev cpan install NetPacket::IP cpan install Net::PcapUtils
For this test two Suse systems were used, separated by a Sunscreen firewall and several routers:
Emitter >> NAT router >> Stealth Firewall >> Sensor
176.17.3.30 80.254.183.65 (Sunscreen) 193.5.233.50
Ftest ftestd
Initialisation: Empty or move the log files on the emitter (ftest.log) and sensor (ftestd.log). Select a port that we know is open between emitter and sensor, this will be used to send a ‘stop signal’ indicating the end of a test. In this example we expect port 21 (ftp) to be open.
Sensor command: (listen to interface ‘eth0’ in verbose mode)
perl ./ftestd -i eth0 -v
Firewall Tester sniffer v.1.0
Copyright©) 2001-2006 Andrea Barisani <andrea@inversepath.com>
default system TTL =
replies TTL = 200
listening on eth0
Emitter command: (do a firewall test according to the specification in ftest.conf)
perl ./ftest -f ftest.conf -v
The configuration file, ftest.conf contains:
# 10ms delay
flags: -d 0–01 -v
# checking privileged ports (<1025)
176.17.3.88:1025:193.5.233.50:1-1025:S:TCP:0
# What port do we know is open, through which we can send a special
# packet that indicates the end of the test run?
stop_signal=176.17.3.88:1025:193.5.233.50:21:AP:TCP:0
Results:
On the emitter we see a line output for each packet sent, and additionally, a file ‘ftest.log’ is created documenting the packets sent
1 - 176.17.3.88:1025 > 193.5.233.50:1 S TCP –
2 - 176.17.3.88:1025 > 193.5.233.50:2 S TCP –
3 - 176.17.3.88:1025 > 193.5.233.50:3 S TCP 0
…..
On the sensor, a line is shown for each packet received:
21 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
Reporting: The ftest.log can then be copied to the sensor, and the two log files compared, and a report established of the open and closed ports. Below there are no unmodified open port, but several which are open and subject to network address translation.
./freport ftest.log ftestd.log
Authorized packets:
Modified packets (probably NAT):
1 - 176.17.3.88:1025 > 193.5.233.50:1 S TCP 0
2 - 176.17.3.88:1025 > 193.5.233.50:2 S TCP 0
4 - 176.17.3.88:1025 > 193.5.233.50:4 S TCP 0
21 - 176.17.3.88:1025 > 193.5.233.50:21 S TCP 0
80 - 176.17.3.88:1025 > 193.5.233.50:80 S TCP 0
443 - 176.17.3.88:1025 > 193.5.233.50:443 S TCP 0
1026 - 176.17.3.88:1025 > 193.5.233.50:80 PA TCP 0
>>>>>>>>
1 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
2 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
4 - 80.254.183.65:1025 > 193.5.233.50:80 S TCP 0
21 - 80.254.183.65:1025 > 193.5.233.50:21 S TCP 0
80 - 80.254.183.65:1025 > 193.5.233.50:80 S TCP 0
443 - 80.254.183.65:1025 > 193.5.233.50:443 S TCP 0
1026 - 80.254.183.65:1025 > 193.5.233.50:80 PA TCP 0
Filtered or dropped packets:
3 - 176.17.3.88:1025 > 193.5.233.50:3 S TCP 0
5 - 176.17.3.88:1025 > 193.5.233.50:5 S TCP 0
6 - 176.17.3.88:1025 > 193.5.233.50:6 S TCP 0
7 - 176.17.3.88:1025 > 193.5.233.50:7 S TCP 0
……. (many more lines..)
Analysis: The detected open ports correspond to what was expected in this case, and the information about NAT is correct.
Some additional tests were conduced to give more real-life usage scenarios. Note that a slow 1Mb network was used for the test, so results are indicative only:
a) Checking all 65’000 ports for one source and one destination IP took 56 seconds.
b) Checking all 65’000 ports for 90 source IPs and one destination IP took 80 minutes.
c) Checking all 65’000 ports from two sets of 45 source Ips and two destinations, i.e. which two ftester instances running in parallel, also took 85 minutes,
- it was almost twice as fast with two processes running in parallel.
- The load on the emitter (2Ghz Pentium ‘barebones’, 512Mb ram) was significant (20% cpu, load average with ‘uptime’: 2.21).
- The (ADSL) NAT router in front of the emitter was really not fast enough:
FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 193.5.233.53
%SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from 0x8015B04C, alignment 0
Pool: Processor Free: 103768 Cause: Memory fragmentation
Alternate Pool: None Free: 0 Cause: No Alternate pool
This is a great tool!
Performance is linear, depending on the number of ports, IPs (in the above low performance environment, one source IP/destination IP for all ports per minute). Checking an entire C-class is much faster than port scanning, but still takes time.
In a Gigabit environment it will of course be much faster than the tests above, but careful selection of source and destination ranges and ports is important.
Several ftester runs can be done in parallel to speed up.
Two articles have been written, the focus of updates is on the v9 paper:
The Bind V9 paper walks through compiling, installing and configuring a chroot'ed BIND v9 on Solaris 2.6 and 8. It also presents examples of advanced topics such as TSIGs and dynamic updates. It is specific to version 9 but aims to help existing BIND 8 administrators realize what is involved in migrating to v9.
Although originally written in 2001, information may still be relevant to you: I do update now and again due to positive feedback and to document some Solaris servers I still have running productively.
If starting from scratch now, I'd probably use Ubuntu LTS as the base OS and use the standard packages and automated updates :-)
This book was written over ten years ago, when there was a lack of material on IT-Security available (e.g. SANS was just starting out). Some sections were never finished, and other are not out of date, but it is provided here for reference purposes.
Objectives
VISIT THE BOOK: http://boran.com/security
An interview with LinuxSecuity: http://www.linuxsecurity.com/content/view/117634/169/