BASE and Snorby: packet captures

Noticed that someone on the interwebz stated that Snorby captures full payload while BASE doesn't.  I read this as a comment on the Snorby pages.  Unless I'm totally off-base here, that's not the case, unless they're taking about something like netflows or something akin to it.  I believe one of the dev guys stated that only Snorby and Sguil offer full packet capturing.  That does NOT sound right and I believe he should clarify.

I'll dig up the link later, but it should be very apparent on their pages (it was to me, when I was perusing).

So, I pulled up my BASE console and looked at a sample packet.  To look at payload/packets within BASE, you go to a line item then click on the "ID", which would look akin to "2-278900". 

BASE capture view:

Snorby capture view:

Now, I don't see either lacking in that regard.  This is enough for the analyst to determine a false positive vs. a real attack/concern.

Now, if I wanted to further investigate, I can (in BASE), go to a listing, then click the offending IP (or the other IP...doesn't matter).  Then I click "Unique alerts" or "Unique IP links" under "Summary Statistics":

 

Unique alerts

This is basic stuff here.  It shows the history of that particular IP...it shows everything that was ever recorded from that IP, and you can dig down from there.  Source/Destination would show bidirectional traffic between the offending IP and whatever it was communicating with.  I'll get payload every time, IF (BIG IF HERE) the Snort signature is designed to capture payload and if the traffic even has payload.

I don't understand the argument of saying that BASE doesn't capture full payload.  Of course, BASE won't.  It's just a SEM.  Snort would actually do the capturing.  It would also totally depend on who sets up Snort and their requirements.  The admin that configures Snort may not even have all the sigs enabled.  But, BASE will show any payload that Snort does capture.

At this point, Snorby's search and analytical functionality is lacking.  I've said this before and got ridiculed by one of the Snorby developers.  We all know Snorby is relatively new when comparing it to BASE, but until the Snorby dev team enables better query functionality and better ways to quickly track activity, I'm going to stick to my guns.  A pretty (and even simplified) interface is one thing, but when it comes to the meat and potatoes, candy apples doesn't cut it.  As an analyst, I'd not want to lose any type of query features, as this will make a sometimes frustrating job all the more frustrating (been there, done that).

Lastly, I will NOT HAVE A PISSING MATCH over this.  I've been doing such comparisons for YEARS and am fully capable of judging what is acceptable and what is not regarding most security tools (that's why I get paid the big bucks), although I'm always objective in my opinions.  I definitely know what "best of breed" entails.  I'm going to put it out there:  Snorby is NOT best of breed.  I'd love it to be, but right now, it is NOT.  It has to help me sort/organize/filter information that helps me catch malware and such...much more that what it currently offers.  Right now, with Snorby, there's no such thing as digging down or simplifying the search through thousands of potentially bad security events.  "Packet capture options/Customer" isn't going to cut it.  It is good for the small investigation but not for the bigger tasks.  Let's be grown-ups about this topic and offer objective opinions.  If you can't do that, don't even try to leave some nasty comment on this blog.  Comments moderation is enabled.  Yes, I do require clarification on what is considered "full payload analysis", as I feel that's not enough of a description and could actually be relating to something else entirely different that the above (I doubt it, though).

GUIs for Snort

GUIs for Snort --

http://blog.snort.org/2011/01/guis-for-snort.html

Some of these might appeal to you, the network/security administrator, depending on your organization's needs. Note: there is NO best in breed tool...it totally depends on your organization's needs, which will vary when comparing org X to org Y.

HTTP Viewers

I found something that is very similar to Web-sniffer.net (an HTTP viewer/proxy)...it is called "Rex Swain's HTTP Viewer". That's a mouthful, so I'll call it RSHV.

One thing that Web-sniffer can't do is allow for referer configuration. RSHV will let you configure the referer (in fact, this appears to be a recently added feature). Why is this sometimes important? Read here. In comparison to Web-Sniffer.net, RSHV is better documented. A con of RSHV is that it won't do HTTPS.

Why do I call these HTTP viewers proxies? Well, they are. When you utilize those tools to view, for example, pages/headers at wigglit.ath.cx, if you check the web logs at wigglit.ath.cx, you'll see the traffic you generated came from someone else's IP (and not the one that was assigned to your machine when you visited wigglit.ath.cx). That's a protection, in my opinion...this means you can conduct research without having to use a lab system to prevent infection.

Note that the services these two tools provide can be done on pretty much any computer (*nix or win32/64). Just use telnet. Of course, wget can also be used (or fetch or curl), but I consider that to be a more cumbersome solution (although you may be able to create scripts that you can use wget/fetch/curl with).

Utilizing such tools in such a manner is important when conducting security analysis (for instance, validating that a certain website is or isn't compromised and serving malware).

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.