IPs hammering Postfix

So, I've been lax in checking my logs lately, but decided to check them last night on my Linode server, which is running Ubuntu.

I'm running PSAD but for some reason, it stopped reporting scanning IPs to me. I've fixed that but it won't account for the last few months of PSAD not working.

What I'm seeing in the syslogs are connection attempts to my Postfix mail server. The server appears to have automatically dropped the traffic. I see no indication that Iptables tried to block the traffic, but this is probably due to needing to have Postfix open to the internet.

I can either rely on Postfix to continue to kill these connection attempts or I can add them to the firewall. First, I've to compile a listing of unique IPs (there were many duplicates as well as other connection information that needed to be removed).

The first thing I did was filter any logs not relevant to Postfix and redirect that output to a file. In fact what I did was grep the syslogs using the following filter: 'disconnect from unknown', which showed me every instance of Postfix disconnecting an IP from communication:

root@linode:/var/log# grep 'disconnect from unknown' syslog > /root/postfix_drops

Nov 12 05:44:12 linode postfix/smtpd[15130]: disconnect from unknown[198.206.134.152]
Nov 12 05:46:10 linode postfix/smtpd[15176]: disconnect from unknown[203.157.41.130]
Nov 12 05:57:11 linode postfix/smtpd[15366]: disconnect from unknown[91.205.167.98]
Nov 12 06:03:48 linode postfix/smtpd[15424]: disconnect from unknown[198.206.134.152]
Nov 12 06:05:49 linode postfix/smtpd[15467]: disconnect from unknown[155.208.242.236]
Nov 12 06:17:03 linode postfix/smtpd[15677]: disconnect from unknown[203.122.41.195]
Nov 12 06:17:20 linode postfix/smtpd[15677]: disconnect from unknown[112.175.103.29]
Nov 12 06:21:59 linode postfix/smtpd[15861]: disconnect from unknown[122.154.46.172]
Nov 12 06:22:20 linode postfix/smtpd[15861]: disconnect from unknown[155.208.242.236]
Nov 12 06:23:41 linode postfix/smtpd[15861]: disconnect from unknown[198.206.134.152]
Nov 12 06:35:21 linode postfix/smtpd[16335]: disconnect from unknown[122.154.46.172]
Nov 12 06:48:00 linode postfix/smtpd[16516]: disconnect from unknown[203.157.41.130]

The small snippet above shows that there are repeat offenders.  That'll need to be sorted out but we'll do that later.  Right now, all I need are the IPs.  I've to remove everything else.

I then use the following to remove a good bit of the logs:

root@linode:/var/log# nawk '{print $8}' /root/postfix_drops > /root/postfix_drops_2

The result is:

unknown[91.205.167.98]
unknown[198.206.134.152]
unknown[155.208.242.236]
unknown[203.122.41.195]
unknown[112.175.103.29]
unknown[122.154.46.172]
unknown[155.208.242.236]
unknown[198.206.134.152]
unknown[122.154.46.172]
unknown[203.157.41.130]

Note that everytime I'm making a change to the output, I'm also redirecting the output to a new file.

I then remove all instances of 'unknown' from the file (I had to add spaces between the the pointed brackets and the word "unknown", otherwise neither will render...remove the spaced for the code to work properly):

root@linode:/var/log# sed 's/\< unknown \>//g' /root/postfix_drops_2 > /root/postfix_drops_3

[155.208.242.236]
[203.122.41.195]
[112.175.103.29]
[122.154.46.172]
[155.208.242.236]
[198.206.134.152]
[122.154.46.172]
[203.157.41.130]

All that's left are removing the brackets:

root@linode:/var/log# sed 's/\[//g;s/\]//g' /root/postfix_drops_3 > /root/postfix_drops_4

203.122.41.195
112.175.103.29
122.154.46.172
155.208.242.236
198.206.134.152
122.154.46.172
203.157.41.130

I then sort the file while also only wanting to see unique IPs:

root@linode:/var/log# sort -u /root/postfix_drops_4

94.156.37.145
94.156.37.146
94.156.37.147
94.156.37.148
94.156.37.149
94.156.37.150

