Threat Level: green Handler on Duty: Jim Clausing

SANS ISC: A day in the life of a firewall log - Internet Security | DShield SANS ISC InfoSec Forums


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
A day in the life of a firewall log

Every now and then when you have one of those days some nice therapy is to go through the firewall logs.  After all, whilst junior is doing a good job, you do need to keep your hand in, you never know what you might find.

This particular firewall often has some interesting logs entries as it hooks up to a public C class network.  So patterns are often more obvious than may be the case on smaller networks.

The way I broke the logs down is very simple.  Using the DSHIELD Universal Firewall Client I reduced the firewall log down to the basic information that is typically submitted to the DSHIELD.  It gives me a time, source, destination IP and ports and the protocol.  The information left are all the denies, but as I’m looking at a class C anything unusual is likely to hit a closed port on one of the addresses and at this stage I’m interested in getting an idea of what is happening in this particular nick of the woods, nothing more.

So what did 12/12 bring?
Firstly lots of SPAM, both email and Instant Messaging (IM) spam.   The mail SPAM is being sent to the secondary MX record.  The reason it is bouncing on this particular firewall is because the port is closed, unless the primary mail server can’t be reached.  About 13K SPAM emails were “delivered” to the secondary MX address.  This is approximately triple the amount delivered to the primary mail server for this site.   The sources varied, but the following list of countries was responsible for most of the SPAM (and pretty much anything else as well):  China, Russia, Thailand, Peru, Turkey, Italy, Columbia, and Poland.

What else was there?
(btw most of the entries shown were repeated for a significant number of hosts on the subnet)

The explained
Hosts looking for open proxies:
195.10.123.118    3142    abc.def.ghi.198    80    TCP
195.10.123.118    3143    abc.def.ghi.198    443    TCP
195.10.123.118    3148    abc.def.ghi.198    1080    TCP
195.10.123.118    3145    abc.def.ghi.198    3128    TCP
195.10.123.118    3146    abc.def.ghi.198    8000    TCP
195.10.123.118    3144    abc.def.ghi.198    8080    TCP

Looking for SQL servers
203.168.246.177    2256    abc.def.ghi.174    1433    TCP
203.168.246.177    2245    abc.def.ghi.174    3306    TCP
203.168.246.177    1813    abc.def.ghi.191    1433    TCP
203.168.246.177    1814    abc.def.ghi.191    3306    TCP
203.158.191.28       2563    abc.def.ghi.155    3306    TCP
203.158.191.28       2249    abc.def.ghi.165    3306    TCP
203.162.219.133     2093    abc.def.ghi.112    1433    TCP
203.162.219.50       2539    abc.def.ghi.200    1433    TCP

Probing the usual MS ports
203.110.95.199      3153    abc.def.ghi.61     445    TCP
203.110.95.199      1569    abc.def.ghi.64     445    TCP
203.113.133.72      2498    abc.def.ghi.100   139    TCP
203.113.133.72      2504    abc.def.ghi.101   139    TCP
190.137.134.106    1035    abc.def.ghi.60     137    UDP
190.137.134.106    1035    abc.def.ghi.61     137    UDP

Looking for pop3 & SMTP
68.20.167.21    4804    abc.def.ghi.53    110    TCP
68.20.167.21    1112    abc.def.ghi.54    110    TCP
190.2.22.85    1369    abc.def.ghi.110    25    TCP
190.2.22.85    1370    abc.def.ghi.111    25    TCP

Slammer Worm
202.96.87.29    1107    abc.def.ghi.105    1434    UDP
202.96.87.29    1107    abc.def.ghi.106    1434    UDP

SAV Bot (CVE-2006-2630)
203.20.75.18    3884    abc.def.ghi.135    2967    TCP
203.20.75.18    3371    abc.def.ghi.142    2967    TCP

Looking for X11
195.13.58.137    44101    abc.def.ghi.211    6000    TCP
195.13.58.137    44102    abc.def.ghi.212    6000    TCP

Trend Micro Server issue from earlier in the year
58.246.107.14    6000    abc.def.ghi.100    5168    TCP
58.246.107.14    6000    abc.def.ghi.101    5168    TCP

SSH Probes
193.0.121.66    41359    abc.def.ghi.110    22    TCP
193.0.121.66    57590    abc.def.ghi.111    22    TCP

Planetlab
05:42:41     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
06:05:53     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
06:30:54     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
06:49:43     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
07:17:32     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
07:41:10     193.55.112.40    59912    abc.def.ghi.136    33434    UDP
The above entries looked unusual and were traced back to a research facility Planetlab, which has a number of projects, the project hitting the firewall in this case was looking for routing anomalies.

Unix Traceroute - (Thanks Jens)
206.123.64.70    12889    abc.def.ghi.26    33435    UDP      - Unix Traceroute
206.123.64.70    17749    abc.def.ghi.26    33437    UDP     -  Unix Traceroute

The unexplained
For the following I’m yet to find a good explanation so more digging tomorrow.   If you have a good explanation, feel free to write in using the contact form.
66.168.182.42    50935    abc.def.ghi.235    4899    TCP
66.168.182.42    50937    abc.def.ghi.236    4899    TCP
66.168.182.42    50938    abc.def.ghi.237    4899    TCP
The DSHIELD database shows a big increase in the number of targets for the last few days, but I haven’t managed to capture anything just yet.  The port 4899 belongs to radmin. 

Update - The port is used as a backdoor, so the above is likely to be a scan for already compromised hosts.

The following are in my “no Idea” bucket.
192.148.123.44    39841    abc.def.ghi.227    32801    UDP
192.148.123.45    39841    abc.def.ghi.227    32801    UDP

Whilst the following may look like replies to an RDP session, none of the hosts can make an outbound RDP connection.
61.238.148.9    3389    abc.def.ghi.32    36199    TCP
61.238.148.9    3389    abc.def.ghi.33    16763    TCP
61.238.148.9    3389    abc.def.ghi.4    27149    TCP
61.238.148.9    3389    abc.def.ghi.4    55340    TCP

Comparing the logs from the last review and this one, it is obvious that China and Russia are still the biggest sources of attacks, however the number of attacks are down from previous months.  There is an increased amount of traffic from Turkey, Italy, Columbia and Peru.   Some of this may be explained with the reported move of RBN to other locations such as Turkey and Italy.  The increase for Columbia and Peru may have something to do with our Brazilian friends.

Thats a day in the life of my log.  If you see anything weird in your logs, or you can explain my few left over log entries (especially port 4899 traffic), let us know.

Mark H - Shearwater

Mark

391 Posts
ISC Handler
Hi Mark-
I believe I can help with the TCP 4899 entries. I see a lot of these scans, looking for radmin installations. This is the default listening port...
Dale
Anonymous

Sign Up for Free or Log In to start participating in the conversation!