--------------------------<[ * report for host mozart *
<[ tcp port: 80 (http) ]>       <[ tcp port: 23 (telnet) ]>
<[ tcp port: 143 (imap) ]>      <[ tcp port: 110 (pop-3) ]>
<[ tcp port: 111 (sunrpc) ]>    <[ tcp port: 79 (finger) ]>
<[ tcp port: 53 (domain) ]>     <[ tcp port: 25 (smtp) ]>
<[ tcp port: 21 (ftp) ]>
--<[ *OS*: mozart: os detected: redhat linux 5.1
mozart: VULN: linux box vulnerable to named overflow.
-<[ *CGI*: 172.17.6.30: tried to redirect a /cgi-bin/phf request.
-<[ *FINGER*: mozart: root: account exists.
--<[ *VULN*: mozart: sendmail will 'expn' accounts for us
--<[ *VULN*: mozart: linux bind/iquery remote buffer overflow
--<[ *VULN*: mozart: linux mountd remote buffer overflow
---------------------------<[ * scan of mozart completed *

• Nmap represents the "raw data" tool set.  It doesn't tell you what vulnerabilities exist,  rather, it tells you what ports are open, you determine the security impact.  Nmap has quickly become the port scanner of choice, and with good reason.  It takes the best of a variety of port scanners and puts all their functionality into a single tool, including OS detection, various packet assembly options, both UDP and TCP scanning, randomization, etc.  However, you need  networking skills to use the tool and interpret the data.  Below is an example of nmap ran against the same system.

otto #nmap -sS -O 172.17.6.30

Starting nmap V. 2.08 by Fyodor (fyodor@dhp.com, www.insecure.org/nmap/)
Interesting ports on mozart (172.17.6.30):
Port    State       Protocol  Service
21      open        tcp        ftp
23      open        tcp        telnet
25      open        tcp        smtp
37      open        tcp        time
53      open        tcp        domain
70      open        tcp        gopher
79      open        tcp        finger
80      open        tcp        http
109     open        tcp        pop-2
110     open        tcp        pop-3
111     open        tcp        sunrpc
143     open        tcp        imap2
513     open        tcp        login
514     open        tcp        shell
635     open        tcp        unknown
2049    open        tcp        nfs

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
Remote operating system guess: Linux 2.0.35-36

Nmap run completed -- 1 IP address (1 host up) scanned in 2 seconds

/var/log/secure
Apr 14 19:18:56 mozart in.telnetd[11634]: connect from 192.168.11.200
Apr 14 19:18:56 mozart imapd[11635]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.fingerd[11637]: connect from 192.168.11.200
Apr 14 19:18:56 mozart ipop3d[11638]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.telnetd[11639]: connect from 192.168.11.200
Apr 14 19:18:56 mozart in.ftpd[11640]: connect from 192.168.11.200
Apr 14 19:19:03 mozart ipop3d[11642]: connect from 192.168.11.200
Apr 14 19:19:03 mozart imapd[11643]: connect from 192.168.11.200
Apr 14 19:19:04 mozart in.fingerd[11646]: connect from 192.168.11.200
Apr 14 19:19:05 mozart in.fingerd[11648]: connect from 192.168.11.200

/var/log/maillog
Apr 14 21:01:58 mozart imapd[11667]: command stream end of file, while reading line user=??? host=[192.168.11.200]
Apr 14 21:01:58 mozart ipop3d[11668]: No such file or directory while reading line user=??? host=[192.168.11.200]
Apr 14 21:02:05 mozart sendmail[11675]: NOQUEUE: [192.168.11.200]: expn root

/var/log/messages
Apr 14 21:03:09 mozart telnetd[11682]: ttloop:  peer died: Invalid or incomplete multibyte or wide character
Apr 14 21:03:12 mozart ftpd[11688]: FTP session closed

sscan also scans for cgi-bin vulnerabilities.  These probes will not be logged by syslogd, you will find them in access_log.  I decided to included them anyway for your edification :)

/var/log/httpd/access_log
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/phf HTTP/1.0" 302 192
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/Count.cgi HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/test-cgi HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/php.cgi HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/handler HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webgais HTTP/1.0" 404 168
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/websendmail HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/webdist.cgi HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/faxsurvey HTTP/1.0" 404 170
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/htmlscript HTTP/1.0" 404 171
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/pfdisplay.cgi HTTP/1.0" 404 174
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/perl.exe HTTP/1.0" 404 169
192.168.11.200 - - [14/Apr/1999:16:44:49 -0500] "GET /cgi-bin/wwwboard.pl HTTP/1.0" 404 172
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/ews/ews/architext_query.pl HTTP/1.0" 404 187
192.168.11.200 - - [14/Apr/1999:16:44:50 -0500] "GET /cgi-bin/jj HTTP/1.0" 404 163

Notice how a complete connection was made for all the ports(SYN, SYN-ACK, ACK)  then torn down.  That is because sscan is determining at the application layer what is going on.  Not only does sscan want to know if your ftp port is open, but what ftp daemon is running.  The same can be said for imap, pop, etc.  This can be seen in sniff traces using sniffit, a tool commonly used to sniff passwords.

mozart $ cat 172.17.6.30.21-192.168.11.200.7238
220 mozart.example.net FTP server (Version wu-2.4.2-academ[BETA-17](1) Tue Jun 9 10:43:14 EDT 1998) ready.

As you see above, a complete connection was made to determine the version of wu-ftpd that was running.  When you see the complete connections in your logs, as shown above, you are most likely  being scanned by an exploit tool.  These tools are making a complete connection to determine what you are running.

Nmap, like most port scanners, does not care what you are running, but if you are running specific services.  For this, nmap has a powerful set of options, letting you determine what kind of connection to make, including SYN, FIN, Xmas, Null, etc.  For a detailed description of these options, check out http://www.insecure.org/nmap/nmap_doc.html.   Because of these options, your logs will be different based on the options selected by the remote user.   A connection made with the -sT flag is a complete connection, so the logs will like similar to sscan, however by default nmap scans more ports.

/var/log/secure
Apr 14 21:20:50 mozart in.rlogind[11706]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.fingerd[11708]: connect from 192.168.11.200
Apr 14 21:20:51 mozart ipop2d[11709]: connect from 192.168.11.200
Apr 14 21:20:51 mozart in.rshd[11710]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: connect from 192.168.11.200
Apr 14 21:20:51 mozart gn[11711]: error: cannot execute /usr/sbin/gn: No such file or directory
Apr 14 21:20:52 mozart in.timed[11712]: connect from 192.168.11.200
Apr 14 21:20:52 mozart imapd[11713]: connect from 192.168.11.200
Apr 14 21:20:52 mozart ipop3d[11714]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.telnetd[11715]: connect from 192.168.11.200
Apr 14 21:20:52 mozart in.ftpd[11716]: connect from 192.168.11.200

One thing to keep in mind is the -D (or decoy) option.  This nmap option allows the user to spoof the source address.  You may see scans from 15 different sources at the same time, but only one of them is the real one.  It is extremely difficult to determine which of the 15 was the actual source.  More often, users will select the -sS flag for port scanning.  This is a stealthier option, as only a SYN packet is sent.   If the remote system responds, the connection is immediately torn down with a RST.  The logs from such a scan looks as follows (NOTE: Only the first five entries are included here).

/var/log/secure
Apr 14 21:25:08 mozart in.rshd[11717]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:08 mozart in.rshd[11717]: connect from unknown
Apr 14 21:25:09 mozart in.timed[11718]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.timed[11718]: connect from unknown
Apr 14 21:25:09 mozart imapd[11719]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart imapd[11719]: connect from unknown
Apr 14 21:25:09 mozart ipop3d[11720]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart ipop3d[11720]: connect from unknown
Apr 14 21:25:09 mozart in.rlogind[11722]: warning: can't get client address: Connection reset by peer
Apr 14 21:25:09 mozart in.rlogind[11722]: connect from unknown
 

Notice all the errors in the connections.  Since the SYN-ACK sequence is torn down before a complete connection can be made, the daemon cannot determine the source system.  The logs show that you have been scanned, unfortunately you do not know by whom.  What is even more alarming is, on most other systems (including newer kernels of Linux), none of these errors would have been logged.  To qoute Fyodor " ... based on all the 'connection reset by peer' messages.  This is a Linux 2.0.XX oddity -- virtually every other system (including the 2.2 and later 2.1 kernels) will show nothing.  That bug (accept() returning before completion of the 3-way handshake) was fixed."

Nmap includes other stealth option, such as -sF, -sX, -sN where various flags are used,  This is what the logs look like for these scans

/var/log/secure
 

Notice something here, no logs!  Scary huh, you just got scanned and didn't even know it.  All three types of scans determined the same results, however you are able to fully log only the first type, -sT (full connection).  To detect these stealth scans, you will need to use a different logging application such as tcplogd or ippl   Some commercial Firewalls will also detect and log all of these scans (I have confirmed this on Checkpoint Firewall 1).
 

Did They Gain Access?
Once you have determined that you were scanned, and what you were looking for, the next big question is "Did they get in?".   Most of today's remote exploits are based on buffer overflows (otherwise known as smashing the stack).  Simply stated, a buffer overflow is when a program (usually a daemon) receives more input then it expected, thus overwriting critical  areas in memory.  Certain code is then executed, usually giving the user root access.  For more info on buffer overflows, check Aleph1's excellent paper at ftp://ftp.technotronic.com/rfc/phrack49-14.txt.

You can normally identify buffer overflow attacks in the /var/log/messages log file (or /var/adm/messages for other flavors of Unix) for attacks such as mountd.  You will also see similar logs in maillog for such attacks against imapd.  A buffer overflow attack would look like this.

Apr 14 04:20:51 mozart mountd[6688]: Unauthorized access by NFS client 192.168.11.200.
Apr 14 04:20:51 mozart syslogd: Cannot glue message parts together
Apr 14 04:20:51 mozart mountd[6688]: Blocked attempt of 192.168.11.200 to mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~
P~P~P3Û3À°^[Í~@3Ò3À~KÚ°^FÍ~@þÂuô1À°^BÍ~@~EÀubëb^V¬<ýt^FþÀt^Këõ°0þÈ~HFÿëì^°^B~
I^FþÈ~IF^D°^F~IF^H°f1ÛþÃ~IñÍ~@~I^F°^Bf~IF^L°*f~IF^N~MF^L~IF^D1À~IF^P°^P~IF^H°
fþÃÍ~@°^A~IF^D°f³^DÍ~@ë^DëLëR1À~IF^D~IF^H°fþÃÍ~@~Hð?1ÉÍ~@°?þÁÍ~@°?þÁÍ~@¸.bin@~
I^F¸.sh!@~IF^D1À~HF^G~Iv^H~IF^L°^K~Ió~MN^H~MV^LÍ~@1À°^A1ÛÍ~@èEÿÿÿÿýÿPrivet
ADMcrew~P(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(Apr 14 04:20:51
mozart ^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^
E^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^ H(-^E^H(-^E^H(-^E^H(-^E^H(-^E^H(-^E
^H(-^E^H(-^E
 

When you see something like this in your log files, someone has attempted to exploit your system.  It is difficult to determine if the exploit was successful.  One way to do this is, following the exploit attempt, see if there are any connections from the remote source to your system.  If they successfully login from the remote system, they have access.  Another clue is if you find the accounts "moof", "rewt", "crak0", or "w0rm" added to your /etc/passwd file.  These accounts, uid 0, are added by some of the more common exploit scripts.  Once a black-hat gains access, normally the first thing they do is wipe your logs clean and trojan your logging (syslogd), for more information, see Know Your Enemy: III.  From this point on, you will not receive any logs from your system as everything has been compromised.  What you do next is subject for another article :).   Until then, I recommend you check out http://www.cert.org/nav/recovering.html

To help me find anomalies in my log files, I whipped up a shell script that scans my logs for me    For more detailed information on grepping and sorting log files, check out this posting by Marcus Ranum.

Author's bio
Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@spitzner.net .