Just ordered another machine

Yeah, yeah, I've ordered yet ANOTHER machine:

Abit NF-M2SV GeForce 6100 Socket AM2 Motherboard
AMD Athlon 64 X2 4400+ Socket AM2 CPU
Crucial 1024MB PC4200 DDR2 533MHz (X2)
Seagate 250GB Serial ATA w/NCQ 7200/8MB/SATA-3G
Power Up Silver 5511 ATX Mid-T Case w/450w

All for $199 after $30 in rebates. Note that there's no CPU heatsink/fan, no OS, no CD/DVD burner, and no vidcard (although there's an integrated one on the motherboard, which may get me through the testing/burn-in phase).

I've just ordered an Arctic Cooling Freezer 64 LP CPU Cooler for $25 from Microcenter. I'll order a CD/DVD burner in another week, and within the next month, I'll install a new vidcard. I don't know what OS I'll utilize yet...maybe Linux, but more than likely Windows (only I don't want to buy Vista [or XP, really]).

At this point, the barebones I ordered last year is still the better computer, but I spent quite a bit more for it. Until the new one is up and running, I'm also using its 2gb of RAM in the older computer, for a total of 3gb of RAM (COD4 flies during loading!).

This is the deal I saw on Tigerdirect.com that made me purchase this machine.

Verizon hit with GPL copyright lawsuit over router software

This article is old but interesting. I've this router and I've Verizon's FIOS service. Not long after purchasing this service, I perused Actiontec's website and had seen that they utilized Linux (this is, specifically, an issue with Verizon not including the source code for BusyBox to its customers, per v2 of the GPL) as the firmware for this router. I also saw that Verizon offered firmware versions for this router on their pages. I didn't think that they'd not release their software as GPL, though. I think it was either forgotten or GPL was taken for granted (because GPL software is usually free).

Anyways, this is a good read.

Port 33435

I'm doing some additional research on this ISC SANS diary entry. It appears that I have a prominent host attempting to connect to port 33435/UDP. The traffic is showing in my FW logs but I wanted to get a sniff going to provide to ISC.sans.org.

I used the following to capture the traffic:

tcpdump -Xvvnnes -0 -i eth0 -w /tmp/isc-inv/isc-inv1 port 14323 or port 33435

I got seven hits over several days:

root@starchild:~# screen -r 32692
7 packets received by filter
0 packets dropped by kernel

root@starchild:~# tcpdump -Xvvnnes -0 -r /tmp/isc-inv/isc-inv1
reading from file /tmp/isc-inv/isc-inv1, link-type EN10MB (Ethernet)
20:59:13.181494 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 659, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0293 0000 0111 ae43 d834 6104 E..........C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
20:59:54.435063 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 2451, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0993 0000 0111 a743 d834 6104 E..........C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
21:00:35.451099 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 4243, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 1093 0000 0111 a043 d834 6104 E..........C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
21:01:17.435358 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 6035, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 1793 0000 0111 9943 d834 6104 E..........C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
21:01:58.435072 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 7827, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 1e93 0000 0111 9243 d834 6104 E..........C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
21:02:40.432363 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 9619, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 2593 0000 0111 8b43 d834 6104 E...%......C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG
21:03:21.431071 00:0c:db:fc:8b:59 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 46: (tos 0x0, ttl 1, id 11411, offset 0, flags [none], proto UDP (17), length 32) 216.52.97.4.11941 > xxx.xxx.xxx.xxx.33435: [udp sum ok] UDP, length 4
0x0000: 4500 0020 2c93 0000 0111 8443 d834 6104 E...,......C.4a.
0x0010: 42a0 8d1e 2ea5 829b 000c 8f00 6956 4d47 B...........iVMG

I've not yet taken the time to delve into the capture (will have some time when I get home today).

BASH script to parse FW logs

I've created a BASH script that parses my FW logs to show me the activity in one screen dump and also show me the total hit count per log file (I have my FW logs show in /var/log/messages).

The script is below:

root@starchild:/tmp# cat fwlogsearch2.sh
#!/bin/bash

# Searches FW logs on Linode, which are contained in /var/log/messages* files
#
# v0.1: couldn't get the script to work but could get the raw grep command to run flawlessly manually. Changed the "grep "$ip" /var/log/messages*" to "grep "$1" /var/log/messages*" and it worked! Same for the wordcount line.

function search {
local ip #ip is local to the function
echo "Searching... "
echo " "
grep "$1" /var/log/messages*
#cat /var/log/messages* | grep $ip
wordcount=`grep -c "$1" /var/log/messages*`
#wordcount=`cat /var/log/messages* | grep $ip | wc -l`
echo " "
echo "The number of instances this IP shows in $wordcount"
}
echo " "
echo " "
echo "Type in a number to search. Output will be dumped to stdout:"
read number
value_returned=$(search $number)
echo "$value_returned"
echo " "
echo " "

The results look like:

root@starchild:/tmp# ./fwlogsearch2.sh


Type in a number to search. Output will be dumped to stdout:
216.218.230.82
Searching...

/var/log/messages:Jun 3 05:23:30 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=18621 DF PROTO=TCP SPT=1121 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0
/var/log/messages:Jun 3 05:23:33 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=19854 DF PROTO=TCP SPT=1121 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0
/var/log/messages:Jun 21 15:57:52 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=3853 DF PROTO=TCP SPT=45085 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0
/var/log/messages:Jun 21 15:57:55 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=5091 DF PROTO=TCP SPT=45085 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0
/var/log/messages.1:May 29 22:08: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=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=28369 DF PROTO=TCP SPT=29144 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0
/var/log/messages.1:May 29 22:08:47 starchild kernel: Connection attempt (UNPRIV): IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f5:90:00:08:00 SRC=216.218.230.82 DST=xxx.xxx.xxx.xxx LEN=48 TOS=0x00 PREC=0x00 TTL=125 ID=29195 DF PROTO=TCP SPT=29144 DPT=5900 WINDOW=65535 RES=0x00 SYN URGP=0