I started out with 394 lines and ended up with 94 unique IPs, across two syslog files.  I still have to do the archived syslog files.  I also saw that the 94 IPs show many IPs that are in sequence, which means that the culprits are trying to distribute the attacks over a range of IPs (I've posted similar attacks when analyzing SSH logs).

The resulting log file is here.

So, now, I can either be happy with how Postfix is handling the traffic or add the IPs to my firewall ruleset.  This was more of an exercise in seeing how well I could quickly assess the nature of the traffic in question and I'm happy (it was simple enough, although I'm out of practice in doing such things).

UPDATE:

1. I scrubbed the archived syslog files and the total, including those IPs I already scrubbed, is 959, and when sorted uniquely, there are 301 IPs.

2.  I added the first batch of IPs to /etc/hosts.deny for tcpwrappers to block.  I also found that I couldn't use tcpwrappers since I didn't compile postfix with tcpwrapper support, so I installed xinetd (which can wrap services inside itself with some configuration).  I'll monitor to see if the IPs will be blocked and if it doesn't work, I'll add the IPs to the firewall's ruleset.

Dshield Results From Log Donations

So, every day I submit logs to Dshield, I get a report from them with a breakdown of the submitted logs.

Here's an example:

For 2010-01-15 you submitted 496 packets from 136 sources hitting 2 targets.

Port Summary
============

Port  |  Packets  |  Sources  |  Targets  |      Service       |  Name
------+-----------+-----------+-----------+--------------------+-------------
 445 |        63 |        17 |         2 |       microsoft-ds | Win2k+ Server Message Block
 5900 |        31 |        15 |         2 |                vnc | Virtual Network Computer
 135 |        46 |        14 |         2 |              epmap | DCE endpoint resolution
 1080 |       162 |        13 |         2 |              socks | Proxy Server
  22 |        19 |        12 |         2 |                ssh | SSH Remote Login Protocol
  23 |         9 |         9 |         2 |             telnet |
 1433 |        12 |         9 |         2 |           ms-sql-s | Microsoft-SQL-Server
 3389 |        11 |         7 |         2 |   ms-term-services | MS Terminal Services
 3072 |        12 |         6 |         1 |        csd-monitor | ContinuStor Monitor Port
 4899 |         7 |         5 |         2 |             radmin | Remote Administrator default port
  25 |        20 |         5 |         2 |               smtp | Simple Mail Transfer
 3128 |        13 |         5 |         2 |         squid-http | Proxy Server
 8000 |        10 |         5 |         2 |              irdmi | iRDMI
 8080 |         7 |         4 |         2 |           http-alt | HTTP Alternate (see port 80)
 139 |         7 |         3 |         2 |        netbios-ssn | NETBIOS Session Service
 7212 |         7 |         3 |         2 |                    |
  21 |         5 |         3 |         1 |                ftp | File Transfer [Control]
  80 |         6 |         2 |         1 |                www | World Wide Web HTTP
 2967 |         2 |         2 |         1 |          ssc-agent | Symantec System Center
 1024 |         6 |         2 |         1 |                    |


Port Scanners
=============

   source     | Ports Scanned | Host Name
---------------+---------------+------------
 173.192.192.92|          10   | 173.192.192.92-static.reverse.softlayer.com
 221.192.199.35|           6   |
 78.159.112.84|           5   |
 77.223.143.18|           4   | 77-223-143-18.netdirekt.com.tr
 222.215.230.49|           4   |
 205.209.161.68|           3   |
 67.51.137.218|           2   |
 173.66.248.120|           2   | auth03.cs.net
188.132.196.173|           2   | datacenter-173-196-132-188.sadecehosting.net
 68.237.174.120|           2   | static-68-237-174-120.lsanca.fios.verizon.net
206.217.205.170|           2   | noptr.midphase.com
 66.159.229.149|           2   | netblock-66-159-229-149.dslextreme.com
222.208.183.218|           2   |
  66.160.182.5|           2   | system-5.squaw.com
   64.38.82.20|           2   |
174.129.185.251|           2   | ec2-174-129-185-251.compute-1.amazonaws.com


Source Summary
==============

   source     | hostname  |packets|targets| all pkts | all trgs | first seen
