Asus ships software cracker on recovery DVD:
Asus is accidentally shipping software crackers and confidential documents on the recovery DVDs that come with its laptops.
The startling discovery was made by a PC Pro reader whose antivirus software was triggered by a key cracker for the WinRAR compression software, which was located on the recovery DVD for his Asus laptop.
Tuesday, September 23, 2008
Tuesday, July 08, 2008
Script that parses FW logs?
What I'm trying to do now is create a script that will parse FW logs daily and break down how many entries each IP generated.
I want to do this first as a quick command, then leverage BASH scripting to automate this.
What I used in http://slackfiles.blogspot.com/2007/12/modsecurity-again.html apparently isn't working when trying to parse the firewall logs. I don't get it, but then again, I'm tired. I'll try again tomorrow.
The new logs look like the below (showing in /var/log/syslog instead of /var/log/messages of my old setup):
I may need to leverage Awk (I was close to doing this before I upgraded the server from v9.0 to v12.0).
Stay tuned!
I want to do this first as a quick command, then leverage BASH scripting to automate this.
What I used in http://slackfiles.blogspot.com/2007/12/modsecurity-again.html apparently isn't working when trying to parse the firewall logs. I don't get it, but then again, I'm tired. I'll try again tomorrow.
The new logs look like the below (showing in /var/log/syslog instead of /var/log/messages of my old setup):
Jul 8 22:55:19 starchild kernel: BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:fc:8b:59:08:00 SRC=64.47.32.59 DST=64.62.231.220 LEN=48 TOS=0x00 PREC=0x00 TTL=249 ID=39747 DF PROTO=TCP SPT=3405 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
I may need to leverage Awk (I was close to doing this before I upgraded the server from v9.0 to v12.0).
Stay tuned!
Sunday, June 22, 2008
Linode has been upgraded to Slackware v12.0
I decided to take the plunge and upgrade my Linode server from v9.0 to v12.0.
Things are semi-normal, yet I still have some things to do, such as reinstall denyhosts, a new iptables script, mnwclient, and dshieldclient.
So far, I've reinstalled the eggdrop bot (slackboy), using the latest version of the software. I've also reinstalled Apache, using v2.0.63. Snort is running on the system (installed using my v12.0 slackpack), and also Webmin (which eases my pain somewhat, especially when administrating from work...they frown upon using SSH outbound).
This verion of Slackware is barebones and I've had to manually install the following packages so far:
-rw-r--r-- 1 root root 122953 2006-11-01 02:50 checkinstall-1.6.1-i386-1.tgz
-rw-r--r-- 1 root root 551952 2006-05-27 16:24 cyrus-sasl-2.1.22-i486-1.tgz
-rw-r--r-- 1 root root 744871 2007-05-09 14:46 fetchmail-6.3.8-i486-2.tgz
-rw-r--r-- 1 root root 2268306 2006-03-26 19:04 groff-1.19.2-i486-1.tgz
-rw-r--r-- 1 root root 2088735 2007-07-01 19:12 httpd-2.2.4-i486-6.tgz
-rw-r--r-- 1 root root 1898552 2008-02-14 17:37 httpd-2.2.8-i486-1_slack12.0.tgz
-rw-r--r-- 1 root root 313616 2007-06-02 18:52 lsof-4.78-i486-1.tgz
-rw-r--r-- 1 root root 222760 2006-02-10 20:03 man-1.6c-i486-2.tgz
-rw-r--r-- 1 root root 1949092 2007-06-13 13:35 man-pages-2.55-noarch-1.tgz
-rw-r--r-- 1 root root 135893 2004-02-18 05:59 metamail-2.7-i486-2.tgz
-rw-r--r-- 1 root root 16756453 2007-03-24 00:52 mysql-5.0.37-i486-1.tgz
-rw-r--r-- 1 root root 16942549 2007-12-14 17:01 mysql-5.0.51-i486-1_slack12.0.tgz
-rw-r--r-- 1 root root 1483847 2007-05-07 01:15 ntp-4.2.4p0-i486-1.tgz
-rw-r--r-- 1 root root 3440059 2007-06-13 13:40 openssl-0.9.8e-i486-3.tgz
-rw-r--r-- 1 root root 836941 2007-06-13 13:40 openssl-solibs-0.9.8e-i486-3.tgz
-rw-r--r-- 1 root root 143713 2006-09-19 00:11 procmail-3.22-i486-2.tgz
-rw-r--r-- 1 root root 2450931 2003-10-29 01:08 rpm-4.2.1-i486-3.tgz
-rw-r--r-- 1 root root 4603 2007-01-04 22:28 rpm2tgz-1.0-i486-1.tgz
-rw-r--r-- 1 root root 212764 2007-02-10 14:52 rsync-2.6.9-i486-1.tgz
-rw-r--r-- 1 root root 1391679 2007-06-10 01:16 sendmail-8.14.1-i486-1.tgz
-rw-r--r-- 1 root root 276485 2007-06-10 01:16 sendmail-cf-8.14.1-noarch-1.tgz
-rw-r--r-- 1 root root 30270 2006-04-19 00:56 slocate-3.1-i486-1.tgz
-rw-r--r-- 1 root root 763394 2008-06-15 15:30 snort-2.6.1.5-i386-1.tgz
-rw-r--r-- 1 root root 137062 2006-02-06 14:00 sudo-1.6.8p12-i486-1.tgz
-rw-r--r-- 1 root root 1793130 2007-06-02 19:32 tcl-8.4.15-i486-1.tgz
-rw-r--r-- 1 root root 66773 2007-04-30 00:35 telnet-0.17-i486-1.tgz
-rw-r--r-- 1 root root 8614263 2007-06-20 16:34 vim-7.1.012-i486-1.tgz
-rw-r--r-- 1 root root 1882278 2007-06-20 16:50 vim-gvim-7.1.012-i486-1.tgz
-rw-r--r-- 1 root root 13573880 2008-05-26 00:19 webmin-1.420.tar.gz
Stability-wise, the server appears to be running somewhat more efficiently than before (for instance, the CPU and memory utilizations, along with IO, appear to be less 'spiky' when looking at chart readouts. When I shut down the server to upgrade (which is the way its done with Linode.com), I'd had 440+ days of uptime, so I can't argue about stability...it doesn't get much better than that!
Sooner or later, I'm going to try backing up my latest install, then trying to upgrade to v12.1 (just because I can).
Things are semi-normal, yet I still have some things to do, such as reinstall denyhosts, a new iptables script, mnwclient, and dshieldclient.
So far, I've reinstalled the eggdrop bot (slackboy), using the latest version of the software. I've also reinstalled Apache, using v2.0.63. Snort is running on the system (installed using my v12.0 slackpack), and also Webmin (which eases my pain somewhat, especially when administrating from work...they frown upon using SSH outbound).
This verion of Slackware is barebones and I've had to manually install the following packages so far:
-rw-r--r-- 1 root root 122953 2006-11-01 02:50 checkinstall-1.6.1-i386-1.tgz
-rw-r--r-- 1 root root 551952 2006-05-27 16:24 cyrus-sasl-2.1.22-i486-1.tgz
-rw-r--r-- 1 root root 744871 2007-05-09 14:46 fetchmail-6.3.8-i486-2.tgz
-rw-r--r-- 1 root root 2268306 2006-03-26 19:04 groff-1.19.2-i486-1.tgz
-rw-r--r-- 1 root root 2088735 2007-07-01 19:12 httpd-2.2.4-i486-6.tgz
-rw-r--r-- 1 root root 1898552 2008-02-14 17:37 httpd-2.2.8-i486-1_slack12.0.tgz
-rw-r--r-- 1 root root 313616 2007-06-02 18:52 lsof-4.78-i486-1.tgz
-rw-r--r-- 1 root root 222760 2006-02-10 20:03 man-1.6c-i486-2.tgz
-rw-r--r-- 1 root root 1949092 2007-06-13 13:35 man-pages-2.55-noarch-1.tgz
-rw-r--r-- 1 root root 135893 2004-02-18 05:59 metamail-2.7-i486-2.tgz
-rw-r--r-- 1 root root 16756453 2007-03-24 00:52 mysql-5.0.37-i486-1.tgz
-rw-r--r-- 1 root root 16942549 2007-12-14 17:01 mysql-5.0.51-i486-1_slack12.0.tgz
-rw-r--r-- 1 root root 1483847 2007-05-07 01:15 ntp-4.2.4p0-i486-1.tgz
-rw-r--r-- 1 root root 3440059 2007-06-13 13:40 openssl-0.9.8e-i486-3.tgz
-rw-r--r-- 1 root root 836941 2007-06-13 13:40 openssl-solibs-0.9.8e-i486-3.tgz
-rw-r--r-- 1 root root 143713 2006-09-19 00:11 procmail-3.22-i486-2.tgz
-rw-r--r-- 1 root root 2450931 2003-10-29 01:08 rpm-4.2.1-i486-3.tgz
-rw-r--r-- 1 root root 4603 2007-01-04 22:28 rpm2tgz-1.0-i486-1.tgz
-rw-r--r-- 1 root root 212764 2007-02-10 14:52 rsync-2.6.9-i486-1.tgz
-rw-r--r-- 1 root root 1391679 2007-06-10 01:16 sendmail-8.14.1-i486-1.tgz
-rw-r--r-- 1 root root 276485 2007-06-10 01:16 sendmail-cf-8.14.1-noarch-1.tgz
-rw-r--r-- 1 root root 30270 2006-04-19 00:56 slocate-3.1-i486-1.tgz
-rw-r--r-- 1 root root 763394 2008-06-15 15:30 snort-2.6.1.5-i386-1.tgz
-rw-r--r-- 1 root root 137062 2006-02-06 14:00 sudo-1.6.8p12-i486-1.tgz
-rw-r--r-- 1 root root 1793130 2007-06-02 19:32 tcl-8.4.15-i486-1.tgz
-rw-r--r-- 1 root root 66773 2007-04-30 00:35 telnet-0.17-i486-1.tgz
-rw-r--r-- 1 root root 8614263 2007-06-20 16:34 vim-7.1.012-i486-1.tgz
-rw-r--r-- 1 root root 1882278 2007-06-20 16:50 vim-gvim-7.1.012-i486-1.tgz
-rw-r--r-- 1 root root 13573880 2008-05-26 00:19 webmin-1.420.tar.gz
Stability-wise, the server appears to be running somewhat more efficiently than before (for instance, the CPU and memory utilizations, along with IO, appear to be less 'spiky' when looking at chart readouts. When I shut down the server to upgrade (which is the way its done with Linode.com), I'd had 440+ days of uptime, so I can't argue about stability...it doesn't get much better than that!
Sooner or later, I'm going to try backing up my latest install, then trying to upgrade to v12.1 (just because I can).
Wednesday, June 11, 2008
wigglit.ath.cx being bombarded with scans of port 1028/UDP
The culprit?
24.64.0.0/13, or 24.64.0.0 - 24.71.255.255, which resolves to SHAWCABLE.NET
There are at least 311 hosts within that range that have tried to connect to UDP port 1028 in the last few days. This isn't really a broad scan but the pepperings of hosts every day for the last few days, each one being unique hosts that have never been logged makes it hard to establish a pattern so that I can block remote hosts that continue to scan for this port, so I've opted to initiate a broad block and keep the block in place for maybe 30 days.
I'll monitor this activity and maybe alert the ISC diary if the scans continue.
If you're caught up in this ban, let me know and I'll see about allowing traffic to specific hosts.
24.64.0.0/13, or 24.64.0.0 - 24.71.255.255, which resolves to SHAWCABLE.NET
There are at least 311 hosts within that range that have tried to connect to UDP port 1028 in the last few days. This isn't really a broad scan but the pepperings of hosts every day for the last few days, each one being unique hosts that have never been logged makes it hard to establish a pattern so that I can block remote hosts that continue to scan for this port, so I've opted to initiate a broad block and keep the block in place for maybe 30 days.
I'll monitor this activity and maybe alert the ISC diary if the scans continue.
If you're caught up in this ban, let me know and I'll see about allowing traffic to specific hosts.
Monday, June 09, 2008
Metaspolit hijacked?
Monday morning, Metasploit.com was temporarily hijacked using an attack on the local area network of Metasploit's hosting provider.
More info here
More info here
Monday, May 05, 2008
Slamd64
I've installed Slamd64 on my new AMD system. Initially, I had SATA issues that have mysteriously disappeared (no idea why, other than maybe swapping out that SATA cables helped). I installed using Disk 1 only (I didn't download anything else), which has the core system components. I then wanted to boot X, which required me downloading the X and KDE software. In fact, I went ahead and copied a whole mirror site and will continue to rsync the site against my local copy, using the updated local mirror as a upgrade repository.
I had issues getting my mouse recognized. I've a Logitech MX1000 wireless mouse, which is connected to a KVM. Slamd64 detects it as a PS/2 mouse. Slamd64 has PS/2 mice blacklisted, so I had to unblock the psmouse module from /etc/modules.d/blacklist (by uncommenting the module entry). Then I loaded the module and rebooted. The reboot detected the mouse. It took me a while to find this tidbit of info (although, it was recorded on the Slamd64 forums). I'll be adding this to my local knowledgbase (in fact, I need to add a whole Slamd64 category first).
I've also installed phpsysinfo on this machine, so I can see the hardware and how it is detected by this tool. From what I've seen so far, the second CPU core takes the brunt of the load, with the first CPU core assisting when the second is maxed out...I don't know if this is normal or a software issue (maybe phpsysinfo needs to be optimized for dual core usage?), but I only tested this by refreshing the phpsysinfo browser session (it appears to put a quick load on the system...dunno if that's normal or not).
Anyways, if things go well with this distro, I'll be using this machine as my main Linux machine, eventually.
I had issues getting my mouse recognized. I've a Logitech MX1000 wireless mouse, which is connected to a KVM. Slamd64 detects it as a PS/2 mouse. Slamd64 has PS/2 mice blacklisted, so I had to unblock the psmouse module from /etc/modules.d/blacklist (by uncommenting the module entry). Then I loaded the module and rebooted. The reboot detected the mouse. It took me a while to find this tidbit of info (although, it was recorded on the Slamd64 forums). I'll be adding this to my local knowledgbase (in fact, I need to add a whole Slamd64 category first).
I've also installed phpsysinfo on this machine, so I can see the hardware and how it is detected by this tool. From what I've seen so far, the second CPU core takes the brunt of the load, with the first CPU core assisting when the second is maxed out...I don't know if this is normal or a software issue (maybe phpsysinfo needs to be optimized for dual core usage?), but I only tested this by refreshing the phpsysinfo browser session (it appears to put a quick load on the system...dunno if that's normal or not).
Anyways, if things go well with this distro, I'll be using this machine as my main Linux machine, eventually.
Saturday, May 03, 2008
AMD vs. Intel Comparison
About the new AMD system I recently bought...
The AMD Athlon 64 X2 4400+ rocks when compared to my Intel system, which uses a Pentium D830. The AMD CPU is running on an Abit NF-M2SV board with 1GB of RAM. The Intel system is running on an ECS nForce 570 SLIT-A v5.1 mainboard and 2GB of RAM. While the Intel system outguns the AMD system, spec-wise, the AMD system is quite a bit more responsive...the whole system seems and responds like it is extremely lightweight. Both are running XP Pro. The AMD CPU runs 104F temps on the average, while the Intel CPU is in the 120F range...and this system has the beefier CPU fan/heatsink too! The AMD CPU cooler is here. It is an Arctic Cooling Freezer 64 LP. The Intel CPU cooler is here and is apparently a standard issue HSF (Intel Socket 775 Cooling Fan, although it is badged as an Ultra unit).
I'm very impressed!
No, I don't have any benchmark specs (you can probably find these online via Google), but this is really a seat-of-the-pants comparison. That I noticed such a difference in this manner should speak for itself.
Now, I've split the 250GB drive on the AMD system in half, to test Slamd64, an unofficial 64-bit port of Slackware (which is a 32-bit OS). I've run into issues booting up Slamd64, though...I've been getting SATA-specific errors that hint that the hard drive is going bad (which I seriously doubt). I think I've seen these errors before when I last installed Slackware on a SATA drive...I think I selected the wrong kernel. I need to select a kernel specific to SATA support. I'll work on this during the next 7 days and report my findings here.
I'm seriously thinking on swapping the Intel machine for the AMD one, since the AMD machine appears more robust.
The AMD Athlon 64 X2 4400+ rocks when compared to my Intel system, which uses a Pentium D830. The AMD CPU is running on an Abit NF-M2SV board with 1GB of RAM. The Intel system is running on an ECS nForce 570 SLIT-A v5.1 mainboard and 2GB of RAM. While the Intel system outguns the AMD system, spec-wise, the AMD system is quite a bit more responsive...the whole system seems and responds like it is extremely lightweight. Both are running XP Pro. The AMD CPU runs 104F temps on the average, while the Intel CPU is in the 120F range...and this system has the beefier CPU fan/heatsink too! The AMD CPU cooler is here. It is an Arctic Cooling Freezer 64 LP. The Intel CPU cooler is here and is apparently a standard issue HSF (Intel Socket 775 Cooling Fan, although it is badged as an Ultra unit).
I'm very impressed!
No, I don't have any benchmark specs (you can probably find these online via Google), but this is really a seat-of-the-pants comparison. That I noticed such a difference in this manner should speak for itself.
Now, I've split the 250GB drive on the AMD system in half, to test Slamd64, an unofficial 64-bit port of Slackware (which is a 32-bit OS). I've run into issues booting up Slamd64, though...I've been getting SATA-specific errors that hint that the hard drive is going bad (which I seriously doubt). I think I've seen these errors before when I last installed Slackware on a SATA drive...I think I selected the wrong kernel. I need to select a kernel specific to SATA support. I'll work on this during the next 7 days and report my findings here.
I'm seriously thinking on swapping the Intel machine for the AMD one, since the AMD machine appears more robust.
Monday, April 28, 2008
Bake-off: NoScript and Firekeeper
I decided to mention Firekeeper on the security forums at LQ.org. One of the moderators there mentioned that NoScript was better at blocking malcode than Firekeeper. In order to understand what he was talking about (I'm confused about that comment), I decided to install both to see if one can layer and leverage both of these tools. I also wanted to see which was better at blocking and alerting on malcode in general.
It appears that NoScript is specific to javascript, although it looks to detect cross-site scripting, flash, and MS' version of Flash. It also works via whitelists and blacklists and not pattern matching (other than focusing on the word "script" and occasionally focusing on "ath.cx" (I haven't determined why it does this yet).
Both tools work in conjunction with another fine, though (so far).
I'm partial to Snort because an efficient and focused rule will always beat someone adding a site to a whitelist. I've seen trusted sites be hacked before, so if a trusted site is violated and begins serving malware, you're going to be visiting that site and that site will be in your white list...with Firekeeper, it will alert and block any malicious traffic.
The bad thing about Firekeeper is that someone always has to maintain the ruleset (be it the user or the developer or a combination of both).
I'll continue to comment as I learn both tools.
It appears that NoScript is specific to javascript, although it looks to detect cross-site scripting, flash, and MS' version of Flash. It also works via whitelists and blacklists and not pattern matching (other than focusing on the word "script" and occasionally focusing on "ath.cx" (I haven't determined why it does this yet).
Both tools work in conjunction with another fine, though (so far).
I'm partial to Snort because an efficient and focused rule will always beat someone adding a site to a whitelist. I've seen trusted sites be hacked before, so if a trusted site is violated and begins serving malware, you're going to be visiting that site and that site will be in your white list...with Firekeeper, it will alert and block any malicious traffic.
The bad thing about Firekeeper is that someone always has to maintain the ruleset (be it the user or the developer or a combination of both).
I'll continue to comment as I learn both tools.
Thursday, April 24, 2008
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.
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.
Anyways, this is a good read.
Monday, April 14, 2008
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:
I've not yet taken the time to delve into the capture (will have some time when I get home today).
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).
Wednesday, April 09, 2008
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:
The results look like:
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):
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!
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!
Sunday, March 30, 2008
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.
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.
Thursday, February 21, 2008
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...
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...
Sunday, February 17, 2008
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:
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/
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/
Friday, January 25, 2008
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."
Monday, January 21, 2008
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:
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).
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).
Saturday, January 12, 2008
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...
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...
Friday, December 21, 2007
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.
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.
Wednesday, December 19, 2007
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:
The logs go back to May of 2007.
I did the same for my snort logs:
This Snort log is 7.4M in size.
Pretty cool, eh? I thought it would be cool to share this!
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!
Subscribe to:
Posts (Atom)