The number of instances this IP shows in /var/log/messages:4
/var/log/messages.1:2
/var/log/messages.2:0
/var/log/messages.3:0
/var/log/messages.4:0


root@starchild:/tmp#

The plan is to add more functionality to this simple script (yeah, I'm enthused because I don't normally script things and rarely get it right without some type of extreme research or problem).

Regarding Snort, I've recently added the following sigs to all three of my IDSs (regarding detecting Kraken activity):

# Kraken sigs (Emerging Threats sigs)
alert tcp $HOME_NET 1024: -> $EXTERNAL_NET 447 (msg:"ET CURRENT_EVENTS Bobax/Kraken/Oderoor TCP 447 CnC? Channel Initial Packet Outbound"; flow:established; dsize:24; threshold:type threshold, track by_src, count 2, seconds 360; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008103; rev:1;)
alert udp $HOME_NET 1024: -> $EXTERNAL_NET 447 (msg:"ET CURRENT_EVENTS Bobax/Kraken/Oderoor UDP 447 CnC? Channel Initial Packet Outbound"; dsize:24; threshold:type threshold, track by_src, count 2, seconds 360; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008104; rev:1;)
alert udp $EXTERNAL_NET 447 -> $HOME_NET 1024: (msg:"ET CURRENT_EVENTS Bobax/Kraken/Oderoor UDP 447 CnC? Channel Initial Packet Inbound"; dsize:24; threshold:type threshold, track by_src, count 2, seconds 360; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008105; rev:1;)
alert tcp $EXTERNAL_NET 447 -> $HOME_NET 1024: (msg:"ET CURRENT_EVENTS Bobax/Kraken/Oderoor TCP 447 CnC? Channel Initial Packet Inbound"; flow:established; dsize:24; threshold:type threshold, track by_src, count 2, seconds 360; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008106; rev:1;)
alert udp $EXTERNAL_NET 447 -> $HOME_NET 1024: (msg:"ET CURRENT_EVENTS Possible Bobax/Kraken/Oderoor UDP 447 CnC? Channel Inbound"; threshold:type threshold, track by_src, count 5, seconds 60; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008107; rev:1;)
alert tcp $EXTERNAL_NET 447 -> $HOME_NET 1024: (msg:"ET CURRENT_EVENTS Possible Bobax/Kraken/Oderoor TCP 447 CnC? Channel Inbound"; flow:established; threshold:type threshold, track by_src, count 5, seconds 60; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008108; rev:1;)
alert udp $HOME_NET 1024: -> $EXTERNAL_NET 447 (msg:"ET CURRENT_EVENTS Possible Bobax/Kraken/Oderoor UDP 447 CnC? Channel Outbound"; threshold:type threshold, track by_src, count 5, seconds 60; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008109; rev:1;)
alert tcp $HOME_NET 1024: -> $EXTERNAL_NET 447 (msg:"ET CURRENT_EVENTS Possible Bobax/Kraken/Oderoor TCP 447 CnC? Channel Outbound"; flow:established; threshold:type threshold, track by_src, count 5, seconds 60; classtype:trojan-activity; reference:url,doc.emergingthreats.net/bin/view/Main/OdeRoor; sid:2008110; rev:1;)

I doubt I'll see anything, but I'm a bit concerned, as this malware affects Windows systems and is supposed to alert on non-internet activity...I do have Windows machines on my LAN.

I also conducted some research on this ISC SANS diary entry. It appears that I have a prominent host attempting to connect to port 33435/UDP. I counted 50 FW log hits from maybe 4 different IPs, with one IP being more active than the rest.

root@starchild:/tmp# cat /var/log/messages* | grep "PT=33435" | wc -l
50

root@starchild:/tmp# whois 216.52.97.4
Internap Network Services PNAP-8-98 (NET-216-52-0-0-1)
216.52.0.0 - 216.52.255.255
InterNAP Network Services, PNAP-OCY PNAP-OCY-INAP-BB-1 (NET-216-52-96-0-1)
216.52.96.0 - 216.52.97.255

Looking at my logs, I also see 33436/UDP, 33437/UDP, 33438/UDP, and 33439/UDP being hit by hosts from PNAP hosts...strange...I'm thinking about blocking that whole huge range.

Anyways, I thought some of this would be cool to share.

Until next time!

Firekeeper, an IDPS system (plugin) for Firefox

http://isc.sans.org/diary.html?storyid=2403 explains Firekeeper, an IDS/IPS Firefox browser plugin.

I'm running it on two machines that run Slackware (versions 11.0 and 12.0). I may throw it on my work machine (which runs Windows XP), but that may be a bit daring.

Firekeeper's homepage is at http://firekeeper.mozdev.org/installation.html

Please share your experiences with this plugin...this is a great idea and may be a Holy Grail for malware that infects via browsers.

Also, I've found what may be a good security site, http://www.megasecurity.org/Main.html. It may take me awhile to read, as it has tons of data, it seems.

Kernel Upgrade

I've done the following (copy/paste):

root@slackbox:~/kernel-patches# ls
kernel-generic-2.6.21.5-i486-2_slack12.0.tgz
kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
kernel-huge-2.6.21.5-i486-2_slack12.0.tgz
kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
root@slackbox:~/kernel-patches# md5sum kernel-*
ebf025aa30af925ac6817fe58811e921 kernel-generic-2.6.21.5-i486-2_slack12.0.tgz
e35c66f2d765a221b509f1b7b463c9fe kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
3f9e3783dd7d799a277ec3e79e8bb82d kernel-huge-2.6.21.5-i486-2_slack12.0.tgz
0503193191731bba693ed6ce35b8c26d kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
root@slackbox:~/kernel-patches#
root@slackbox:~/kernel-patches#
root@slackbox:~/kernel-patches#
root@slackbox:~/kernel-patches# upgradepkg kernel-generic-2.6.21.5-i486-2_slack12.0.tgz

+==============================================================================
| Upgrading kernel-generic-2.6.21.5-i486-2 package using ./kernel-generic-2.6.21.5-i486-2_slack12.0.tgz
+==============================================================================

