Saturday, February 26, 2011

Let’s Get For/Sec-Motivated!

While the NYT has been waxing prosaic that Blogs Wane as the Young Drift to Sites Like Twitter I take heart that I tend to be both old(er) and require a verbosity in communication that sites like Twitter and Facebook just cannot satisfy.  Mitch Joel has a great response to the NYT article in his Blogging Is Dead (Again) | Six Pixels of Separation Blog. And I am encouraged by two points he offers; “Blogging isn’t dead. Blogging is publishing.” and “Blogging is hard.”  From Mitch’s post:

Blogging is hard.

Blogging is hard because writing is hard. Writing is hard because finding the time to do real critical thinking and then to put those thoughts down in writing is even more complex. Reading, research, critical thinking, writing, editing and publishing isn't like posting a picture to tumblr or texting off a tweet. They're different beasts and they deserve different forms of metrics and comparison.

So despite the visible slowdown in GSD posting here, I assure my gentle readers that it’s because my boots have been on the ground, in the trenches, getting very dirty with real-world experiences.  I’ve been studying books, taking notes, putting into practice, crafting and refining.  And along the way taking names, linkage, and notes.

So please enjoy this labor-of-love blogging post today.  And special credit to two extra-special things I noted this week that helped me get focused:

  1. My “new post ranking” on the sidebar of the Windows Incident Response blog hadn’t sunk to dead-bottom yet, but was slowly getting closer and needed to be “bumped up”, and
  2. For some really bizarre reason bound to be the result of an interdimensional rift, E-Evidence Information Center - Blogs & Wikis made a grave error with the consequence of having Harlan Carvey’s Windows Incident Response blog listed at the top of the left-column and this humble blog listed alongside at the top of the right-hand column.  I’m not worthy…I’m not worthy!  Hopefully that will resolve itself dropping GSD a bit lower into the link-pile.  In the meantime I better represent!

Collections

Since it’s already come e up, it seems natural to start this LinkFest off with this WindowsIR blog post Links, Tools and Stuff.  At the end of the post, Harlan has a list of forensic/security related tool sites.  I’ve listed his finds below with a few others as well:

Wi-Fi Mapping/Monitoring Resources

A while back in the GSD post Security and Forensics Watch-List: GSD Linkfest Style I touched on some great (and free) Wi-Fi signal discovery tools; the inSSIDer 2.0 Wi-Fi Scanner or NirSoft’s WirelessNetView or the eye-candy rich Xirrus Wi-Fi Inspector.

Corey Harrell of Journey into Incident Response blog kindly left a comment on that post bringing my attention to Ekahau HeatMapper - The Free Wi-Fi Coverage Mapping Site Survey Tool.  While I was able to use inSSIDer on a recent incident response event to pinpoint a rouge Wi-Fi device and neutralize it, I truly believe the Ekahau product may have been able to help me better had I known about it at the time.

Since then, other similar tools such as Vistumbler and PassMark WirelessMon have come to my attention as well that not only provide Wi-Fi signal monitoring but also “heat-mapping” features.

New Stuff

There seems to have been a slight slowdown in the number of new “sparkly things” in terms of security/forensic software/freeware tools that usually makes me react like a Bowerbird to a shiny new object.

Fresh on the heels of DEFT Linux 6 getting released, Brett Shavers over at the Windows Forensic Environment (WinFE) blog announced It’s time to build your WinFE! having put together a very slick WinFE WinBuilder package.  It’s no secret I’m a mad WinPE builder and this WinFE builder is top-notch and will provide a very slick WinFE build with minimal fuss.  Check out Brett’s hard efforts for yourself.

JADsoftware has both installable and portable versions of Internet Evidence Finder v4 available: Internet Evidence Finder v4 – Standard Edition and Internet Evidence Finder v4 – Portable Edition.  Although not free, there are free-trial versions available for immediate download.  What’s more according to Brett Shavers’ post Portable Internet Evidence Finder and WinFE, it works just fine in a WinFE build!

Now out via SecurityOrb.com » Feb Edition of Hackin9

Lightbox Technologies is readying a release of Lightgrep.  First spotted via JL’s stuff: NYC4SEC Meeting 1/19/2011 blog post, this looks to be an interesting tool.

In the meantime, there is still the free Windows Grep tool AstroGrep. Other handy utilities are File Hound 3.2, Windows Grep, PRGrep, GREP for Windows, and my favorite, BareGrep.

Port Monitoring / SPAN port / Misc Network Traffic Monitoring Resources

Instead of using a network tap connection to monitor traffic, I rely upon a dedicated capture system hooked into a switch port configured with the port set to a particular SPAN configuration.  So far this configuration has worked golden.

I’ve posted these resources before on GSD, but I keep finding them so valuable I can’t help but repost them again, just in case someone stumbles across this post.

TaoSecurity post on SPANs versus Taps: TaoSecurity: Expert Commentary on SPAN and RSPAN Weaknesses

It links to two MOST Excellent articles on the issues of using spanned switch ports for collecting your network capture data, both form Tim O’Neill:

OK, now the linkage on SPAN’ing

And my oldies but goodies favorites:

CDP - What Switch Am I Connected To? and Monitoring Traffic with Span Ports – SynJunkie.  Two really great posts out of series of ones touching on network monitoring, and Cisco switch/router configuration techniques.  I’m singling these out in particular as they are of interest to sysadmin troubleshooting on the network as well as traffic captures.

And recently found this Wireshark Wiki article as well -- CaptureSetup/Ethernet.