---------------+-----------+-------+-------+----------+----------+-----------
  66.160.182.5|5.squaw.com|    54 |     1 |      143 |       66 | 01-08-2010
  79.125.50.62|azonaws.com|    33 |     1 |    14083 |       94 | 01-11-2010
 79.125.39.245|azonaws.com|    27 |     1 |     5974 |       92 | 01-11-2010
 174.129.93.137|azonaws.com|    27 |     1 |    16623 |      102 | 01-06-2010
174.129.161.206|azonaws.com|    21 |     1 |     8258 |       99 | 01-11-2010
174.129.137.234|azonaws.com|    15 |     1 |     2328 |       90 | 01-14-2010
 221.192.199.35|           |    13 |     1 |    63162 |     2825 | 01-05-2010
  79.125.44.37|azonaws.com|    12 |     1 |     6155 |       88 | 01-12-2010
 173.192.192.92|ftlayer.com|    10 |     1 |   287815 |    25717 | 12-31-2009
 222.215.230.49|           |     9 |     2 |   225112 |     6288 | 05-28-2008
 79.125.32.165|azonaws.com|     9 |     1 |     2346 |       89 | 01-14-2010
 94.59.233.125|           |     7 |     1 |       29 |       13 | 01-15-2010
 77.223.143.18|rekt.com.tr|     7 |     1 |   120123 |    20906 | 12-28-2009
 78.159.112.84|           |     6 |     1 |     7356 |     3206 | 01-15-2010
188.132.196.173|hosting.net|     6 |     1 |     2606 |     1735 | 01-13-2010
118.161.243.145|c.hinet.net|     6 |     1 |       54 |        8 | 01-15-2010
   64.38.82.20|           |     5 |     1 |      894 |      446 | 01-15-2010
 205.209.161.68|           |     5 |     1 |      278 |      245 | 01-15-2010
204.236.194.181|azonaws.com|     5 |     1 |     8563 |       95 | 01-10-2010
204.236.244.234|azonaws.com|     4 |     1 |    10215 |      155 | 01-05-2010

All of this is valuable, and I can sometimes tune the IDS and FW based on the findings of these reports. There are other freeware tools that can do this type of data crunching, but I like the fact that if I'm donating logs, I'm getting a analysis report in return.

Now, the concern is that there's a lot of source IPs that appear to be owned by Amazon (Amazon Web Services). I'm hoping that most of these aren't EC2 hosts. If so, that indicates that Amazon has a security or abuse issue (or a combination of both). I'm hesitant to mention this to ISC since this may well be a trivial concern for them. Regardless of perception, I still believe this is more than likely an issue that should be pursued.

FW Log Check

Doing a remote check of FW activity, I've found that the FW has blocked MANY IPs in the last 9 days:

[root@delly ~]# zcat /var/log/bruteforce.0908* | wc -l
11424

Those are all unique IPs. Out of curiosity, I checked July's and May's logs:

[root@delly ~]# zcat /var/log/bruteforce.0907* | wc -l
40511

[root@delly ~]# zcat /var/log/bruteforce.0906* | wc -l
10121

All I can say is, "WOW!!" There was a HUGE spike in July (maybe due to summer vacation of most kids). Unfortunately, my logs don't go back beyond June.

I'm curious as to how August will be but I can already see that the number will be high. I'll update the blog as I as continue to watch.