Pre-installing package kernel-generic-2.6.21.5-i486-2_slack12.0...

Removing package /var/log/packages/kernel-generic-2.6.21.5-i486-2-upgraded-2008-02-21,19:59:56...

Installing package kernel-generic-2.6.21.5-i486-2_slack12.0...
PACKAGE DESCRIPTION:
kernel-generic: kernel-generic (a general purpose single processor Linux kernel)
kernel-generic:
kernel-generic: This is a Linux kernel with built-in support for most IDE controllers.
kernel-generic: For filesystem support, or if you need to load support for a SCSI or
kernel-generic: other controller, then you'll need to load one or more kernel modules
kernel-generic: using an initial ramdisk, or initrd. For more information about
kernel-generic: creating an initrd, see the README.initrd file in the /boot directory.
kernel-generic:
Executing install script for kernel-generic-2.6.21.5-i486-2_slack12.0...

Package kernel-generic-2.6.21.5-i486-2 upgraded with new package ./kernel-generic-2.6.21.5-i486-2_slack12.0.tgz.

root@slackbox:~/kernel-patches# upgradepkg kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0.tgz

+==============================================================================
| Upgrading kernel-generic-smp-2.6.21.5_smp-i686-2 package using ./kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
+==============================================================================

Pre-installing package kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0...

Removing package /var/log/packages/kernel-generic-smp-2.6.21.5_smp-i686-2-upgraded-2008-02-21,20:01:00...

Installing package kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0...
PACKAGE DESCRIPTION:
kernel-generic-smp: kernel-generic-smp (a general purpose SMP Linux kernel)
kernel-generic-smp:
kernel-generic-smp: This is a Linux kernel with built-in support for most disk
kernel-generic-smp: controllers. To use filesystems, or to load support for a SCSI or
kernel-generic-smp: other controller, then you'll need to load one or more kernel
kernel-generic-smp: modules using an initial ramdisk, or initrd. For more information
kernel-generic-smp: about creating an initrd, see the README.initrd file in the /boot
kernel-generic-smp: directory.
kernel-generic-smp:
kernel-generic-smp: SMP is "Symmetric multiprocessing", or multiple CPU/core support.
kernel-generic-smp:
Executing install script for kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0...

Package kernel-generic-smp-2.6.21.5_smp-i686-2 upgraded with new package ./kernel-generic-smp-2.6.21.5_smp-i686-2_slack12.0.tgz.

root@slackbox:~/kernel-patches# upgradepkg kernel-huge-2.6.21.5-i486-2_slack12.0.tgz

+==============================================================================
| Upgrading kernel-huge-2.6.21.5-i486-2 package using ./kernel-huge-2.6.21.5-i486-2_slack12.0.tgz
+==============================================================================

Pre-installing package kernel-huge-2.6.21.5-i486-2_slack12.0...

Removing package /var/log/packages/kernel-huge-2.6.21.5-i486-2-upgraded-2008-02-21,20:01:34...

Installing package kernel-huge-2.6.21.5-i486-2_slack12.0...
PACKAGE DESCRIPTION:
kernel-huge: kernel-huge (a fully-loaded single processor Linux kernel)
kernel-huge:
kernel-huge: This is a Linux kernel with built-in support for most disk controllers
kernel-huge: and filesystems. If you're looking for a more stripped down kernel
kernel-huge: (this one contains everything but the kitchen sink ;-), then install
kernel-huge: the kernel-generic from the /boot directory along with an initrd to
kernel-huge: load support for your boot device and filesystem. For instructions
kernel-huge: on the initrd, see README.initrd in the /boot directory.
kernel-huge:
Executing install script for kernel-huge-2.6.21.5-i486-2_slack12.0...

Package kernel-huge-2.6.21.5-i486-2 upgraded with new package ./kernel-huge-2.6.21.5-i486-2_slack12.0.tgz.

root@slackbox:~/kernel-patches# upgradepkg kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0.tgz

+==============================================================================
| Upgrading kernel-huge-smp-2.6.21.5_smp-i686-2 package using ./kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0.tgz
+==============================================================================

Pre-installing package kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0...

Removing package /var/log/packages/kernel-huge-smp-2.6.21.5_smp-i686-2-upgraded-2008-02-21,20:02:13...

Installing package kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0...
PACKAGE DESCRIPTION:
kernel-huge-smp: kernel-huge-smp (a fully-loaded SMP Linux kernel)
kernel-huge-smp:
kernel-huge-smp: This is a Linux kernel with built-in support for most disk
kernel-huge-smp: controllers. If you're looking for a more stripped down kernel
kernel-huge-smp: (this one contains everything but the kitchen sink ;-), then install
kernel-huge-smp: the kernel-generic-smp in the /boot directory along with an initrd to
kernel-huge-smp: load support for your boot device and filesystem. For instructions
kernel-huge-smp: on the initrd, see README.initrd in the /boot directory.
kernel-huge-smp:
kernel-huge-smp: SMP is "Symmetric multiprocessing", or multiple CPU/core support.
kernel-huge-smp:
Executing install script for kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0...

Package kernel-huge-smp-2.6.21.5_smp-i686-2 upgraded with new package ./kernel-huge-smp-2.6.21.5_smp-i686-2_slack12.0.tgz.

root@slackbox:~/kernel-patches#

root@slackbox:~/kernel-patches# lilo
Fatal: VolumeID read error: sector 0 of /dev/sda not readable

OUCH!

I read this: http://unixadmintalk.com/f11/lilo-fails-dev-sda-not-readable-65533/

It appears to help:

root@slackbox:~/kernel-patches# lilo
Warning: bypassing VolumeID scan of drive flagged INACCESSIBLE: /dev/sda
Warning: The boot sector and map file are on different disks.
Added Windows *
Added Linux
2 warnings were issued.

Will reboot then test to see if this upgraded kernel is still vulnerable...

Kernel vulnerabilities affecting Linux machines

Whenever there's some kernel-level vulnerability, it seems that the whole community goes ape-crap over something that should be a no-brainer.