So during a recent troubleshooting exercise regarding network traffic capture analysis, I kept pounding my head on the desk because the data I was collecting just was turning up to be frustratingly non-helpful.  My data from source A wasn’t matching my observed data from source B.  After a week of forehead soreness I finally realized I wasn’t capturing any TCP/UDP traffic at all!  Turns out this model of Cisco switch required a different port mirroring configuration than the standard one used. With the help of a cubicle buddy, we figured out the correct configuration settings, applied them, captured the network traffic data again, and within an hour I had the problem identified and resolved. Easy-Peasy.

That said, it drove home that while my Wireshark/Network Monitor skills may be getting much better, if I can’t self-evaluate the correctness of switch configurations, I may waste a bunch of time working off someone else’s assumptions.

So I ended up collecting the following additional links that were helpful in this regard:

Network Assessment and Analysis

There are some great updates in the realm of network assessment tools. 

My foundational tool are

These tools along with information of networks from Cisco Network Assistant generally can provide me a pretty good view of what is going on when I am analyzing network traffic captures.

However, lately I’ve been trying to add depth to my bench.

Nmap - Free Security Scanner For Network Exploration & Security Audits has been recently released at version 5.50.  I snagged a GUI-supported build Nmap 5.51 at FileHippo.com.  I’m still getting my feet wet on it with my home network before I expand usage onto our production environment but I am very impressed.

Erik Hjelmvik has recently kicked off his NETRESEC NetworkMiner website that offers both the free version of NetworkMiner we have all come to love and adore as well as a Professional version that offers result exporting, Host coloring support, and CLI scripting.  Erik’s site also includes a Blog so you can follow current events.  If you didn’t hear (who hasn’t) NetworkMiner has been released at version 1.0.  PCAP loading speeds are very much improved, no bomb-outs on pcaps that have particular packet errors in the capture, and a few new bells and whistles.

Despite Lavie’s teasing's, I am certain I’ve not yet fallen asleep with my copy of Laura Chappell’s Wireshark Network Analysis book on my chest…though truth be told it is rarely beyond fingertip reach lately.  I’ve learned a ton of great techniques and filters already and I’m only 1/4 of the way though!

I keep three installed version levels of Wireshark on my system.  I use the “Old Stable” version 1.2.x set as my work-horse doing most of my .CAP--> .PCAP conversions via the included version of EDITCAP.  I use the “Stable” version 1.4.3 for my daily capture and focused analysis work. Then I have been excited to find that the “Development” version 1.5.0 is super-fast and doesn’t seem to experience the constant memory-crash problem opening large PCAP trace files that the other versions to. So it is often the first one I use to open then post-capture filter the trace file into smaller more focused PCAP files.  If you haven’t tried it yet, give Wireshark 1.5.0 Development Release a whirl.

GSD Related posts: Network Linkfest & Network Monitoring Madness: Poor Man’s Resource Linkfest

Scanning for MAC and and finding some-FING special

Once you spend any time at all in the network world you quickly realize that addressing physical network security is a foundational element.  If you haven’t found it yet, give this /dev/random post Why Physical (Network) Security is Important? a look.  It is a concise primer and I can vouch that it is unnerving when doing a network trace analysis to suddenly be staring face-to-face with a rouge network device secretly added to your network.

Nmap can be a good place to start. Also, having a list of IP/MAC addresses as well as Host data for them can be a great reference while picking apart and filtering capture traces.

Here are some other free tools I’ve had good success with in performing local network inventory sessions to get that IP/MAC information.

Note: most (but not all) generally do not provide accurate (if any) MAC address discovery across networks.  By that I mean you generally need to be running the tool on a device that is already inside that network..rather than from a remote system outside the network/subnet.  That’s not a problem for me with our embedded network capture systems we remote in to.  But be aware of that issue in case you try one and results are not displayed as intended.

An exciting and new find (to me) was Fing 1.4 from overlook.

What I really, really, really liked about Fing was that is is a CLI-based network discovery tool that is multi-platform (Linux, Mac, Windows, even, yes…Android), supports MAC address gathering, service info gathering, and can run as a service and scan/report changes when occur.

The Fing manual contains a lot of information as to the capabilities as well as examples of report output in csv, text, html, and sml formats.  It is really cool.

Enjoy the view of a demo report. Fing is freeware, and may be downloaded here.

Don’t let the CLI environment worry you, once installed, it creates a program shortcut for launching a terminal window in “interactive” mode which will guide you through the process.  Once you get comfortable, you can run your own targeted ping commands much more efficiently on your own.

And if you can wait, alpha/beta testing has concluded on a GUI-based FING edition. No word on release date. I missed out on the testing (DRAT!) so I haven’t had an opportunity to see this GUI-version but the forum feedback seemed positive.

Check Fing out!

RE: MAC’s & Spoofing

Yes…I felt obligated to add this.

I know that MAC addresses can be spoofed. Easily. So a MAC address alone is definitely no smoking gun.  That said, if the MAC address you are working with is captured “in-context” in a traffic capture or with other tools, and especially if it persistently consistent in presence, you still stand a good chance of being able to track down the physical device associated with it. If it shows up in a traffic capture you should have the traffic, the packets, the IP address associated, and the MAC address being offered.

Couple that with a MAC/IP/Network scanning tool, some l33t work inside your switching hardware, and you should be able to trace it to a physical switch port (well, it it isn’t Wi-Fi I suppose).  Then it’s just a matter of following the wire.  Then finding the answer to why someone would want to spoof an MAC address on your network would be my next step.

Anyway…that said, here are some related resources.

Blogging is dead?  Seriously?  I think not.

Tweet that.

--Claus V.

Posted by Claus at 3 comments
Labels: , , , , , , , , , ,
Subscribe to: Posts (Atom)