Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: A day in the life of a firewall log SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms:

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:    3142    abc.def.ghi.198    80    TCP    3143    abc.def.ghi.198    443    TCP    3148    abc.def.ghi.198    1080    TCP    3145    abc.def.ghi.198    3128    TCP    3146    abc.def.ghi.198    8000    TCP    3144    abc.def.ghi.198    8080    TCP

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

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

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

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

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

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

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

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

05:42:41    59912    abc.def.ghi.136    33434    UDP
06:05:53    59912    abc.def.ghi.136    33434    UDP
06:30:54    59912    abc.def.ghi.136    33434    UDP
06:49:43    59912    abc.def.ghi.136    33434    UDP
07:17:32    59912    abc.def.ghi.136    33434    UDP
07:41:10    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)    12889    abc.def.ghi.26    33435    UDP      - Unix Traceroute    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.    50935    abc.def.ghi.235    4899    TCP    50937    abc.def.ghi.236    4899    TCP    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.    39841    abc.def.ghi.227    32801    UDP    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.    3389    abc.def.ghi.32    36199    TCP    3389    abc.def.ghi.33    16763    TCP    3389    abc.def.ghi.4    27149    TCP    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


391 Posts
ISC Handler
Dec 13th 2007
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...

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