The recent vulnerability is documented here:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0010
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0163
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0600

So, what's the big deal? It is a locally exploitable vulnerability. Everyone is acting like its the end of the world. Why? Are people actually giving people access to their systems that they don't trust? Why am I not worried? Because I want to learn things about security. Think about this for a second: in an enterprise environment, you're not going to be able to always apply kernel patches to production machines. You're not always going to be able to test by standing up a development environment. There is not always going to be one distribution used and not every platform will share the same hardware. What's readily apparent is that security should always be applied in layers. This means that no one should be accessing machines on your local network that you can't trust. If someone is not trustworthy, you should always be worrying about what they're doing on the network, instead of only when kernel-level vulnerabilities are discovered.

Does that lessen the responsibility of the system admins? No, but if everyone thought less of patching applications and more as a security administrator, the workload of the system administrator would probably be less. What I'm seeing in chatrooms and forums is this: "Oh shit...this exploit gives local root access...I have to apply this patch NOW!!" Someone said something similar in an IRC channel that I frequent:

SiegeX - I dunno, having a local root exploit (which ive tested with existing code) on a box that runs any sort of service would worry the hell out of me
W|GGL|T - SiegeX: in all actuality, you could have root exploits locally all over the place and you'd not know about it
SiegeX - and I probably do, but its no excuse for not patching the ones I do
W|GGL|T - security is more than just patching....in a corporate scenario, you have to balance out if you can even apply the patch....you bet your ass we're not going to take down a production system that has a localized vulnerability if it is indeed only local
SiegeX - heh, step 1) su root 2) cat /etc/shadow 3) ??? 4) profit
W|GGL|T - its called mitigation
W|GGL|T - if security is applied in layers, certain risks are lessened
SiegeX - W|GGL|T: why wouldnt you apply the patch on a production clone for testing purposes and do regression testing on that to make sure everything is a-ok before moving it over ?
W|GGL|T - SiegeX: if the corporate network has 10 different security layers, the need for immediate patching is small. sure, we'd patch but we'd do it in a sane manner
SiegeX - W|GGL|T: since you're into the corp security let me ask you if there was a solid way for a corp to not allow outbound tunnels while still allowing https?
SiegeX - s/was/is
W|GGL|T - SiegeX: nope, but then again, those who don't follow corporate policy need to be fired
SiegeX - afaik, if you tunnel over https, not even a L7 filter will look at it funny since the connection setup looks legit. Only thing i can think of is traffic analysis
W|GGL|T - there are always checks and balances
W|GGL|T - SiegeX: hrmm....there is IDS
W|GGL|T - and there is also a concept called behavioral analysis

The conversation dies shortly thereafter. I do think SiegeX was thinking in a sane manner. What he's worried about is someone either breaking into the machine or someone from inside tunneling and somehow letting an unauthorized user into the network. Layered security addresses both of those concerns. You lock down your firewall to only allow certain traffic in/out of the network. You set up either an IDS or an IPS to either log suspicious traffic or actively log and block unusual traffic. Yes, IDS/IPS can detect layer-7 traffic anomalies (but only if there are rules patterned after the unwanted traffic). Those people that tunnel out of the corporate network can be either reprimanded or handed their walking papers...that problem can be solved rather quickly.

I take it that SiegeX didn't want to deal with traffic analysis. That's the only way ANYONE is going to see stuff. Think about it. When you look at firewall logs, you're looking at logged traffic. If you're looking at your system logs (for instance, /var/log/secure, /var/log/faillog, or /var/log/messages (which may contain snort log and/or firewall log entries)), you're pretty much conducting traffic analysis. This should be within the realm of every system admin.

The easier way would be to address the kernel vulnerability, but I've also seen places that will NOT update a kernel unless absolutely necessary. The train-of-thought is that they wanted absolute stability and that stability overruled patch updating. What type of organization would think in this manner? Think of organizations that deal in national flight systems.

So, when am I going to apply a patched kernel? I don't know...my LAN is so layered with security that its not a hot priority for me to apply this patch.

Lastly, here's a Secunia link of the vulnerabilities in question: http://secunia.com/advisories/28835/

Mystery infestation strikes Linux/Apache Web sites

http://www.linux.com/feature/125548

"According to a press release issued earlier this month by Finjan, a security research firm, compromised Web servers are infecting thousands of visitors daily with malware that turns their Windows machines into unwitting bots to do the bidding of an as yet unidentified criminal organization. Security firms ScanSafe and SecureWorks have since added their own takes on the situation, though with varying estimates on the number of sites affected. All reports thus far say the compromised servers are running Linux and Apache."

What's New?

What's new for 2008?

I've quit smoking. The last time I smoked was on the 31st of Dec 2007. I've also enrolled in my company's benefits as a non-smoker (as an incentive and as punishment, as a smoker who has claimed non-smoker status can be disciplined or fired). I've been using smoking cessation aids (ie, Nicoderm and other aids).

Other than that, nothing is new, other than I'm burned out at work. Shiftwork and looking at packets all day (along with customer firewall requests and the semi-management stuff I do) has taken its toll, so my resume is out there and I've gotten some interesting hits. Sadly, most of
it is contract work (which sucks) or requires a clearance (my clearance status is still in some black hole somewhere). Soooo...I'm applying within the company for other positions of interest. I'd like to stay in my field and have completed one assessment 'test'...it blew my mind, along with it being like 60 questions long, essay format. The things I do to get a freekin' job... :)

Anyways, I've a tidbit for you. If anyone has ever perused their web server logs and saw the below:

193.205.4.38 - - [19/Jan/2008:16:31:56 -0500] "HEAD / HTTP/1.0" 200 0
193.205.4.38 - - [19/Jan/2008:16:31:56 -0500] "HEAD / HTTP/1.0" 200 0 "-" "-"
193.205.4.38 - - [19/Jan/2008:16:31:56 -0500] "POST /_vti_bin/_vti_aut/author.dll HTTP/1.1" 500 544
193.205.4.38 - - [19/Jan/2008:16:31:56 -0500] "POST /_vti_bin/_vti_aut/author.dll HTTP/1.1" 500 544 "-" "core-project/1.0"

