Professional Documents
Culture Documents
13
Pattern Matching
By looking at your log entries, you can usually determine if you are being port scanned. Most Script Kiddies scan a network for a single vulnerability. If your logs show most of your systems being connected from the same remote system, on the same port, this is most likely an exploit scan. Basically, the enemy has an exploit for a single vulnerability, and they are scanning your network for it. When they find it, they exploit it. For most Linux systems, TCP Wrappers is installed by default. So, we would find most of these connections in /var/log/secure. For other flavors of Unix, we can log all inetd connections by launching inetd with the "-t" flag, facility daemon. A typical exploit scan would look like something below. Here we have a source scanning for the wu-ftpd vulnerability. / v a r / l o g / s e c u r e A p r1 01 3 : 4 3 : 4 8m o z a r ti n . f t p d [ 6 6 1 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 01 3 : 4 3 : 5 1b a c hi n . f t p d [ 6 6 1 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 01 3 : 4 3 : 5 4h a d y e ni n . f t p d [ 6 6 1 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 01 3 : 4 3 : 5 7v i v a l d ii n . f t p d [ 6 6 1 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 01 3 : 4 3 : 5 8b r a h m si n . f t p d [ 6 6 1 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 Here we see the source 1 9 2 . 1 6 8 . 1 1 . 2 0 0scanning our network. Notice how the source sequentially scans each IP (this is not always the case). This is the advantage of having a log server, you can more easily identify patterns in your network since all the logs are combined. The repeated connections to port 21, ftp, indicated they were most likely looking for the wu-ftpd exploit. We have just determined what the black-hat is looking for. Often, scans tend to come in phases. Someone will release code for an imap exploit, you will suddenly see a rush of imaps scans in your logs. The next month you will be hit by ftp. An excellent source for current exploits is http://www.cert.org/advisories/ Sometimes, tools will scan for a variety of exploits at the same time, so you may see a single source connecting to several ports. Keep in mind, if you are not logging the service, you will not know if you are scanned for it. For example, most rpc connections are not logged. However, many services can simply be added to /etc/inetd.conf for logging with TCP Wrappers. For example, you can add an entry in /etc/inetd.conf for NetBus. You can define TCP Wrappers to safely deny and log the connections (see Intrusion Detection for more info on this).
old.honeynet.org/papers/enemy2/
1/5
05.12.13
05.12.13
A p r1 41 9 : 1 9 : 0 5m o z a r ti n . f i n g e r d [ 1 1 6 4 8 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 / v a r / l o g / m a i l l o g A p r1 42 1 : 0 1 : 5 8m o z a r ti m a p d [ 1 1 6 6 7 ] :c o m m a n ds t r e a me n do ff i l e ,w h i l er e a d i n gl i n eu s e r = ? ? ?h o s t = [ 1 9 2 . 1 6 8 . 1 1 . 2 0 0 ] A p r1 42 1 : 0 1 : 5 8m o z a r ti p o p 3 d [ 1 1 6 6 8 ] :N os u c hf i l eo rd i r e c t o r yw h i l er e a d i n gl i n eu s e r = ? ? ?h o s t = [ 1 9 2 . 1 6 8 . 1 1 . 2 0 0 ] A p r1 42 1 : 0 2 : 0 5m o z a r ts e n d m a i l [ 1 1 6 7 5 ] :N O Q U E U E :[ 1 9 2 . 1 6 8 . 1 1 . 2 0 0 ] :e x p nr o o t / v a r / l o g / m e s s a g e s A p r1 42 1 : 0 3 : 0 9m o z a r tt e l n e t d [ 1 1 6 8 2 ] :t t l o o p :p e e rd i e d :I n v a l i do ri n c o m p l e t em u l t i b y t eo rw i d e c h a r a c t e r A p r1 42 1 : 0 3 : 1 2m o z a r tf t p d [ 1 1 6 8 8 ] :F T Ps e s s i o nc l o s e d 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 :) / v a r / l o g / h t t p d / a c c e s s _ l o g 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / p h fH T T P / 1 . 0 "3 0 21 9 2 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / C o u n t . c g iH T T P / 1 . 0 "4 0 41 7 0 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / t e s t c g iH T T P / 1 . 0 "4 0 41 6 9 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / p h p . c g iH T T P / 1 . 0 "4 0 41 6 8 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / h a n d l e rH T T P / 1 . 0 "4 0 41 6 8 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / w e b g a i sH T T P / 1 . 0 "4 0 41 6 8 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / w e b s e n d m a i lH T T P / 1 . 0 "4 0 41 7 2 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / w e b d i s t . c g iH T T P / 1 . 0 "4 0 41 7 2 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / f a x s u r v e yH T T P / 1 . 0 "4 0 41 7 0 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / h t m l s c r i p tH T T P / 1 . 0 "4 0 41 7 1 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / p f d i s p l a y . c g iH T T P / 1 . 0 "4 0 41 7 4 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / p e r l . e x eH T T P / 1 . 0 "4 0 41 6 9 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 4 90 5 0 0 ]" G E T/ c g i b i n / w w w b o a r d . p lH T T P / 1 . 0 "4 0 41 7 2 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 5 00 5 0 0 ]" G E T/ c g i b i n / e w s / e w s / a r c h i t e x t _ q u e r y . p lH T T P / 1 . 0 "4 0 41 8 7 1 9 2 . 1 6 8 . 1 1 . 2 0 0--[ 1 4 / A p r / 1 9 9 9 : 1 6 : 4 4 : 5 00 5 0 0 ]" G E T/ c g i b i n / j jH T T P / 1 . 0 "4 0 41 6 3 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. < m o z a r t$c a t1 7 2 . 1 7 . 6 . 3 0 . 2 1 1 9 2 . 1 6 8 . 1 1 . 2 0 0 . 7 2 3 8 2 2 0m o z a r t . e x a m p l e . n e tF T Ps e r v e r( V e r s i o nw u 2 . 4 . 2 a c a d e m [ B E T A 1 7 ] ( 1 )T u eJ u n91 0 : 4 3 : 1 4E D T1 9 9 8 )r e a d y . 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. / v a r / l o g / s e c u r e A p r1 41 9 : 1 8 : 5 6m o z a r ti n . t e l n e t d [ 1 1 6 3 4 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 8 : 5 6m o z a r ti m a p d [ 1 1 6 3 5 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 8 : 5 6m o z a r ti n . f i n g e r d [ 1 1 6 3 7 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 8 : 5 6m o z a r ti p o p 3 d [ 1 1 6 3 8 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 8 : 5 6m o z a r ti n . t e l n e t d [ 1 1 6 3 9 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 8 : 5 6m o z a r ti n . f t p d [ 1 1 6 4 0 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 9 : 0 3m o z a r ti p o p 3 d [ 1 1 6 4 2 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 9 : 0 3m o z a r ti m a p d [ 1 1 6 4 3 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 9 : 0 4m o z a r ti n . f i n g e r d [ 1 1 6 4 6 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 A p r1 41 9 : 1 9 : 0 5m o z a r ti n . f i n g e r d [ 1 1 6 4 8 ] :c o n n e c tf r o m1 9 2 . 1 6 8 . 1 1 . 2 0 0 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. / v a r / l o g / s e c u r e Dooh! Notice there is nothing there! That is because system logs only record full connections. Since nmap scanner is using -sS option, a complete TCP connection is not being made, thus the scan attempts are not being logged. That is why this scanning method is considered stealthy, system logs are not recording the scans. For older Linux kernels, specifically 2.0.x, incomplete TCP connections are being logged, but as broken. The logs from a -sS scan looks as follows for older kernels. (NOTE: Only the first three entries are included here). / v a r / l o g / s e c u r e A p r1 42 1 : 2 5 : 0 8m o z a r ti n . r s h d [ 1 1 7 1 7 ] :w a r n i n g :c a n ' tg e tc l i e n ta d d r e s s :C o n n e c t i o nr e s e tb yp e e r A p r1 42 1 : 2 5 : 0 8m o z a r ti n . r s h d [ 1 1 7 1 7 ] :c o n n e c tf r o mu n k n o w n A p r1 42 1 : 2 5 : 0 9m o z a r ti n . t i m e d [ 1 1 7 1 8 ] :w a r n i n g :c a n ' tg e tc l i e n ta d d r e s s :C o n n e c t i o nr e s e tb yp e e r A p r1 42 1 : 2 5 : 0 9m o z a r ti n . t i m e d [ 1 1 7 1 8 ] :c o n n e c tf r o mu n k n o w n
old.honeynet.org/papers/enemy2/ 3/5
05.12.13
A p r1 42 1 : 2 5 : 0 9m o z a r ti m a p d [ 1 1 7 1 9 ] :w a r n i n g :c a n ' tg e tc l i e n ta d d r e s s :C o n n e c t i o nr e s e tb yp e e r A p r1 42 1 : 2 5 : 0 9m o z a r ti m a p d [ 1 1 7 1 9 ] :c o n n e c tf r o mu n k n o w n 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. This behaviour only happens with older 2.0.x linux kerenls. 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 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 / v a r / l o g / s e c u r e Once again, 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 without them being logged, similar to the -sS option. To detect these stealth scans, you will need to use a different logging application such as tcplogd or ippl. Most firewalls will also detect and log all of these scans, such as IPFIlter, SunScreen, or FireWall-1.
Conclusion
Your system logs can tell you a great deal about the enemy. However, the first step is guaranteeing the integrity of your log files. One of the best ways to do that is use a remote log server that receives and stores logs from all systems. Once secured, you can then identify patterns in your log files. Based on these patterns and log entries, you can determine what the black-hat is looking for, and potentially what tools they are using. Based on this knowledge, you can better secure and protect your systems.
old.honeynet.org/papers/enemy2/
4/5
05.12.13
old.honeynet.org/papers/enemy2/
5/5