IT Security notes

Linux/unix security auditing scripts "Lusas"

Introduction

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

License

These tools are OpenSource. The GPL v2 applies.  Please share any fixes/improvements you make, if possible. Or help with documentation.

What does it do?

The tool consists of two main scripts, both of which look at the system, but do not make any modifications.

  1. audit.sh: Call two main audit scripts: audit1.sh and audit2.pl and collate results.
  2. remote.sh is an example for running audit.sh on many remote machines via SSH.
  3. audit1.sh (Bourne shell): This script is designed to run quickly and gather as much security information as possible about the system. 
    No file searches are conducted, to keep it fast.
    Tested on: Solaris 2.6/7/8/9, OpenBSD 2.6, RH 7, Suse 7.1/8.1, HP-UX11. Solaris is best supported.
  4. audit2.pl (perl): This second script searches the entire file system, listing SUID, SGID, world-writable, group-writable files. It also lists trust files and their contents. Finally it lists files with weird names (e.g., containing punctuation characters), which might be danger or a sign of penetration. On a large server with 100GB disks, this can take a few hours to run.
    Initially tested on SunOS 5.5/6/7/8/9, OpenBSD 2.6, RH 7, Suse 7.1/8.1/9, HP-UX11.Focus has been on Ubuntu and HP these last few years.

     
  5. audit3.sh is a minimal Bourne shell script, that replaces audit2.pl and old systems than don't have Perl. Normally you don't need to run this.
  6. audit4.sh: Create a list of active tcp/udp connections and listenings in a common format and summarize them in a logfile avoiding very big samplefiles. Udp Sessions cannot be sampled on every architecture.
  7. audit4_summ.pl: Summarise results from audit4.sh on several machines
  8. audit5.sh: Create a list of active tcp/udp connections by listening with tcpdump. Collect in a common format and summarize them in a logfile avoiding very big sample files.
  9. audit5.pl: Create a list of active tcp/udp/icmp connections by listening with tcpdump. Collect in a common format to allow easy viewing in excel Ony record one row for each "connection" (optimise space). WARNING: This script is an optimised version of "audit5.sh", however it seg faults after one hour on one of my test machines, so it can't be considered production ready (SunOS 5.8 Generic_117350-25 sun4u, perl 5.005_03)
  10. audit5_summ.pl: Summarise results from audit5.sh on several machines. We ignore multiple ICMP & tcp sessions with same from/to IP. UDP: ignore multiple packets to ports 514|53|123 with same from/to IP.
  11. ssh-key-crack: There is a sub directory included ssh-key-crack containing two different tools for analysing the strength of pass phrases used to protect SSH private keys. ssh-privkey-crack.c is more complete than ssh-privkey-crack.c. These tools are include in the auditing bundle since they don't have a site of their own.

 

Download

Running the Tool

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.

 To do

Unix auditing, password and ssh key strength

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).

Verify ports open in a firewall with ftester

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

Open ports test

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.

Speed Tests

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

 

Lessons learned.

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.

Securing the BIND DNS server

Two articles have been written, the focus of updates is on the v9 paper:

  1. Hardening BIND v8: bind_hardening8.html
  2. Running BIND v9 DNS Server securely: bind9_20010430.html

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 no longer have productive Solaris servers - everything on Liinux these days.

Update 2012:

Older articles

IT Security Cookbook

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 BOOKhttp://boran.com/security

An interview with LinuxSecuity: http://www.linuxsecurity.com/content/view/117634/169/