It looks harmless, eh? Seen this tons of times before? I know I have. Well, take a look at how my Snort setup detected it:

WEB-MISC cross site scripting attempt 1 1 2008-01-19 16:31:56 2008-01-19 16:31:56

Digging deeper:

[ GAAAHHH...the code renders like pure dung when I post! ]

Note that I've disabled the harmful HTML flags and Snort removed the garbage (noted as non-ASCII characters).

And, no, I don't allow any inputting of text on my site, and I also don't allow any scripts to be run. My site is a static site, so I'm safe enough, along with using modsecurity and Snort for blocking of HTTP traffic and detection of badness. I refuse to be a statistic, although my stubbornness limits dynamic content serving.

The script looks like it checked for a live webserver then began the attack, quick-fast. Most people will associate the Frontpage attack as an old attack. The payload of the Frontpage attacks show:

method=put+document%3a4%2e0%2e2%2e4715&service%5fname=&document=%5bdocument%5fname%3dindex.htm%3bmeta%5finfo%3d%5b%5d%5d&put%5foption=overwrite&comment=&keep%5fchecked%5fout=false

I will not pretend I know what all it does. It is attempting to inject data into my server, though. The red flag for me is the 'method=put+document'. Also, there were two of these, happening 24 hours apart (but only one cross-site scripting event). I'll not block the site, as I may actually learn something from recording its attacks (and I can't block the whole internet, either).

Another host to block

I've just blocked 202.75.33.249. I haven't been paying heed to my Dshield reports and when I compared two reports today, I saw the same IP generating many hits. I checked the firewall logs and processed how many alerts this IP has generated. I found that the attacks began Nov 18th and the total number of alerts are 863.

This IP was a prime candidate for blocking.

Why don't I use Snort-inline? Because I don't have that much control over the network that my host is on (its a colo box running on a virtual server). So, I have to do things manually...it's not a problem, as it keeps me on my toes.

EDIT - I actually blocked 3 other IPs also. What's funny is that I saw one that was trying to connect on port 3389 (MS Term Svcs)...to a Linux machine...

e-GeForce 7300 GT fan issues

The fan on this card, which I purchased last March, seized. It appears to be removable. Instead of returning it, I'm going to see about adding another fan (I just need to find one that will clamp on without issues).

I ordered another one eariler in the week and will use this one while I'm repairing the other's fan (in fact, I'll order an additional fan for when the new one's fan breaks).

Why am I putting up with replacing the fan and buying an additional fan for the new one? Because the card is AWESOME! The fan issue totally sucks and the card is still under warranty, but I can tell that these cards have bad fans and this is a design defect, I believe. If I can replace the fan with one that clamps on at the same clamp-on points, I'll be happy. If not, I'll return both before the warranties end and get the fanless versions.

Click here for some TigerDirect reviews of this card.

EDIT: WHOA... I just opened the box of my replacement 7300 and saw that they've changed the fan to something that is hopefully more robust. It is an open fan and is black plastic. EVGA must have had too many complaints and decided that a new fan was in order. I'll post pics later.

Modsecurity again

Reading through some of my unread modsecurity mailing list emails, I found this tidbit (pretty simple, actually):

egrep '^Message:' modsec_audit.log | sort | uniq -c | sort -rn

I edited it to read: egrep 'message:' audit_log | sort | uniq -c | sort -rn

I see the following after running those commands:

927 mod_security-message: Access denied with code 403. Pattern match "index.php" at REQUEST_URI [id "1005"][rev "2"] [msg "index.php usage, suspicious activity"] [severity "ALERT"]
728 mod_security-message: Access denied with code 403. Pattern match "cmd.txt" at REQUEST_URI [id "1005"][rev "2"] [msg "cmd.txt usage, suspicious activity"] [severity "ALERT"]
668 mod_security-message: Warning. Pattern match "/robots\\.txt" at THE_REQUEST [severity "EMERGENCY"]
377 mod_security-message: Warning. Pattern match "/*\\.shtml" at THE_REQUEST [severity "EMERGENCY"]
171 mod_security-message: Access denied with code 500. Pattern match "\\?\\?\\?\\?\\?\\?\\?\\?\\?\\?" at THE_REQUEST [severity "EMERGENCY"]
141 mod_security-message: Access denied with code 403. Pattern match "/xmlrpc.php" at REQUEST_URI [id "1003"][rev "2"] [msg "lupper-type attack attempt"] [severity "CRITICAL"]
127 mod_security-message: Warning. Pattern match "/\\?M=D" at THE_REQUEST [severity "EMERGENCY"]
127 mod_security-message: Access denied with code 403. Pattern match "index2.php" at REQUEST_URI [id "1005"][rev "2"] [msg "index2.php usage, suspicious activity"] [severity "ALERT"]
115 mod_security-message: Access denied with code 500. Pattern match "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data;)" at HEADER("Content-Type") [severity "EMERGENCY"]
82 mod_security-message: Access denied with code 403. Pattern match "adxmlrpc.php" at REQUEST_URI [id "1004"][rev "2"] [msg "lupper-type attack attempt"] [severity "CRITICAL"]
51 mod_security-message: Access denied with code 403. Pattern match "login.php" at REQUEST_URI [id "1005"][rev "2"] [msg "login.php usage, un-kosher activity"] [severity "ALERT"]
48 mod_security-message: Access denied with code 500. Pattern match "\\." at REQUEST_URI [severity "EMERGENCY"]
29 mod_security-message: Access denied with code 500. Pattern match "\\.\\." at THE_REQUEST [severity "EMERGENCY"]
12 mod_security-message: Access denied with code 500. Error normalising REQUEST_URI: Invalid character detected [0] [severity "EMERGENCY"]
8 mod_security-message: Access denied with code 403. Pattern match "index.php" at POST_PAYLOAD [id "1005"][rev "2"] [msg "index.php usage, suspicious activity"] [severity "ALERT"]
7 mod_security-message: Access denied with code 500. Pattern match "/calendar" at THE_REQUEST [severity "EMERGENCY"]
5 mod_security-message: Warning. Pattern match "/bash" at THE_REQUEST [severity "EMERGENCY"]
4 mod_security-message: Access denied with code 500. Pattern match "wget\\x20" at REQUEST_URI [severity "EMERGENCY"]
2 mod_security-message: Access denied with code 500. Pattern match "\\?&" at THE_REQUEST [severity "EMERGENCY"]
2 mod_security-message: Access denied with code 500. Pattern match "/root\\.exe" at THE_REQUEST [severity "EMERGENCY"]
1 mod_security-message: Access denied with code 403. Pattern match "/cmd.exe" at REQUEST_URI [id "1002"][rev "2"] [msg "codered/nimda attack attempt"] [severity "ALERT"]

