Monitoring Attacks


Regardless of the type of network service you want to enable, you should have lots of log files that identify what happened and when. You're going to need a way to sort through all the noise and clutter for those few items that might indicate a possible attack-or a successful attack.

What Should You Look For?

There are a couple of different types of attacks, each of which should show up in various log files.

  • Brute force-Brute force attacks are usually tried against login systems. You should see logs that have a high number of failed connection attempts.

  • Reconnaissance scans-Before attacking a target, many systems initially perform some type of reconnaissance. This should appear in the logs as a scan. Scans usually look like a bunch of connections or simple queries. There may be one per host, or a suite of connections per host. If the scan finds anything useful, then the attack will come later.

  • One-time tries-Many automated attack systems blindly try exploits. If the attack works, then you are compromised. If it fails, then you're safe. These should appear in log files as one-time oddities. Or in the case of a massive worm, lots of the same oddity as each infected system tries to spread.

A quick hack for analyzing log files simply looks at file size. If you rotate logs hourly or daily, then look for a sharp increase in log size-this will indicate some new worm or network scan. As far as one-time attacks go, look over some logs to get an idea of "normal" and then look for things that stand out as odd.

Periodic scans of your own systems with tools like nmap should be used to look for new, unexpected services. If there is a new, unexpected service running on your system, then take the time to find out why. If there are lots of new ports, then it is a good sign that the system is compromised. Similarly, look for unexpected network traffic. If you never use IRC and start seeing IRC traffic, then find out where it is coming from!

What Now? After a Compromise

Ok, so you started a new network service, you put it on the Internet, and you've been compromised. Do you know what you will do? Turning off the system is a good start, but how and when will you turn it back on? Do you reset or restore the system? This could simply reintroduce the same environment that led to the initial compromise!

Regardless what you plan to do, have a plan in place before making a service public. For example, what will you do if you are on vacation and you suddenly hear that your hobby FTP server is sending millions of spam e-mail messages? It is better if you take care of it than having your ISP disconnect you.

I have a very simple plan: there is always someone available to pull out the power cord if a system is acting fishy. Later, I can remove the hard drive and mount it under a different Linux system and see what went wrong and recover log files. Later, I can restore from a backup and apply the most recent patches as needed.

Logging Logins

Many types of services provide login access. Failed logins should be placed in log files. Under the default Ubuntu installation, successful logins are stored in /var/log/wtmp. This is a binary file that stores the login account name, date of access (login and logout), and if it is a remote connection, then the name of the remote host. You can access this log file with the last command.

 $ last nealk    pts/2        foghorn.local.lan  Sun Dec  3 10:36    still logged in nealk    :0                              Sat Dec  2 15:31    still logged in reboot   system boot  2.6.15-26-686      Sat Dec  2 15:30          (1+00:51) wtmp begins Sat Dec  2 11:10:17 2006 

Unfortunately, Ubuntu does not normally log failed login attempts. To log failed attempts, you will need to create a /var/log/btmp file. Simply creating this file enables logging and all new login failures will be recorded.

 sudo touch /var/log/btmp sudo chown root:utmp /var/log/btmp sudo chmod 660 /var/log/btmp 
Tip 

The /var/log/btmp file is usually used by text-based login windows. The graphical login screen, such as Dapper's gdm version 2.14, does not record login failures to btmp. To test btmp, press Alt+F2 and try a few failed logins, then login and use lastb to see the results.

You can access the btmp logs using the lastb command:

 $ sudo lastb UNKNOWN                                 Sun Nov 12 15:36 - 15:36  (00:00) root                                    Sun Nov 12 15:36 - 15:36  (00:00) root                                    Sun Nov 12 15:35 - 15:35  (00:00) 111                                     Sun Nov 12 12:05 - 12:05  (00:00) ggg                                     Sun Nov 12 12:05 - 12:05  (00:00) UNKNOWN                                 Sun Nov 12 12:01 - 12:01  (00:00) UNKNOWN                                 Sun Nov 12 12:01 - 12:01  (00:00) UNKNOWN                                 Sun Nov 12 12:00 - 12:00  (00:00) nealk                                   Sun Nov 12 11:58 - 11:58  (00:00) nealk                                   Sun Nov 12 11:58 - 11:58  (00:00) UNKNOWN                                 Sun Nov 12 11:56 - 11:56  (00:00) UNKNOWN                                 Sun Nov 12 11:56 - 11:56  (00:00) btmp begins Sun Nov 12 11:56:40 2006 

Tip 

The wtmp and btmp log files rotate. You may need to use lastb -f to specify a specific log file. For example, sudo lastb -f /var/log/btmp.1.

Normally btmp only logs valid user names and the time of the failed login attempts. Unknown user names are logged as UNKNOWN. You can change btmp to log all unknown usernames, enabling you to see what user names are used by a brute force attack:

  1. As root, edit /etc/login.defs.

  2. Change LOG_UNKFAIL_ENAB from no to yes. There is no need to restart the system-this change takes affect immediately.

