SAGAN: An open-source event correlation system - Part 1: Installation
SAGAN can be found here.
This is an online log of my Slackware experiences. Be aware that I'm also using this blog to cover basic and intermediate security issues that may not pertain to Slackware. This is my way of consolidating blogs (I've several of them).
Monday, July 19, 2010
Friday, June 18, 2010
Distributed SSH Brute Force Attempts on the rise again -- SANS ISC
Reported by SANS ISC:
Distributed SSH Brute Force Attempts on the rise again
SSH brute force attempts seem to be on the rise again, at the SANS Internet Storm Center we have received a number of reports that a number of networks are seeing them. The source IP addresses vary with each new attempted username in the wordlist, which would indicate that the attempts are distributed through botnet(s). It only takes a single user with a weak password for a breach to occur, then with that foothold escalation and further attacks are likely next. This is certainly not a new phenomenon, however I think it is a good time to raise awareness about it once again.
Distributed SSH Brute Force Attempts on the rise again
SSH brute force attempts seem to be on the rise again, at the SANS Internet Storm Center we have received a number of reports that a number of networks are seeing them. The source IP addresses vary with each new attempted username in the wordlist, which would indicate that the attempts are distributed through botnet(s). It only takes a single user with a weak password for a breach to occur, then with that foothold escalation and further attacks are likely next. This is certainly not a new phenomenon, however I think it is a good time to raise awareness about it once again.
Wednesday, May 05, 2010
Twitter Spam
I looked in my e-mail going back a few days and saw the above e-mail. It looks legit, right? It appears to be coming from a twitter engineer, but look at my mouseover...there's a different URL behind the one showing and it looks to be suspicious.
I've gotten six of these since April 21st and I know that they're phishing-related. Most people don't know this, though. While some people suspect this type of e-mail is suspect, others are asking, "WTF is this?"
Tips:
1. Turn off HTML rendering in your e-mail client, as this prevents accidental clicking of malware/spyware/phishware links.
2. If you prefer HTML rendering to be on, if your OS or e-mail client supports link mouseover, you should be able to see what site you'd be directed to if you clicked the link. If the link isn't related to Twitter, then you know that something isn't right about that e-mail.
These phishers are beginning to get crafty, and in a subtle manner. It's sad that we have to suspect any official e-mails as bad as a first step.
Bottom Line: Don't click on those links if you're getting these types of e-mails.
Sunday, April 11, 2010
Got Prey?

I've installed Prey onto my Dell Mini 9. I'm considering also installing it onto my wife's Dell Mini 10 and both of our Macbooks.
Prey is a small and free application that will help you track down your machine if it is stolen. They've agents for Windows, Mac OS X, and Linux. It can be run on a desktop or laptop.
What you do is register with the website, install the application onto the machines you want to monitor (up to three per account). You then sync keys between the application and server software. You can monitor many things on the remote machine from the Prey website and can determine the general location of your equipment. You can even send messages to the thief!
This software gives you the chance to recover your equipment by enabling manipulation of the system. It can alert the 'new owner', it can be tracked via traceroute or GPS, the logs and processes can be monitored, and the webcam can be enabled.
Tuesday, March 30, 2010
Web Server Got Scanned