The logs go back to May of 2007.

I did the same for my snort logs:

egrep 'Classification:' alert | sort | uniq -c | sort -rn

14441 [Classification: Misc activity] [Priority: 3]
1892 [Classification: Web Application Attack] [Priority: 1]
1857 [Classification: Attempted Information Leak] [Priority: 2]
1613 [Classification: Misc Attack] [Priority: 2]
1147 [Classification: access to a potentially vulnerable web application] [Priority: 2]
442 [Classification: Executable code was detected] [Priority: 1]
7 [Classification: Potentially Bad Traffic] [Priority: 2]
3 [Classification: Attempted User Privilege Gain] [Priority: 1]
3 [Classification: Attempted Denial of Service] [Priority: 2]
2 [Classification: Detection of a Network Scan] [Priority: 3]
1 [Classification: Attempted Administrator Privilege Gain] [Priority: 1]

This Snort log is 7.4M in size.

Pretty cool, eh? I thought it would be cool to share this!

WPA and Slackware (or in this case, Backtrack)

I've got Slackware (OK, actually Backtrack...the differences between the two are subtle but defined pretty well and is a discussion for another day) running wpa_supplicant. In the last week, I've seen several people complaining on the lack of documentation on how to get this running. Another issue that isn't well-documented is the fact that Slackware has no GUI that'll allow the user to switch wireless networks as quickly as possible. My only answer is to use Slackware's KDE-based wifi management tool.

I've used ndiswrapper with a closed-source card on a Toshiba Satellite 1805-S274, in this case.

Anyways, I'm going to attempt to describe how I use wpa-supplicant. My wifi setup uses a PCMCIA card (Linksys WPC54GS) in which I have to use win32 drivers (via ndiswrapper). I created a script in the root directory: wlan_script2.sh.

#!/usr/bin/bash

#Start of script

wpa_supplicant -ieth1 -c/etc/wpa_supplicant.conf -dP -Dndiswrapper -B

dhcpcd -d -t 10 eth1

#End of script

I've also added the following to the bottom of the /etc/wpa_supplicant.conf file:

network={
ssid="youarebeingwatched2"
proto=WPA
key_mgmt=WPA-PSK
psk="There are a lot of steps to this document and the process should be simplified!"
priority=99
}

I usually run the first script above, then the second. I'm then instantly connected without trouble:

bt ~ # ./wlan_script2.sh
Initializing interface 'eth1' conf '/etc/wpa_supplicant.conf' driver 'default' ctrl_interface 'N/A'
bridge 'N/A'
Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant.conf'
ctrl_interface='/var/run/wpa_supplicant'
ctrl_interface_group='wheel' (DEPRECATED)
eapol_version=1
ap_scan=1
fast_reauth=1
Priority group 99
id=0 ssid='youarebeingwatched2'
Initializing interface (2) 'eth1'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
EAPOL: External notification - portEnabled=0
EAPOL: External notification - portValid=0
SIOCGIWRANGE: WE(compiled)=21 WE(source)=18 enc_capa=0xf
capabilities: key_mgmt 0xf enc 0xf
WEXT: Operstate: linkmode=1, operstate=5
Own MAC address: 00:0f:66:4a:42:6a
wpa_driver_wext_set_wpa
wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0
wpa_driver_wext_set_countermeasures
wpa_driver_wext_set_drop_unencrypted
Setting scan request: 0 sec 100000 usec
Using existing control interface directory.
ctrl_interface_group=10 (from group name 'wheel')
Added interface eth1
Daemonize..
dhcpcd: MAC address = 00:0f:66:4a:42:6a
dhcpcd: your IP address = 10.150.1.109

Now, this is a cheap hack and this can be done using the existing Slackware scripts, most likely...it was quicker for me to script this on my own and get internet connectivity up and running quickly. Besides that, I'm OK using this hack. Usually I just turn on the laptop, plug in the wireless PCMCIA adapter (Linksys WPC54GS), run the scripts, and commence to browse!

Any of you got any wireless hacks?

A Good Read: Snort for Dummies

Don't laugh. I bought this book a long time ago so that I could understand some things about Snort that were described in other expensive books that I didn't understand. Somtimes, very basic explanations in a non-technical jargon is best and every little bit of understanding helps, right? Here's the link: Snort for Dummies

58 Cool Hacks...and more

Here are fifty-eight (58) cool hacks that are posted on the Linux Format Wiki. Some of these are actually cool and insightful. I plan on attemtping to regularly use a few of them. I'll let you know a bit later which ones they are and how well my implementation and usage goes.

Here is another good link. It describes in detail how to build your own distribution (build, not create, as you will build from a pre-existing Linux ISO file). If I'd enough time to do this, I would...maybe during my next holiday, I'll begin this, with the idea of making a seriously light yet secure distro.

This one is a good one, but I've only skimmed it so far. It is LinuxFormat's Slackware documentation. Since I know they are a bit biased in their views of Slackware (they seem to think that apt-get-like package management is a requirement and that the distribution is a bit 'behind the times'), I know I need to read this part of their wiki with some attention to detail.

Web server being scanned

