Saturday, November 10, 2007

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).

Sunday, November 04, 2007

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


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.