So, I got alerted last night that source IP 74.53.76.11 was hitting my web server. It was scanned....heavily.
The FW blocked it...it all hit the clean-up rule, which is a bit weird. Usually, IPs that scan will hit open ports also (I've a few open). This one was one of those with a source port of 80 that isc.sans.org was reporting about a few weeks ago. The IP belongs to ThePlanet. TrustedSource shows some squirrely activity but nothing definitive. My IDS didn't pick up anything either. I also searched MyNetWatchman but the server is busted and craps out when I try to conduct searches. The scan started at 14:38 and ended at 17:45 EST.
I'll keep a watch out for further activity.
References:
http://www.trustedsource.org/query/74.53.76.11
http://www.dshield.org/ipinfo.html?ip=74.53.76.11
EDIT (4/1/2010):
74.53.76.11 scanned the server today, generating 2144 FW log entries that were blocks triggered by the clean-up rule.
EDIT (4/2/2010):
124.217.254.63 also scanned the server today, generating 487 FW log entries that were blocks triggered by the clean-up rule.
http://www.trustedsource.org/query/124.217.254.63
Monday, March 29, 2010
Kismet for Macs - WEP/WPA/WPA2
Added KisMac to my Macbook.
This software is NICE!! I've used Kismet before (on a Sharp Zaurus SL5500), but the Mac version is VERY nice!
One disturbing thing (that I should put on my security blog) is that I saw a lot of WAPs in my neighborhood still using WEP. Three of them were Actiontec routers, which show the new rollout of FIOS from Verizon. Mine also shows up, but mine is set to use WPA2. There were maybe 5-6 WAPs using WPA (of maybe 10-12), but I was the ONLY one that I detected that was using WPA2. That's not good, IMO.
I may take a drive around tomorrow to sample the neighborhood. I'll parse that data and post it on my security blog.
Thursday, March 25, 2010
Feds weigh expansion of Internet monitoring
Feds weigh expansion of Internet monitoring
http://tinyurl.com/ybd23bz (credit: cnet.com)
SAN FRANCISCO--
"Homeland Security and the National Security Agency may be taking a closer look at Internet communications in the future.
The Department of Homeland Security's top cybersecurity official told CNET on Wednesday that the department may eventually extend its Einstein technology, which is designed to detect and prevent electronic attacks, to networks operated by the private sector. The technology was created for federal networks.
Not much is known about how Einstein works, and the House Intelligence Committee once charged that descriptions were overly "vague" because of "excessive classification." The White House did confirm this week that the latest version, called Einstein 3, involves attempting to thwart in-progress cyberattacks by sharing information with the National Security Agency.
Greater federal involvement in privately operated networks may spark privacy or surveillance concerns, not least because of the NSA's central involvement in the Bush administration's warrantless wiretapping scandal. Earlier reports have said that Einstein 3 has the ability to read the content of emails and other messages, and that AT&T has been asked to test the system. (The Obama administration says the "contents" of communications are not shared with the NSA.)"
Read more by clicking the link at the top of this section
http://tinyurl.com/ybd23bz (credit: cnet.com)
SAN FRANCISCO--
"Homeland Security and the National Security Agency may be taking a closer look at Internet communications in the future.
The Department of Homeland Security's top cybersecurity official told CNET on Wednesday that the department may eventually extend its Einstein technology, which is designed to detect and prevent electronic attacks, to networks operated by the private sector. The technology was created for federal networks.
Not much is known about how Einstein works, and the House Intelligence Committee once charged that descriptions were overly "vague" because of "excessive classification." The White House did confirm this week that the latest version, called Einstein 3, involves attempting to thwart in-progress cyberattacks by sharing information with the National Security Agency.
Greater federal involvement in privately operated networks may spark privacy or surveillance concerns, not least because of the NSA's central involvement in the Bush administration's warrantless wiretapping scandal. Earlier reports have said that Einstein 3 has the ability to read the content of emails and other messages, and that AT&T has been asked to test the system. (The Obama administration says the "contents" of communications are not shared with the NSA.)"
Read more by clicking the link at the top of this section
Wednesday, March 03, 2010
I passed my Security+ certification Exam!

I passed my Security+ exam! This certification is needed for a work client (a requirement to access their systems). This is a big deal to me, as I'd been studying awhile for it and the deadline for completion was next week.
I don't believe in certifications (I feel strongly that they aren't needed), but this is a first for me.
I'm so glad it is over! Now its reimbursement time! :)
Thursday, February 25, 2010
Aggressive Scanner hitting wigglit.ath.cx