Hrmm...I've found that my web server is being slowly scanned. This scan looks to be attempting to do a 'low and slow' scan, attempting to circumvent any monitoring thresholds. In fact, I noticed the scans a few days ago and just added the IP to my firewall block list.

Here's what I've seen so far:

DShield
myNetWatchman
Web Sniffer Proxy

Both of those links just show a few of my firewall entries. I give feeds of my logs to several organizations to assist in monitoring internet-wide attacks and trending.

My Snort logs show a different story (IDS logs always do, when comparing to firewall logs). What I'm seeing are SNMP-type scans, which are probably NMAP scans. What's weird is that the scans originate from IP 67.15.135.144:80. Visiting that page with http://web-sniffer.net, I see an unconfigured/new server account:

         class="welcomeText">Server Default page
class="descriptionText">
       If you see this page it means:

       1. hosting for this domain is not configured

       or

       2. there's no such domain registered in Plesk
     

The above is usually an indicator of badness...it appears that someone may have purposely stood up this account to use maliciously. All they need is a running web server, and the fact that I'm seeing what I am is an indication that the web server is up and running (I also got an HTTP status code of '200').

I'll keep monitoring this activity, although the activity is fully blocked (the whole network range is blocked).

Slack v12.0 on a old rackmount

My Dell Precision 220 that I had NetBSD installed on has a CPU fan that is dying (bearing failure which is pretty damn noisy). I've turned off the machine but needed a temporary replacement, so I took an old rackmount (no-name brand that was pretty much hand-built) and installed Slackware v12.0 on it. It was previously running Astaro Linux but I needed something that had a bunch of installed NICs. This machine has 4 NICs. I need three of them, one for the management interface and two for connections to an ethernet tap (I'm sniffing traffic before my firewall).

I'd thought this would be a huge exercise in hunting down how to bind the two interfaces that were plugged into the tap ports of the tap, but it was easier than in NetBSD.

After installing Slackware v12.0 and then Snort (2.6.1.5), I then used 'brctl' to establish an ethernet bridge across two different physical interfaces:

root@suna:~# brctl
Usage: brctl [commands]
commands:
addbr add bridge
delbr delete bridge
addif add interface to bridge
delif delete interface from bridge
setageing set ageing time
setbridgeprio set bridge priority
setfd set bridge forward delay
sethello set hello time
setmaxage set max message age
setpathcost set path cost
setportprio set port priority
show show a list of bridges
showmacs show a list of mac addrs
showstp show bridge stp info
stp {on|off} turn stp on/off
root@suna:~#
root@suna:~# brctl addbr br0
root@suna:~#
root@suna:~#
root@suna:~# ifconfig br0
br0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

root@suna:~# ifconfig eth2 up
root@suna:~# ifconfig eth3 up
root@suna:~# brctl addif br0 eth2
root@suna:~# brctl addif br0 eth3
root@suna:~# ifconfig br0 up
root@suna:~# tcpdump -ivv br0
tcpdump: SIOCGIFHWADDR: No such device
root@suna:~# tcpdump -vvi br0
tcpdump: WARNING: br0: no IPv4 address assigned
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
23:44:41.166720 IP (tos 0x0, ttl 54, id 47678, offset 0, flags [DF], proto: TCP (6), length: 129) 64.161.255.20.ircd > pool-71-178-10-160.washdc.fios.verizon.net.49197: P 692786612:692786689(77) ack 97899523 win 98
23:44:41.167554 IP (tos 0x0, ttl 63, id 17743, offset 0, flags [DF], proto: TCP (6), length: 52) pool-71-178-10-160.washdc.fios.verizon.net.49197 > 64.161.255.20.ircd: ., cksum 0x501f (correct), 1:1(0) ack 77 win 1002
23:44:41.175972 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 72) pool-71-178-10-160.washdc.fios.verizon.net.1024 > nsrest01.verizon.net.domain: [udp sum ok] 19732+ PTR? 20.255.161.64.in-addr.arpa. (44)
23:44:41.481742 IP (tos 0x0, ttl 249, id 47959, offset 0, flags [DF], proto: UDP (17), length: 123) nsrest01.verizon.net.domain > pool-71-178-10-160.washdc.fios.verizon.net.1024: 19732 NXDomain q: PTR? 20.255.161.64.in-addr.arpa. 0/1/0 ns: 255.161.64.in-addr.arpa. (95)

4 packets captured
4 packets received by filter
0 packets dropped by kernel
root@suna:~# ifconfig br0
br0 Link encap:Ethernet HWaddr 00:D0:B7:85:78:D6
inet6 addr: fe80::2d0:b7ff:fe85:78d6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1108 (1.0 KiB) TX bytes:468 (468.0 b)

After setting up the br0 interface, I could then use Snort to sniff the br0 device (and see the traffic of the interfaces bridged to br0):

root@suna:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.00d0b78578d6 no eth2
eth3
root@suna:~# ifconfig eth2
eth2 Link encap:Ethernet HWaddr 00:D0:B7:85:78:D6
inet6 addr: fe80::2d0:b7ff:fe85:78d6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:49363 errors:0 dropped:0 overruns:0 frame:0
TX packets:41805 errors:0 dropped:0 overruns:0 carrier:10
collisions:1202 txqueuelen:1000
RX bytes:41520086 (39.5 MiB) TX bytes:5730882 (5.4 MiB)
Interrupt:5

root@suna:~# ifconfig eth3
eth3 Link encap:Ethernet HWaddr 00:D0:B7:85:8A:B4
inet6 addr: fe80::2d0:b7ff:fe85:8ab4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:41860 errors:0 dropped:0 overruns:0 frame:0
TX packets:49312 errors:0 dropped:0 overruns:0 carrier:940
collisions:959 txqueuelen:1000
RX bytes:5771456 (5.5 MiB) TX bytes:41483624 (39.5 MiB)
Interrupt:10

root@suna:~# ethtool eth2
Settings for eth2:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Half
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes

root@suna:~# ethtool eth3
Settings for eth3:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Half
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Current message level: 0x000020c1 (8385)
Link detected: yes
root@suna:~#