[EDIT: I checked August's count and it is below:

zcat /var/log/bruteforce.0908* | wc -l
40761

September (so far) is:

zcat /var/log/bruteforce.0909* | wc -l
20186

I think I'll start scripting this command to run every week so that I can start trending.[09/15/2009]]




[Edit:


So, it is 7/19/2011.  I will try to graph what I'm about to provide, but here's what I have after zcatting some .gz files:

2011:

[root@delly ~]# zcat /var/log/bruteforce.1107* | wc -l

   58589

[root@delly ~]# zcat /var/log/bruteforce.1106* | wc -l

   91736

[root@delly ~]# zcat /var/log/bruteforce.1105* | wc -l

   93765

[root@delly ~]# zcat /var/log/bruteforce.1104* | wc -l

   89521

[root@delly ~]# zcat /var/log/bruteforce.1103* | wc -l

   91337

[root@delly ~]# zcat /var/log/bruteforce.1102* | wc -l

   81415

[root@delly ~]# zcat /var/log/bruteforce.1101* | wc -l

   89971

2010:

[root@delly ~]# zcat /var/log/bruteforce.1012* | wc -l

   90024

[root@delly ~]# zcat /var/log/bruteforce.1011* | wc -l

   87120

[root@delly ~]# zcat /var/log/bruteforce.1010* | wc -l

   89748

[root@delly ~]# zcat /var/log/bruteforce.1009* | wc -l

   85585

[root@delly ~]# zcat /var/log/bruteforce.1008* | wc -l

   84738

[root@delly ~]# zcat /var/log/bruteforce.1007* | wc -l

   66438

[root@delly ~]# zcat /var/log/bruteforce.1006* | wc -l

   62905

[root@delly ~]# zcat /var/log/bruteforce.1005* | wc -l

   63421

[root@delly ~]# zcat /var/log/bruteforce.1004* | wc -l

   60478

[root@delly ~]# zcat /var/log/bruteforce.1003* | wc -l

   59006

[root@delly ~]# zcat /var/log/bruteforce.1002* | wc -l

   44380

[root@delly ~]# zcat /var/log/bruteforce.1001* | wc -l

   45392

2009:

[root@delly ~]# zcat /var/log/bruteforce.0912* | wc -l

   48281

[root@delly ~]# zcat /var/log/bruteforce.0911* | wc -l

   45127

[root@delly ~]# zcat /var/log/bruteforce.0910* | wc -l

   44254

[root@delly ~]# zcat /var/log/bruteforce.0909* | wc -l

   40185

[root@delly /var/log]# zcat bruteforce.* |wc -l

 1704809

[root@delly /var/log]# zcat bruteforce.* |wc -l | uniq

 1704809

]

Log Correlation

I thought I'd talk about the importance of log correlation. For instance, you've found that someone is continually pinging your server. You want to see if your box is responding to the pings. Usually, you'll know right off, since most people know if their firewall was configured to block pings...I'm just using pings as a quick example, though. Log correlation usually consists of checking, for instance, web server logs against firewall logs, or Snort logs against firewall and web server logs. This helps you understand what suspicious activity is actually doing and if your server/workstation responded (and how it responded, if it did).

I run Snort on a server, along with a web server, which is firewalled with IPTables. I have Snort report what it sees to a MySQL database, although it does record captures to a PCAP file locally. I also run Modsecurity, an application firewall that is designed to sniff and possibly block traffic going to/from web servers, mainly Apache. So, I've a ton of logs that I can correlate: Snort, Apache, IPTables, and Modsecurity logs.

We'll pick something easy. In fact, I'll fabricate some logs by generating some false alerts. I'll use 'wget', to visit my website. Keep in mind that what you see below gives you the advantage...you know what you're doing and looking for when we soon check the logs. This won't be the case when some stranger or worm hits your firewall or web server (or any other application server).

-bash-2.05b$ wget wigglit.ath.cx/root.exe
--23:24:05-- http://wigglit.ath.cx/root.exe
=> `root.exe'
Resolving wigglit.ath.cx... 66.160.141.30
Connecting to wigglit.ath.cx|66.160.141.30|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:24:06 ERROR 404: Not Found.

-bash-2.05b$

I used root.exe because there is an old vulnerability was was used to exploit the CodeRed worm of old. Now, let's check the web server's logs. I've tail'd my logs:

root@starchild:/var/log/apache# tail -f -n 100 access_log
12.123.12.123 - - [15/Sep/2007:23:34:35 -0400] "GET /root.exe HTTP/1.0" 404 202
12.123.12.123 - - [15/Sep/2007:23:34:35 -0400] "GET /root.exe HTTP/1.0" 404 202 "-" "Wget/1.10.2"

You see that the communcation was rejected (404 code), as the traffic was deemed forbidden by the web server. This is usually a good indication, as the server didn't respond favorably to the attack.

Now, let us check the firewall logs. We already know that the firewall allowed the traffic, since the web server responded with a 404...if the traffic was being blocked, there would be no record of the attack in the logs, because the firewall would have intercepted the traffic before it reached the web server. We're checking the firewall logs just to be sure this guy hasn't done anything else that the web server didn't see:

Sep 12 17:28:34 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=34557 DF PROTO=TCP SPT=46656 DPT=10083 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:28:44 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=18168 DF PROTO=TCP SPT=40091 DPT=449 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:28:44 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=27053 DF PROTO=TCP SPT=36295 DPT=5060 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:28:54 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=29291 DF PROTO=TCP SPT=47590 DPT=342 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:28:54 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=11788 DF PROTO=TCP SPT=43604 DPT=1519 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:04 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=17600 DF PROTO=TCP SPT=32783 DPT=577 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:04 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=51338 DF PROTO=TCP SPT=47879 DPT=18187 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:14 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=58520 DF PROTO=TCP SPT=41983 DPT=517 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:14 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=20255 DF PROTO=TCP SPT=53355 DPT=1986 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:24 starchild kernel: Connection attempt (PRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=28213 DF PROTO=TCP SPT=38543 DPT=978 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:24 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=60 TOS=0x00 PREC=0x00 TTL=56 ID=10244 DF PROTO=TCP SPT=45624 DPT=11371 WINDOW=5840 RES=0x00 SYN URGP=0
Sep 12 17:29:37 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=28 TOS=0x00 PREC=0x00 TTL=42 ID=53002 PROTO=ICMP TYPE=8 CODE=0 ID=10683 SEQ=16615
Sep 15 17:38:25 starchild sshd[8455]: Accepted publickey for ron from ::ffff:12.123.12.123 port 33557 ssh2
Sep 15 23:21:08 starchild kernel: ICMP-request: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=12.123.12.123 DST=66.160.141.30 LEN=84 TOS=0x00 PREC=0x00 TTL=55 ID=40988 PROTO=ICMP TYPE=8 CODE=0 ID=614 SEQ=0

Quite a bit of stuff, huh? This looks to be a port scan! This is something that we didn't see in the Apache logs! Good thing we checked! Looks like this IP needs to be blocked with IPTables (which we won't do in this exercise).

Sadly, nothing shows in the Modsecurity logs, but we've enough information already. What about Snort? Because I've PCAP files, the search becomes a bit more involved. I'll spare the intimate details, but this is what we see:

[**] [1:1256:9] WEB-IIS CodeRed v2 root.exe access [**]
[Classification: Web Application Attack] [Priority: 1]
09/15-23:34:35.708546 0:C:DB:F5:90:0 -> FE:FD:40:3E:E7:DC type:0x800 len:0xB0
12.123.12.123:52753 -> 66.160.141.30:80 TCP TTL:56 TOS:0x0 ID:51589 IpLen:20 DgmLen:162 DF
***AP*** Seq: 0xAF32BB68 Ack: 0x3F319F7A Win: 0xFFFF TcpLen: 32
TCP Options (3) => NOP NOP TS: 288652007 1521931210
[Xref => http://www.cert.org/advisories/CA-2001-19.html]

23:34:35.708546 00:0c:db:f5:90:00 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 176: IP (tos 0x0, ttl 56, id 51589, offset 0, flags [DF], length: 162) 12.123.12.123.52753 > 66.160.141.30.80: P [tcp sum ok] 2939337576:2939337686(110) ack 1060216698 win 65535
0x0000: fefd 403e e7dc 000c dbf5 9000 0800 4500 ..@>..........E.
0x0010: 00a2 c985 4000 3806 56c0 47b2 0aa0 42a0 ....@.8.V.G...B.
0x0020: 8d1e ce11 0050 af32 bb68 3f31 9f7a 8018 .....P.2.h?1.z..
0x0030: ffff e9c5 0000 0101 080a 1134 7ae7 5ab6 ...........4z.Z.
0x0040: d3ca 4745 5420 2f72 6f6f 742e 6578 6520 ..GET./root.exe.
0x0050: 4854 5450 2f31 2e30 0d0a 5573 6572 2d41 HTTP/1.0..User-A
0x0060: 6765 6e74 3a20 5767 6574 2f31 2e31 302e gent:.Wget/1.10.
0x0070: 320d 0a41 6363 6570 743a 202a 2f2a 0d0a 2..Accept:.*/*..
0x0080: 486f 7374 3a20 7769 6767 6c69 742e 6174 Host:.wigglit.at
0x0090: 682e 6378 0d0a 436f 6e6e 6563 7469 6f6e h.cx..Connection
0x00a0: 3a20 4b65 6570 2d41 6c69 7665 0d0a 0d0a :.Keep-Alive....

The first is the Snort alert file...this is a fast alert, with minimal detail (no packet capture). The second section is the full alert, including packet capture. It is also garbled (due to the hex code and the fact that this blog has issues with formatting) Note that my logs show no response. Apparently, my Snort install doesn't have a 404 signature. Again, the fact that we can correlate helps me when my Snort install lacks the data that I may have needed. I was able to look at the Apache logs to see the 404 when my Snort logs didn't show the return traffic.

Well, this concludes our chat about correlating existing logs. Note that any log files can be correlated. Correlation can also assist in tracking down network issues or issues with, for instance, a faulty Snort install (ahem). Although this discussion focused more on security, hopefully this helps someone understand their network or software architecture also.

`

Did some ##slackware log archiving...

Yeah, I had to do some archiving of the logs, as diskspace usage was at 96%. I didn't just archive the channel logs, but also archived my snort and web logs. About the only thing I haven't archived yet are the modsecurity logs (will do that sometime this weekend). Currently, the host's drive space is currently at 74%. The channel logs are still in place, but I've crunched the logs into monthly tar.bz2 files. This renders the logs unsearchable by google (yeah, this sucks), but I had to compromise...they are still downloadable, just not searchable. So, if you need them, they are there for download. Once you download them, you can grep each tar.bz2 after uncompressing them. Hopefully, Google still has the logs cached so that a person searching for an item can still see the cached files. Maybe I'll purchase more drive space so that I can host the logs in an untarred and uncompressed format in the near future.

Speaking of the channel, there has again been some ruckus about someone being banned 'unduly'. People have to recognize that moderating a channel does come at a price. One of these prices is the fact that people can't visit their frustrations on the channel. An individual visited the channel highly upset that Pat froze Slackware-current relating to issues with both the 2.4 and 2.6 kernel. Instead of following advice to follow up with Pat, he continues to vent on the channel, causing a rather heated flame war over something trivial. He was +q'd (meaning his speech was removed), but he evaded +q. He was then "removed" (meaning he was booted, not kicked, from the channel), but came back in the channel with the same attitude. He was then banned for 30 days. Anyone who evades moderation will automatically get a ban. Why 30 and not 7 days? Because, behind the scenes, in private message, the individual was very argumentive and I didn't feel like dealing with him 2 days later for the same offense. After reading the logs, someone had the gall to mention in the channel that the ban was unwarranted...this person thought that the individual was banned because of his views...WRONG. Read the channel guidelines. It states specifically that any +q/ban evasion will be dealt with in a rather harsh manner. Many people do not realize that the ops will never be able to please every single person's views in the channel. I've been doing this a LONG time (4+ years) and no matter if I just sit there and let the channel run itself or if I step in and boot someone, someone ALWAYS complains. It's a no-brainer for me: moderation is what it is. You can take it or leave it. There aren't too many channels on Freenode that aren't moderated. By nature, moderation pretty much means you can't state everything you feel, especially when it ruins the continuity of the channel chat. Is this an oxymoron, especially since Freenode is inhabited mostly by coders and free-thinkers? Every discussion, whether its in real-life in a conference or in someone's home or online on a forum or in a chat room/channel, will have some type of moderation. So, going forward, I'll not be including comments to the ban messages, as this adds confusion to why the person was banned. Really, the channel doesn't need to know why said person was banned after the fact. The ban messages are for the person being banned and it was designed that way by the people who set up the IRC specifications. If you want to know why someone was banned, speak with them directly or read the logs. I've no time to hold some lengthly dialog with someone who thinks that everyone should join an IRC channel and unload their frustrations. I try to think as objectively as possible on anything that goes on in the channel and to be quite honest, there's been a ton of bitching about the ops lately. When I see the non-ops quit pushing the ops' buttons, I'll take them more seriously and get more active in seeing to their needs...but the bellyaching has to stop first. Seriously, its usually the same people bitching about their rights being violated, and if its not the same people, there's usually some association.