A picture is worth a thousand words:
I blocked him/her last night. He/she hit again early this morning, but got rejected (not blocked). My sensor will log even if the attacks don't pass (picture it as an external IDS, although it really isn't). I sooo wish I messed with tarpits. I could rate-limit, though. I'll think about that.
UPDATE:
myNetWatchman
Sunday, February 14, 2010
Playing with the logs again
So, I've some logging going on. I typically look at my auth logs and my FW logs that reside within /var/log. I also archive my bruteforce blocking FW table (PF), as the table dumps when I reboot or when the system loses power.
I consolidated these logs into one massive file (333,603 IPs). Yes, there are probably many repeat IPs, but that's OK. Several (26 of them, consisting of two unique IPs) are when I accidentally blocked myself.
I took the resulting file and did this:
cat top10_1.txt | sort | uniq -c | sort -rn
which resulted in this file.
The IPs with a count of '238' are obviously part of a distributed brute forcing botnet...its intriguing the way it is depicted within this hack's output. Also, the actual number of unique IPs recorded is 2377.
Now, maybe I should script something to provide me something like this on a daily basis...meaning, I'd like to see only that day's activity (right now, I'm crunching logs from at least a year back).
Also, this is from my FreeBSD machine, which runs PF, has port 22 open to the world (locked down service, though), has port 3306 open, and is my security box.
Saturday, January 30, 2010
SANS Article -- Weathering the Storm Part 2
Weathering the Storm Part 2 @ http://blogs.sans.org/appsecstreetfighter/2010/01/29/weathering-the-storm-part-2-a-day-of-weblogs-at-the-internet-storm-center/
This is pretty cool. This article describes how to parse web server logs for RFI (remote file inclusion). It actually pinpoints the URLs that contain the malicious code.
At first I had an issue in following the logic of the write-up, but when I looked at the scripting, I edited it slightly and used the following:
Yeah, I unzipped the .gz files so that I could have the script parse ALL of the access logs. The result is here.
For people who want to perform forensics on these URLs, have at it but note that some of the links may be old and may no longer exist (or may be blocked or purposely taken down).
This is pretty cool. This article describes how to parse web server logs for RFI (remote file inclusion). It actually pinpoints the URLs that contain the malicious code.
At first I had an issue in following the logic of the write-up, but when I looked at the scripting, I edited it slightly and used the following:
cat access_log | cut -f2 -d'"' access_log* | grep '=http' | grep -v 'utmr=http' | sed 's/.*=http/http/' | uniq -c | sort -rn > /root/WTSP2.txt
Yeah, I unzipped the .gz files so that I could have the script parse ALL of the access logs. The result is here.
For people who want to perform forensics on these URLs, have at it but note that some of the links may be old and may no longer exist (or may be blocked or purposely taken down).
Sunday, January 17, 2010
Dshield Results From Log Donations
So, every day I submit logs to Dshield, I get a report from them with a breakdown of the submitted logs.
Here's an example:
All of this is valuable, and I can sometimes tune the IDS and FW based on the findings of these reports. There are other freeware tools that can do this type of data crunching, but I like the fact that if I'm donating logs, I'm getting a analysis report in return.
Now, the concern is that there's a lot of source IPs that appear to be owned by Amazon (Amazon Web Services). I'm hoping that most of these aren't EC2 hosts. If so, that indicates that Amazon has a security or abuse issue (or a combination of both). I'm hesitant to mention this to ISC since this may well be a trivial concern for them. Regardless of perception, I still believe this is more than likely an issue that should be pursued.
Here's an example:
For 2010-01-15 you submitted 496 packets from 136 sources hitting 2 targets.
Port Summary
============
Port | Packets | Sources | Targets | Service | Name
------+-----------+-----------+-----------+--------------------+-------------
445 | 63 | 17 | 2 | microsoft-ds | Win2k+ Server Message Block
5900 | 31 | 15 | 2 | vnc | Virtual Network Computer
135 | 46 | 14 | 2 | epmap | DCE endpoint resolution
1080 | 162 | 13 | 2 | socks | Proxy Server
22 | 19 | 12 | 2 | ssh | SSH Remote Login Protocol
23 | 9 | 9 | 2 | telnet |
1433 | 12 | 9 | 2 | ms-sql-s | Microsoft-SQL-Server
3389 | 11 | 7 | 2 | ms-term-services | MS Terminal Services
3072 | 12 | 6 | 1 | csd-monitor | ContinuStor Monitor Port
4899 | 7 | 5 | 2 | radmin | Remote Administrator default port
25 | 20 | 5 | 2 | smtp | Simple Mail Transfer
3128 | 13 | 5 | 2 | squid-http | Proxy Server
8000 | 10 | 5 | 2 | irdmi | iRDMI
8080 | 7 | 4 | 2 | http-alt | HTTP Alternate (see port 80)
139 | 7 | 3 | 2 | netbios-ssn | NETBIOS Session Service
7212 | 7 | 3 | 2 | |
21 | 5 | 3 | 1 | ftp | File Transfer [Control]
80 | 6 | 2 | 1 | www | World Wide Web HTTP
2967 | 2 | 2 | 1 | ssc-agent | Symantec System Center
1024 | 6 | 2 | 1 | |
Port Scanners
=============
source | Ports Scanned | Host Name
---------------+---------------+------------
173.192.192.92| 10 | 173.192.192.92-static.reverse.softlayer.com
221.192.199.35| 6 |
78.159.112.84| 5 |
77.223.143.18| 4 | 77-223-143-18.netdirekt.com.tr
222.215.230.49| 4 |
205.209.161.68| 3 |
67.51.137.218| 2 |
173.66.248.120| 2 | auth03.cs.net
188.132.196.173| 2 | datacenter-173-196-132-188.sadecehosting.net
68.237.174.120| 2 | static-68-237-174-120.lsanca.fios.verizon.net
206.217.205.170| 2 | noptr.midphase.com
66.159.229.149| 2 | netblock-66-159-229-149.dslextreme.com
222.208.183.218| 2 |
66.160.182.5| 2 | system-5.squaw.com
64.38.82.20| 2 |
174.129.185.251| 2 | ec2-174-129-185-251.compute-1.amazonaws.com
Source Summary
==============
source | hostname |packets|targets| all pkts | all trgs | first seen
---------------+-----------+-------+-------+----------+----------+-----------
66.160.182.5|5.squaw.com| 54 | 1 | 143 | 66 | 01-08-2010
79.125.50.62|azonaws.com| 33 | 1 | 14083 | 94 | 01-11-2010
79.125.39.245|azonaws.com| 27 | 1 | 5974 | 92 | 01-11-2010
174.129.93.137|azonaws.com| 27 | 1 | 16623 | 102 | 01-06-2010
174.129.161.206|azonaws.com| 21 | 1 | 8258 | 99 | 01-11-2010
174.129.137.234|azonaws.com| 15 | 1 | 2328 | 90 | 01-14-2010
221.192.199.35| | 13 | 1 | 63162 | 2825 | 01-05-2010
79.125.44.37|azonaws.com| 12 | 1 | 6155 | 88 | 01-12-2010
173.192.192.92|ftlayer.com| 10 | 1 | 287815 | 25717 | 12-31-2009
222.215.230.49| | 9 | 2 | 225112 | 6288 | 05-28-2008
79.125.32.165|azonaws.com| 9 | 1 | 2346 | 89 | 01-14-2010
94.59.233.125| | 7 | 1 | 29 | 13 | 01-15-2010
77.223.143.18|rekt.com.tr| 7 | 1 | 120123 | 20906 | 12-28-2009
78.159.112.84| | 6 | 1 | 7356 | 3206 | 01-15-2010
188.132.196.173|hosting.net| 6 | 1 | 2606 | 1735 | 01-13-2010
118.161.243.145|c.hinet.net| 6 | 1 | 54 | 8 | 01-15-2010
64.38.82.20| | 5 | 1 | 894 | 446 | 01-15-2010
205.209.161.68| | 5 | 1 | 278 | 245 | 01-15-2010
204.236.194.181|azonaws.com| 5 | 1 | 8563 | 95 | 01-10-2010
204.236.244.234|azonaws.com| 4 | 1 | 10215 | 155 | 01-05-2010
All of this is valuable, and I can sometimes tune the IDS and FW based on the findings of these reports. There are other freeware tools that can do this type of data crunching, but I like the fact that if I'm donating logs, I'm getting a analysis report in return.
Now, the concern is that there's a lot of source IPs that appear to be owned by Amazon (Amazon Web Services). I'm hoping that most of these aren't EC2 hosts. If so, that indicates that Amazon has a security or abuse issue (or a combination of both). I'm hesitant to mention this to ISC since this may well be a trivial concern for them. Regardless of perception, I still believe this is more than likely an issue that should be pursued.
Thursday, January 14, 2010
Dshield; Verizon FiOS
I've finally got this running.
I spent a bit of time with it last night and found that the dshield.cnf file had some errors.
I still need to tune it, though, because the script is reporting non-malicious web traffic to Dshield...I'll need to exclude all non-attacks and non-probes.
On another note, I'm at home today since we're getting FiOS installed. This service will replace Direct TV and Comcast. I'm looking forward to a dedicated internet connection. I'll be getting the 25/15 (down/up) internet pipe (YES) and two DVRs (I hope to replace the circa-2003 Tivo soon, with something better).
I spent a bit of time with it last night and found that the dshield.cnf file had some errors.
I still need to tune it, though, because the script is reporting non-malicious web traffic to Dshield...I'll need to exclude all non-attacks and non-probes.
On another note, I'm at home today since we're getting FiOS installed. This service will replace Direct TV and Comcast. I'm looking forward to a dedicated internet connection. I'll be getting the 25/15 (down/up) internet pipe (YES) and two DVRs (I hope to replace the circa-2003 Tivo soon, with something better).
Monday, January 11, 2010
What's Up With All The Port Scanning Using TCP/6000 As A Source Port?
What's Up With All The Port Scanning Using TCP/6000 As A Source Port?
Yeah, this is from ISC. I've been noticing this for awhile, but I thought it was just noise. Apparently, others noticed it too. Here's what I have (example snippet):
syslog:Jan 10 14:16:03 none kernel: BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f
c:8b:69:08:00 SRC=221.194.45.3 DST=66.160.141.30 LEN=40 TOS=0x00 PREC=0x00 TTL=109 ID=256
PROTO=TCP SPT=6000 DPT=1521 WINDOW=16384 RES=0x00 SYN URGP=0
syslog:Jan 10 15:44:17 none kernel: BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f
c:8b:69:08:00 SRC=218.240.32.166 DST=66.160.141.30 LEN=40 TOS=0x00 PREC=0x00 TTL=110 ID=25
6 PROTO=TCP SPT=6000 DPT=2967 WINDOW=16384 RES=0x00 SYN URGP=0
syslog:Jan 10 16:21:55 none kernel: BLOCKED: IN=eth0 OUT= MAC=fe:fd:40:3e:e7:dc:00:0c:db:f
c:8b:69:08:00 SRC=61.182.168.30 DST=64.62.231.220 LEN=40 TOS=0x00 PREC=0x00 TTL=107 ID=256
Yeah, I've been blocking these. It's pretty easy, as I've a firewall policy that just flat-out blocks anything I don't outright allow...It's pretty hardcore. For those who think that "port 80 will always be open" (yeah, I do run a web-server), Modsecurity covers that port...but I'm deviating from the topic of this post.
No one seems to know what the offending IPs are doing, but most appear to originate from China. I'm running a tcpdump to try to gather data, but so far I don't have much (6 hours of sniffing only shows 4 hits so far).
I'm using the following tcpdump command:
tcpdump -i eth0 -Xvvnne -s 0 src port 6000 -w /tmp/dump_src_port_6000
I'll leave it running for 24 hours then check and see what I have...it might not amount to much, though.
UPDATE:
One thing I noticed right off the bat was the destination ports...they are all affiliated with MS Windows services (ports 135, 139, 1433, 2967, 1521) but also ports such as 8000, 8080 and 7212. Weird. I'll keep the sniff going for a few days (a week's worth of sniffing, maybe).
UPDATE #2:
Decided to kill the tcpdump process to see what's going on and post it here. Will start it up again before I head to bed (I doubt I'm missing much so far):
root@starchild:~# tcpdump -Xvvnes -0 -r /tmp/dump_src_port_6000
reading from file /tmp/dump_src_port_6000, link-type EN10MB (Ethernet)
20:06:55.553601 00:0c:db:fc:8b:69 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 107, id 256, offset 0, flags [none], proto TCP (6), length 40) 221.195.73.68.6000 > 66.160.141.30.8000: S, cksum 0x3a87 (correct), 132448256:132448256(0) win 16384
0x0000: 4500 0028 0100 0000 6b06 580a ddc3 4944 E..(....k.X...ID
0x0010: 42a0 8d1e 1770 1f40 07e5 0000 0000 0000 B....p.@........
0x0020: 5002 4000 3a87 0000 P.@.:...
21:06:16.773790 00:0c:db:fc:8b:69 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 109, id 256, offset 0, flags [none], proto TCP (6), length 40) 121.101.212.38.6000 > 66.160.141.30.1433: S, cksum 0xca79 (correct), 1796538368:1796538368(0) win 16384
0x0000: 4500 0028 0100 0000 6d06 2f86 7965 d426 E..(....m./.ye.&
0x0010: 42a0 8d1e 1770 0599 6b15 0000 0000 0000 B....p..k.......
0x0020: 5002 4000 ca79 0000 P.@..y..
21:36:31.664717 00:0c:db:fc:8b:69 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 110, id 256, offset 0, flags [none], proto TCP (6), length 40) 60.13.26.66.6000 > 64.62.231.220.1433: S, cksum 0xd34d (correct), 19005440:19005440(0) win 16384
0x0000: 4500 0028 0100 0000 6e06 cd66 3c0d 1a42 E..(....n..f<..B
0x0010: 403e e7dc 1770 0599 0122 0000 0000 0000 @>...p..."......
0x0020: 5002 4000 d34d 0000 P.@..M..
22:00:21.259640 00:0c:db:fc:8b:69 > fe:fd:40:3e:e7:dc, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 106, id 256, offset 0, flags [none], proto TCP (6), length 40) 222.45.112.219.6000 > 66.160.141.30.135: S, cksum 0xe3c1 (correct), 1432485888:1432485888(0) win 16384
0x0000: 4500 0028 0100 0000 6a06 3109 de2d 70db E..(....j.1..-p.
0x0010: 42a0 8d1e 1770 0087 5562 0000 0000 0000 B....p..Ub......
0x0020: 5002 4000 e3c1 0000 P.@.....
I'm not seeing much but my FW is definitely not helping things, either (killing the connections, which is why you can only see syn packets). Well, anyone else want to guess what's going on?
Saturday, January 09, 2010
Been awhile...
So, what am I doing currently?
I've been having an issue getting a print server (Linksys PSUS4) to work with anything other than Windows.
I've two Macs in the house that do NOT like this print server. I've yet to test it in Linux but my wife is one of the people that uses the Macs heavily, so the Linux alternative won't work for her.
For now, I'm attempting to utilize my main Linux machine, 'slackbox' as a print server by using CUPS. The version of Slackware that this machine is using is v12.0. I've found that there is HPLIP support for Slackware v12.0 but I'll need to update the HPLIP version (it is currently at v1.7.4). So, I've the option of attempting to patch the current install to the latest version (no, I've not been keeping up with patches), or compile the latest version from sources and install it to the Slackware machine.
Another thing I've found is that http://packages.slackware.it/ has been down since at least this past October. I didn't realise how crucial this Slackware service was, but I'm hoping that this gets fixed soon or that Pat V. eventually addresses the issue by standing up his own service. As much as I agree with the manual approach to Linux, there will come a time to where some things may have to become simplified...this is one of those things, I think.
Anyways, I'll update this post with any notes as I continue to work around the print server issue (so that my wife can quit nagging me and making bad assumptions about things she doesn't understand).
I've been having an issue getting a print server (Linksys PSUS4) to work with anything other than Windows.
I've two Macs in the house that do NOT like this print server. I've yet to test it in Linux but my wife is one of the people that uses the Macs heavily, so the Linux alternative won't work for her.
For now, I'm attempting to utilize my main Linux machine, 'slackbox' as a print server by using CUPS. The version of Slackware that this machine is using is v12.0. I've found that there is HPLIP support for Slackware v12.0 but I'll need to update the HPLIP version (it is currently at v1.7.4). So, I've the option of attempting to patch the current install to the latest version (no, I've not been keeping up with patches), or compile the latest version from sources and install it to the Slackware machine.
Another thing I've found is that http://packages.slackware.it/ has been down since at least this past October. I didn't realise how crucial this Slackware service was, but I'm hoping that this gets fixed soon or that Pat V. eventually addresses the issue by standing up his own service. As much as I agree with the manual approach to Linux, there will come a time to where some things may have to become simplified...this is one of those things, I think.
Anyways, I'll update this post with any notes as I continue to work around the print server issue (so that my wife can quit nagging me and making bad assumptions about things she doesn't understand).
Sunday, November 15, 2009
Emergingthreats.com sigs...
Quick note:
One thing I hate about emergingthreats.com sigs is the fact that the sigs have no real documentation. Yeah, I know there's a site (a few, in fact) that provide this (via opensource efforts), but I much prefer to not have to research each and every sig all the time I'm investigating something.
One thing I hate about emergingthreats.com sigs is the fact that the sigs have no real documentation. Yeah, I know there's a site (a few, in fact) that provide this (via opensource efforts), but I much prefer to not have to research each and every sig all the time I'm investigating something.
Monday, August 17, 2009
FW Log Check
Doing a remote check of FW activity, I've found that the FW has blocked MANY IPs in the last 9 days:
All I can say is, "WOW!!" There was a HUGE spike in July (maybe due to summer vacation of most kids). Unfortunately, my logs don't go back beyond June.
I'm curious as to how August will be but I can already see that the number will be high. I'll update the blog as I as continue to watch.
[EDIT: I checked August's count and it is below:
September (so far) is:
I think I'll start scripting this command to run every week so that I can start trending.[09/15/2009]]
[Edit:
So, it is 7/19/2011. I will try to graph what I'm about to provide, but here's what I have after zcatting some .gz files:
[root@delly ~]# zcat /var/log/bruteforce.0908* | wc -lThose are all unique IPs. Out of curiosity, I checked July's and May's logs:
11424
[root@delly ~]# zcat /var/log/bruteforce.0907* | wc -l
40511
[root@delly ~]# zcat /var/log/bruteforce.0906* | wc -l
10121
All I can say is, "WOW!!" There was a HUGE spike in July (maybe due to summer vacation of most kids). Unfortunately, my logs don't go back beyond June.
I'm curious as to how August will be but I can already see that the number will be high. I'll update the blog as I as continue to watch.
[EDIT: I checked August's count and it is below:
zcat /var/log/bruteforce.0908* | wc -l
40761
September (so far) is:
zcat /var/log/bruteforce.0909* | wc -l
20186
I think I'll start scripting this command to run every week so that I can start trending.[09/15/2009]]
[Edit:
So, it is 7/19/2011. I will try to graph what I'm about to provide, but here's what I have after zcatting some .gz files:
2011:
[root@delly ~]# zcat /var/log/bruteforce.1107* | wc -l
58589
[root@delly ~]# zcat /var/log/bruteforce.1106* | wc -l
91736
[root@delly ~]# zcat /var/log/bruteforce.1105* | wc -l
93765
[root@delly ~]# zcat /var/log/bruteforce.1104* | wc -l
89521
[root@delly ~]# zcat /var/log/bruteforce.1103* | wc -l
91337
[root@delly ~]# zcat /var/log/bruteforce.1102* | wc -l
81415
[root@delly ~]# zcat /var/log/bruteforce.1101* | wc -l
89971
2010:
[root@delly ~]# zcat /var/log/bruteforce.1012* | wc -l
90024
[root@delly ~]# zcat /var/log/bruteforce.1011* | wc -l
87120
[root@delly ~]# zcat /var/log/bruteforce.1010* | wc -l
89748
[root@delly ~]# zcat /var/log/bruteforce.1009* | wc -l
85585
[root@delly ~]# zcat /var/log/bruteforce.1008* | wc -l
84738
[root@delly ~]# zcat /var/log/bruteforce.1007* | wc -l
66438
[root@delly ~]# zcat /var/log/bruteforce.1006* | wc -l
62905
[root@delly ~]# zcat /var/log/bruteforce.1005* | wc -l
63421
[root@delly ~]# zcat /var/log/bruteforce.1004* | wc -l
60478
[root@delly ~]# zcat /var/log/bruteforce.1003* | wc -l
59006
[root@delly ~]# zcat /var/log/bruteforce.1002* | wc -l
44380
[root@delly ~]# zcat /var/log/bruteforce.1001* | wc -l
45392
2009:
[root@delly ~]# zcat /var/log/bruteforce.0912* | wc -l
48281
[root@delly ~]# zcat /var/log/bruteforce.0911* | wc -l
45127
[root@delly ~]# zcat /var/log/bruteforce.0910* | wc -l
44254
[root@delly ~]# zcat /var/log/bruteforce.0909* | wc -l
40185
[root@delly /var/log]# zcat bruteforce.* |wc -l
1704809
[root@delly /var/log]# zcat bruteforce.* |wc -l | uniq
1704809
]
Sunday, August 16, 2009
Strange traffic in Snort logs
Yesterday, I was messing around with an older machine which had an older version (and rules) of Snort.
I let it run overnight, sniffing internal network traffic. Today, I checked the logs and saw the following:
So, I've a few questions:
1. Who is 10.150.1.133?
2. Who is 204.176.49.2 and 204.176.49.9?
3. So, I have a Tivo system in the house (the payload confirms this). Why is my Tivo calling out to an IP address that is owned by Verizon Business?
4. Why is my production internal Snort sensor not picking up this traffic but this test internal sensor is?
I've some answers to those questions:
1. 10.150.1.133 is a WRT54GX4 Linksys router. This was somewhat difficult for me to find out, because my main router doesn't normally chat to this particular router (it is isolated). The WRT54GX4's sole purpose is to provide internet connectivity for my Tivo. The Tivo is using an old USB wifi connection that only has WEP support, so I use the WRT54GX4 to provide connectivity for the Tivo, lessening the risk in using WEP by isolating the WAP from the rest of the network. In order for me to find out what IP the Tivo is using, I'd have to sniff the traffic on the WRT54GX4's network, which I don't normally do. What I did instead was ping the IP, then check the arp table of the machine I pinged from. This told me the hostname and MAC address of the IP. Once I saw the hostname, I knew it had to be the Tivo generating this traffic (the payload above also helped).
2. I did a 'whois' search on IPs 204.176.49.2 and 204.176.49.9. Both show as belonging to Verizon Business. What threw me for a loop was that I was expecting it to show as owned by Tivo. After thinking on this a bit, it is more than likely that Verizon Business is providing IP space to Tivo (and maybe other hosting services). That is news to me, since I actually work for Verizon Business and am heavily involved in networking services.
3. I conducted Google searches on the IPs and came up with tons of hits. Some hits documented people who saw traffic outbound from their network to those IPs and they were concerned, but most of the hits show that the outbound connections are part of the Tivo service.
4. It is obvious that I have to compare the two internal Snort sensor's config files, specifically the http_inspect settings. Both internal sensors are on the same subnet (the Tivo is not...the WRT router is behind my main router and uses different IP space...the Tivo is behind this router), so both should've seen it. This leads me to believe that I've been missing some internal traffic, so I'll look into this issue soon.
I just wanted to post this so that when/if everyone that owns a Tivo sees such traffic, they won't get alarmed (I didn't see a specific page that stated that this was normal traffic).
I let it run overnight, sniffing internal network traffic. Today, I checked the logs and saw the following:
root@slackbox:/var/log/snort# cat alert | grep 204.176.49.2The whole trace is here, since Blogger tends to choke on Hex payload
10.150.1.133:32834 -> 204.176.49.2:80 TCP TTL:63 TOS:0x0 ID:40635 IpLen:20 DgmLen:576 DF
10.150.1.133:32882 -> 204.176.49.2:80 TCP TTL:63 TOS:0x0 ID:22086 IpLen:20 DgmLen:576 DF
So, I've a few questions:
1. Who is 10.150.1.133?
2. Who is 204.176.49.2 and 204.176.49.9?
3. So, I have a Tivo system in the house (the payload confirms this). Why is my Tivo calling out to an IP address that is owned by Verizon Business?
4. Why is my production internal Snort sensor not picking up this traffic but this test internal sensor is?
I've some answers to those questions:
1. 10.150.1.133 is a WRT54GX4 Linksys router. This was somewhat difficult for me to find out, because my main router doesn't normally chat to this particular router (it is isolated). The WRT54GX4's sole purpose is to provide internet connectivity for my Tivo. The Tivo is using an old USB wifi connection that only has WEP support, so I use the WRT54GX4 to provide connectivity for the Tivo, lessening the risk in using WEP by isolating the WAP from the rest of the network. In order for me to find out what IP the Tivo is using, I'd have to sniff the traffic on the WRT54GX4's network, which I don't normally do. What I did instead was ping the IP, then check the arp table of the machine I pinged from. This told me the hostname and MAC address of the IP. Once I saw the hostname, I knew it had to be the Tivo generating this traffic (the payload above also helped).
2. I did a 'whois' search on IPs 204.176.49.2 and 204.176.49.9. Both show as belonging to Verizon Business. What threw me for a loop was that I was expecting it to show as owned by Tivo. After thinking on this a bit, it is more than likely that Verizon Business is providing IP space to Tivo (and maybe other hosting services). That is news to me, since I actually work for Verizon Business and am heavily involved in networking services.
3. I conducted Google searches on the IPs and came up with tons of hits. Some hits documented people who saw traffic outbound from their network to those IPs and they were concerned, but most of the hits show that the outbound connections are part of the Tivo service.
4. It is obvious that I have to compare the two internal Snort sensor's config files, specifically the http_inspect settings. Both internal sensors are on the same subnet (the Tivo is not...the WRT router is behind my main router and uses different IP space...the Tivo is behind this router), so both should've seen it. This leads me to believe that I've been missing some internal traffic, so I'll look into this issue soon.
I just wanted to post this so that when/if everyone that owns a Tivo sees such traffic, they won't get alarmed (I didn't see a specific page that stated that this was normal traffic).
Thursday, August 06, 2009
Linode uptime
ron@starchild:~$ w
18:09:25 up 417 days, 5:21, 2 users, load average: 0.01, 0.01, 0.00
Last year, I had the around the same, per linuxcounter.org's stats:
ID Name Last auto-update Uptime
316269 starchild 2008-05-12 00:06:02 414.8
Nice, huh?? Don't let the load average fool you...it has a decent load at certain intervals, and that doesn't include when I'm doing maintenance.
Non-Slackware post
Working on my Dell Mini with gOS installed, I've edited the dock bar to include Mozilla's Thunderbird. Basically I edited .wbar in my ~/home dir...I've added the following:
I added this under the Firefox entry.
The dock looked like this before the change:

The dock now looks like this:

I actually had to experiment with this. Apparently, the gOS forums lack this documentation, as I haven't seen any documentation on how to change the dock's format, so I'm posting it here.
EDIT: Wbarconf under "gOS/accessories" is apparently the tool to use to edit the dock bar. Found that tidbit of info here. Note the date of Oct 2008. Although I found the answer on my own, I searched the internet after I applied my edit, checking to see how prevalent the info is...its not that prevalent. That's about the only hit I got, other than one other explaining to download some GUI tool that would allow editing of the dock.
EDIT: Another link describing how to edit the dock bar. Look for "How to add edit and delete the content of the "dock" (Wbar)"
Also, after reading Linux Format LXF119, I've decided to try some hard disk information tools: Filelight, a tool that shows graphical representation of hard disk usage and HardInfo, which is a system profiler/benchmarker. Screenshots are below. Both are decent tools and I recommend them.
Filelight:

HardInfo:
i: /usr/share/icons/gOS3_Icons/scalable/apps/mozilla-thunderbird.png
c: glaunch thunderbird.desktop
t: Thunderbird
I added this under the Firefox entry.
The dock looked like this before the change:

The dock now looks like this:

I actually had to experiment with this. Apparently, the gOS forums lack this documentation, as I haven't seen any documentation on how to change the dock's format, so I'm posting it here.
EDIT: Wbarconf under "gOS/accessories" is apparently the tool to use to edit the dock bar. Found that tidbit of info here. Note the date of Oct 2008. Although I found the answer on my own, I searched the internet after I applied my edit, checking to see how prevalent the info is...its not that prevalent. That's about the only hit I got, other than one other explaining to download some GUI tool that would allow editing of the dock.
EDIT: Another link describing how to edit the dock bar. Look for "How to add edit and delete the content of the "dock" (Wbar)"
Also, after reading Linux Format LXF119, I've decided to try some hard disk information tools: Filelight, a tool that shows graphical representation of hard disk usage and HardInfo, which is a system profiler/benchmarker. Screenshots are below. Both are decent tools and I recommend them.
Filelight:

HardInfo:

Labels:
.wbar,
dock,
Filelight,
gOS,
HardInfo,
LinuxFormat,
Mozilla,
Thunderbird
Subscribe to:
Posts (Atom)