At this point, it can get snort to run, but it dies not long after starting the process. I can also use tcpdump to sniff traffic from the br0 device. I'm seeing normal traffic. There's nothing in the logs to indicate any problems. I'm also able to telnet to port 3306 (Snort is reporting events/alerts to a database). I've also tested my snort.conf and it appears sane (no reported errors) and will connect to the MySQL database without errors.

Hrmmm...looks like it will be a busy weekend...

Edit - 11/10/2007:

I had to revert to Snort v2.4.4 for now, as v2.6.1.5 was causing serious memory issues. Using the -M switch, Snort wasn't telling me why it was dying. 'dmesg' or cat'ing the /var/log/messages file wasn't showing why it was dying either. The only hint was me watching the process via 'top'. Within 5 min, the process would hog all 512MB of physical RAM and commence to using all virtual RAM (1GB). The process would die less than an hour after start. I began trimming the snort.conf file to lessen memory usage, but began to tire of doing this. I decided to fall back a version until I could figure out why v2.6 wasn't working.

Updated Modsecurity rules by converting Snort rules

Using the tool shown here, I was able to convert the latest snort rules into Modsecurity rules!

Previous to this, I'd created my own (crude) rules that blocked most of the traffic I had concerns about, but I wanted something more. I converted the latest Snort rules to Modsecurity rules, ending up with 852 new Modsecurity rules (12 of which I created).

This is already paying off. I'm seeing a good bit of rejected or warning-type (but passing) traffic. Also, the web rejections are actually triggering Snort alerts (attack responses), which is great, as it gives me more data to investigate when perusing my Snort logs.

I also had issues with maybe 7 of the converted rules. I've yet to look at why they wouldn't work without Apache erroring out, but I've disabled them. I'll take a look at them sometime soon.

`

Snort/BASE and Analytics

This post is not related to Slackware, but will cover a method of utilizing BASE to conduct analysis. I'm including screenshots of my BASE setup when conducting analysis to describe how I utilize BASE and correlate logged activity. The below is NOT the only methods of conducting analytics with BASE. This method works for me and offers me quick results. In fact, if you've other methods, please post or e-mail me so that I can know different ways of using this SEM.

If you're not familiar with BASE, please visit the project's site. BASE is a browser-based console that presents intrusion detection logs in various readable formats.

Here is a screenshot of the root page:



Within the upper left-hand corner (within the blue field), there are what I call "canned queries", that will allow you to see certain subsets of data. The ones that I focus on the most are

- Today's alerts
- Last 24 Hours alerts
- Last 72 Hours alerts
- Most recent 15 Alerts
- Most recent 15 Unique Alerts
- Most frequent 5 Unique Alerts

Out of those, I focus on "Last 72 Hours alerts" most frequently.

Let us delve into the last 72 hours' events. Note in the image that I've circled this link. Please either follow along if you've BASE installed, or follow this diatribe and its image links. Either click the circled link or open it in a new tab or browser. I tend to open BASE links in a new browser instance, as it gives me a separate area to dig into a new investigation. This way, if I've several concerns, I've a browser window for each.

After clicking the 72-hour link, you should see something similar to below:



I've split the browser window into two pages, since the alerts scroll down the page. For this exercise, we're going to focus on the second image, specifically the "WEB-PHP remote include path" events (toward the bottom). I chose these events because I wanted a good example of how to correlate events per IP. Click on this link (circled in RED) or open the link in a new browser/tab. You may see something similar to the following browser window:



In this example, 37 alerts are showing, with various source IPs (or what I call SIPs) and, in this case, one destination IP (what I call a DIP). Note that there could be more than one DIP, such as when you've two web servers or two IPs that are sharing a NIC. In the above browser window, I've a few IPs apparently attacking my web server. How do I make it so I see one line per SIP yet get enough situational awareness that I have an idea of which SIP generated what number of alerts on a DIP? The "Unique IP Links" in the upper right corner (circled in RED). Click on that link and you should see something similar to the following:



What's changed? The traffic is now matched based on unique traffic. Let's focus on "90-179-94.adsl.cust.tie.cl/200.90.179.94". This IP shows as a source and destination IP. Why? Because the IDS sensor logged both the web server's sending and receiving traffic (bi-directional). Note that this only happens when a response signature triggers (we'll see this in the next screenshot). If the web server response does not trigger a signature, the IDS won't log an alert. This is where signature tuning comes in handy...you really don't want to see legitimate HTTP 202 (OK) traffic being logged unless absolutely necessary. You only want concerning traffic to be logged. Now, note the brackets (sloppy) in RED in the above right screenshot. I'm going to click the 200.90.179.94 IP because I want to know what's going on there. I also observed this IP in the lower half of the screen (not screenshotted for brevity) alerting on my other IP (the NIC is dual-homed). Click on the IP and you'll see something similar:



You can study this page for a moment, but its just a page to gain a further understanding of who owns the IP. The real resources on this page are circled in RED. We'll click on both, starting with "Source/Destination", then "Unique Alerts". Open them in separate windows so you can compare. While both may show similar alerts, each is valuable:



The view on the left shows every unique attack and attack response regarding the attacking IP. The view on the right shows a summary of the attacks, with a description of "4 unique alerts detected among 16 alerts on 200.90.179.94/32". The right view also shows that you can dig down into each category of alert, if you chose.

Which view do I rely on? For a quick view, I usually use the right screenshot, but I also use the left screenshot method for when I want to see everything the attacking IP did (and how my server responded). Note that I didn't obfuscate the whole of my server's IP. I wanted to show an example of this method of analysis showing EVERYTHING the attacker did, including reaching out to both of my IPs.

I'm not going to go further. I just wanted to highlight how BASE can be used efficiently. Anything further would get into payload analysis, which is beyond the scope of today's post.

Stay tuned for a possible swf2vnc movie capture of using BASE. This will happen as soon as I can figure out how to mask my public IPs. This task may get me to delve into using my Macs to edit the SWF movies (we'll see if that is possible, with free- or shareware).

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.

`