58.221.32.117 hammering my server

I've been seeing 58.221.32.117 in my logs, especially within the last week or so.  So far, I've 5,356 instances of blocking by the firewall for this particular IP.  All traffic is coming from source port 80 of that IP.  Yes, every single instance was blocked.

Has anyone else seen similar activity from this IP?

A whois shows the following:

IP address [?]:	58.221.32.117 [Whois] [Reverse IP]
IP country code:	CN
IP address country:	China
IP address state:	Beijing
IP address city:	Beijing
IP address latitude:	39.9289
IP address longitude:	116.3883
ISP of this IP [?]:	CHINANET jiangsu province network
Organization:	CHINANET jiangsu province network
Local time in China:	2010-10-06 10:29

E-mail Malware Attempt

I've a friend that I got an e-mail from.  It had an empty subject line and one URL in the body.  Twenty others were sent the same e-mail.

I notified the sender that they had an issue.  I then decided to use Web-Sniffer to attempt to visit the link and do a quick investigation.

When visiting via the web proxy, I observed the following:

 The web server was up and running, serving content but threw a code 302.  It also may have attempted to redirect to hxxp://uvuhjomuph.com (I obfuscated the link).  Clicking that URL takes me to an ED page (erectile dysfunction):

Googling that domain, I got at least one good hit:

So, my friend more than likely got phished and her e-mail account is now throwing out spam for penile meds.  :(

Protect your privates!

Protect your privates!

http://isc.sans.edu/diary.html?storyid=9367


In view of all the brute force attacks still being attempted against Secure Shell (SSH), we have long since been extolling the virtues of forgoing passwords and moving to RSA/DSA keys instead.
While key based login indeed nicely addresses the problem of password guessing attacks, it looks like many a Unix admin has been less than diligent in the implementation. In pretty much every Unix security audit recently, we've come across unprotected or badly protected SSH private keys (id_dsa, id_rsa). Some reside plain flat out in the open, in /tmp and such. Others are found in world-readable tar "backup" archives of user and administrator home directories. Some are even built into home-grown Linux RPM and Solaris PKG packages, ready to be plucked off an install server.

Failure of controls...Spanair crash caused by a Trojan

 Failure of controls...Spanair crash caused by a Trojan

Several readers have pointed us to an article about the preliminary report of the Spanair flight that crashed on takeoff in 2008 killing 154. The article suggests that a Trojan infected a Spanair computer and this prevented the detection of a number of technical issues with the airplane. The article speculates that if these issues had been detected the plane would not have been permitted to attempt take off.

NOTE:  Another article is here.  Another is here, and this one supports the error being on the pilots' behalves (bad pre-flight checks).

Splunk?

Been thinking on trying Splunk, a console that can monitor multiple system logs, along with health and security alerts.

I'll post more as I delve into this intriguing tool.

SAGAN: An open-source event correlation system - Part 1: Installation (from isc.sans.org)

SAGAN: An open-source event correlation system - Part 1: Installation

 SAGAN can be found here.

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.

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.

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.

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.

http://www.trustedsource.org/query/74.53.76.11

http://www.dshield.org/ipdetails.html?ip=74.53.76.11

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

http://www.dshield.org/ipinfo.html?ip=124.217.254.63

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.

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

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! :)

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:

TrustedSource
myNetWatchman

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.

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:

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

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:

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.

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

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?

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