Warning 

Users sometimes accidentally enter their password instead of a user name. This means that their passwords will be logged to /var/log/btmp. If you accidentally enter your password at the login prompt of a multi-user system, then login and immediately change your password.

Tip 

Make sure btmp is not world-readable (sudo chmod o-r /var/log/wtmp) to prevent other users from potentially seeing login-password mistakes.

Although last and lastb record login events, not every remote-access system uses them. For example, the SSH daemon logs to /var/log/auth.log. To see the list of failed logins, you will need to search the log files:

 $ zgrep "Invalid user" /var/log/auth.log* | sed -e 's/^.*: //' | sort | uniq -c       2 Invalid user bill from 127.0.0.1       1 Invalid user cow from 10.1.3.251       3 Invalid user dog from 127.0.0.1 

This command searches all of the auth.log files for the lines containing Invalid user.It then displays each invalid user name, where the attempt came from, and how many times it was tried (sorted by user name).

Tip 

The zgrep command searches regular logs and compressed (.gz) files.

Enabling Intrusion Detection Systems

Snort is a very powerful tool. As mentioned in Chapter 11, it can be used to sniff packets. However, Snort can do much more than just collect packets. The default installation (sudo apt-get install snort) enables an Intrusion Detection System (/etc/init.d/snort).

This constantly watches for suspicious traffic and generates an activity report. To generate a report, you can use the snort-stat command:

 $ sudo id   # make sure the next sudo command does not prompt for a password $ sudo cat /var/log/snort/alert | snort-stat -a | less Events between  11 28 05:29:52  and  12 02 10:26:15 Total events: 1289 Signatures recorded: 21 Source IP recorded: 8 Destination IP recorded: 21 Events from same host to same destination using same method =========================================================================   # of  from             to               method =========================================================================   1088  10.1.3.10        10.255.255.255   NETBIOS name query overflow attempt UDP     73  10.1.3.5         65.19.187.154    WEB-IIS %2E-asp access     24  204.11.52.67     10.1.3.5         ATTACK-RESPONSES 403 Forbidden     21  64.127.105.40    10.1.3.5         ICMP Destination Unreachable Communication with Destination Host is Administratively Prohibited      9  64.127.105.44    10.1.3.5         ICMP Destination Unreachable Communication with Destination Host is Administratively Prohibited      6  10.1.3.5         209.97.46.5      (http_inspect) DOUBLE DECODING ATTACK      4  10.1.3.251       10.1.3.5         SNMP trap tcp      4  10.1.3.251       10.1.3.5         SNMP AgentX/tcp request      3  10.1.3.5         72.21.210.11     WEB-CGI redirect access      3  10.1.3.251       10.1.3.5         (spp_rpc_decode) Multiple RPC Records      3  10.1.3.5         203.0.178.91     WEB-CGI count.cgi access      2  10.1.3.30        10.1.3.5         (portscan) TCP Portscan      2  10.1.3.251       10.1.3.5         (portscan) TCP Portscan      2  10.1.3.251       10.1.3.5         (portscan) TCP Portsweep -More- 

The log report shows the number of suspicious packets, as well as the type of attack. For example, there were a couple of port scans and port sweeps identified, as well as some suspicious web traffic, but the main concern is a NETBIOS name query overflow attempt. (In this case, it was due to a misconfigured OS/2 system running an old SMB configuration.) Although there are likely to be many false-positive findings, some items such as port scans and known attacks should be closely examined. All of the suspicious packets are saved in /var/log/ snort/tcpdump.log.* files. These can be viewed using Ethereal (see Chapter 11).

The actual set of IDS rules used by Snort are found in /etc/snort/rules/. There are dozens of attack signatures that trigger alerts. If you have some known false-positives, you can remove the IDS rule by commenting out the rule in the /etc/snort/snort.conf configuration file. Similarly, if you learn of a new rule, then you can easily add it to the rules directory and tell snort.conf to include the new rule. After changing any of the rules, be sure to restart the IDS: sudo /etc/init.d/snort restart.

The Snort IDS configuration files (/etc/snort/snort.conf and /etc/snort/snort. debian.conf) have a large number of configuration items, and most have excellent default values. The main items you may want to change are your home network (the HOME_NET variable) and the interface. For example, one of my systems has two network adapters: eth0 and eth1. One adapter (eth0) is used for regular network traffic, while the other (eth1) is connected to a hub in the DMZ and monitors suspicious traffic. To change Snort so that it watches only the second network card, I changed the interface name in /etc/snort/snort.debian. conf from DEBIAN_SNORT_INTERFACE="eth0" to DEBIAN_SNORT_INTERFACE="eth1".



Hacking Ubuntu
Hacking Ubuntu: Serious Hacks Mods and Customizations (ExtremeTech)
ISBN: 047010872X
EAN: 2147483647
Year: 2004
Pages: 124
Authors: Neal Krawetz

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net