Showing posts with label SecurityOnion. Show all posts
Showing posts with label SecurityOnion. Show all posts

Thursday, September 25, 2014

Awesome Bash Vulnerability

I know that this has been posted by a number of people including Doug Burks from SecurityOnion. Just thought I'd share the links. The vulnerability itself...nice...from an attack perspective.




http://blog.securityonion.net/2014/09/bash-vulnerability.html
http://blog.securityonion.net/2014/09/bash-vulnerability-part-2.html

Monday, July 22, 2013

Network Security Monitoring Book

Last week I happened to notice that Richard Bejtlich's new book, The Practice of Network Security Monitoring: Understanding Incident Detection and Response, was available for pre-sale form the No Starch website. After considering it for a short time, I decided that I would go ahead and make the pre-sale purchase, and that I would buy the hard copy so that I would get the free eBook with it. This afternoon I downloaded the eBook (all three formats of it) and the hard copy should be mailed to me next week sometime. But, I am not sure what I think about this yet.

I am actually in the middle of reading two books for book reviews. One book review is for the SIGSOFT quarterly publication and the other is for the SIGACT quarterly. I have really enjoyed doing these book reviews as it gives me (usually) a free copy of a new book and I get to share my opinion with any of the readers of these journals. It is these two current reviews that I am doing that makes me a little uncertain of my choice to go ahead and buy the Bejtlich book: do I have ANY time to actually read this book right now?

I hope so as I am looking forward to this book! Other than a general respect for Mr. Bejtlich's accomplishments and my understanding of his position on things that interest me, the book had one HUGE selling point for me: Doug Burk's SecuirtyOnion. I am a major fan of SecurityOnion and I think it's inclusion in this book is just awesome! It also looks as though the book goes beyond just the installation and configuration of SecurityOnion in that SecurityOnion seems to be the foundation of the book itself.

More about this book in the future...

As of now, the book is still available for pre-sale and has a 30% discount available:

http://nostarch.com/nsm

Thursday, May 2, 2013

PowerShell for your Network Adapter

Recently, I needed to buy a new computer for my development work. While I could have shopped around and bought either an earlier version of Windows, or just a good machine for a Linux distro. However, since the particular laptop I needed to replace was a Windows Vista box, I decided to stick with Windows and set my dev environment up the same way.

This is how I came to own a Windows 8 laptop. I now have a Windows 8 phone as well (thanks to T-Mobile NOT having a single Droid phone that I liked), and while it syncs well with my new laptop, it's a whole different domain of complaints. It is a complaint of my Windows 8 laptop that has caused me to right this long overdue entry to this blog: after my computer sleeps for some [apparently] arbitrary amount of time, my Wi-Fi adapter is disconnected and will not successfully reconnect. I should say that the adapater will not connect without disabling and then re-enabling the adapter. Since I am already playing around a bit with PowerShell, I figured, why not write a script that I can just run when needed. The following covers my efforts (successful efforts, of course!).

Before creating a PowerShell script, it is important to know if you can actually execute said script. As with almost everything else in Windows since the UAC was introduced, just logging in as an administrator doesn't automatically cause every process you start to have the same credentials. PowerShell scripts are no different, so here are a couple key points.

1. Your environment must allow for the running of the PowerShell scripts that you want to save and execute.
2. For writing and testing your scripts, I find it best to open PowerShell (either the command line or the ISE) with "Run as Administrator".

Number 2 above is easy...at least I hope it is for anyone who has read to at least this point of this entry. :-) However, Number 1 may cause some heartache for someone. So, and without a big long description of using PowerShell itself, to determine if you can save and execute PowerShell scripts:

PS C:\Get-ExecutionPolicy
...should return either "RemoteSigned" or "Unrestricted"
I tend to prefer the Unrestricted option while I am working.

To change the execution policy:
PS C:\Set-ExecutionPolicy unrestricted

Now that this is out of the way, time for the hard and complicated stuff.

Before I continue though, I want to report that I happen to like PowerShell. I have been tinkering with it in my tiny bit of free time (when I should probably be doing more with helping test SecurityOnion -- an absolutely AWESOME product!!!). Until today, I have been approaching PS from a standpoint of what it can/can't do for a pentest, flow data, and remote execution (from an SA standpoint). Today, I needed something quick that would let me avoid having to open up multiple windows and go through the disable/enable motions. Below is the fruit of this strenuous labor.

#***********************************************************
#RenewWiFi.ps1
#author: me
#notes: this was way too easy #***********************************************************
#disable Wi-Fi adapter and DO NOT show the confirm window
Disable-NetAdapter -Name wi-fi -Confirm:$false

#Re-enable adaptor Enable-NetAdapter -Name wi-fi #***********************************************************

...and that's it. Really, an actual script file isn't even needed to do this...but it let's me double-click once and get back to something REALLY important, checking on my Detroit Tigers!!!

dw

Monday, September 3, 2012

Ubuntu 12.04 and VMWare Player

In the last few months I have been swamped...COMPLETELY swamped...with not only my own projects and things around the house but also on projects for other people. Unfortunately, part of my time constraint issues have stemmed from one of my test machines being infected, not one but TWO hard drives failing, and a network connection at home (provided by Comcast) that generally sucks everytime it rains.

Some of the testing I have been working on over the last few months has been a little more frustrating than running across a read-only partition that I posted about earlier. While I absolutely love Ubuntu AND SecurityOnion, I have been rather annoyed as of late with trying to set up a distributed setup of Ubuntu 12.04 (32-bit) virtual machines, in order to do some testing of some newer SO features.

It is first important to note that the installation of SecurityOnion is EASY and FAST and is NOT the cause of my heartache with the testing I am attempting to do. In fact, I am ONLY installing the OS right now and will then move from a base install of the OS to installing the latest/greatest SO version.

The problem is Ubuntu 12.04 itself. I am using a downloaded ISO and VMWare's Player and am now into hour 3 of the install process!!! Unfortunately, I do not have enough time to troubleshoot the issue but I suspect it is nothing more than a slow connection...although I am letting VMware's Easy Intaller run which may also be the culprit. The ISO I am using is coming from a network location and it "appears" as if the installer is trying to ALSO retrieve packages from the repo. This is NOT what I want it to do so I have 'skipped' the retrieval of a LOT of files and was very interested to see the end result. However, the VM is now HUNG at the "Easy Installer's" installation of VMware Tools.

Bottom line: things that are "designed" to help us or make things faster/automated STILL run a high risk of slowing down progress. Some irony though in this process is that the actual SO image (Live CD) is designed with ease/speed of install in mind...and it DOES work!

I have a new plan now:
- perform OS install and NOT use the Easy Installer (for a total of three VMs)
- establish host only network for said VMs
- stress test VMs to identify any performance issues NOT related to IDS tools
- install latest SO version from repo (on all three VMs)
    - one to serve as the collection point for data from the other two

In parrallel to the above, I am also going to set up three VMs using the latest SO ISO file (again, one manager and two sensor VMs) and begin testing from there.

Friday, June 15, 2012

Using Perl for NSLOOKUP from logfiles (Part 1)

Wow! It's been so long since I have put anything on here. Over the last six months I have been a TON of things, aside from the normal long hours at work.

A quick recap of the the past six months:
- Graduated from University of Michigan - Dearborn with my Masters of Science in Software Engineering
     - Of course, a MONTH after I walked the stage the school tells me that they screwed up and that I do in fact have to submit a project...grrrr!!!!!!
- Started four different Blog posts that I just haven't perfected enough to post :-(
- Took SANS610 in Orlando and am sitting the GREM exam next week.
- Dad had a heart attack, but he's getting stronger ever day through a life rehab program he is in
- Working on one web-based project with a friend, designing and installing a new small business network for another friend
- Trying to work on two different Android projects, although I haven't found any time in months to even look at what I have so far.
- AND, I want to start trying to help out on the SecurityOnion project (Doug has done such an AWESOME job with this tool and is looking for contributors - link at bottom of post)

In any event, I wanted to talk about a little tool I have been working on. It's a perl script that does two things and produces two output files.

What it does:
- Takes a file as an argument and parses ALL IP address from the file, writing them to "IPAddresses.txt"
- Parses "IPAddresses.txt" and performs an NSLOOKUP (Perl's version) of every address in this file
    - The exception is that I have inserted a quick check for 192.168 address space and ignore those addresses. This could be modified to ignore ALL Private IP space, but I really didn't want to do so yet.
    - The NSLOOKUP results are written to the file "NewIPLookupResults.txt."

A word of caution for anyone that wants to copy any of this script:
Absolutely NO ERROR CHECKING or validation is done. I am saving this for step 3 of this project.

So, time to break down the script:

The first part of the script takes the first argument, hopefully a log file, and parses out ALL IP addresses, pushing each one into an array. After this is done, a hash is setup that takes the unique values from the array. This hash is then sorted back into a final array.
This final array is then written to the "IPAddresses.txt" file, one address per line.

>> code begin <<
open MFILE, ">", "IPAddresses.txt" or die $!;
### This allows for the first passed parameter to be used
### in the loop
# Input: the first paramter passed
my @holder = ();
while(<>) {
  push(@holder, "$1\n") if /\D(\d+\.\d+\.\d+\.\d+)\D/;
}
#using a hash to weed out the dups
%listTemp = map { $_ => 1 } @holder;
@list_out = sort keys %listTemp;
for my $ipa (@list_out) {
 print MFILE $ipa;
}
close(MFILE);

>> end code

That is the "easy" part of this script.  The next section deals with getting the NSLOOKUP results using the perl library NET::NSLOOKUP. If you don't have this module installed, you will need to do so before running the remaining part of this script. Additionally, another GREAT library is probably going to need to be installed, NET::DNS, as NSLOOKUP depends upon this.

I will explain this part of the script below the pasting of it.

>> begin code <<

print "Processing NSLOOKUP of IP addresses\n";
open MFILE4, "<", "IPAddresses.txt" or die $!;
@lines = ;
print "Output file is NewIPLookupResults.txt\n";
open MFILE3, ">", "NewIPLookupResults.txt" or die $!;


for my $line (@lines) {
     #next here if private IP space?
     if($line =~ m/[1][9][2]/ )
     {
          next;
     }
     print "Performing NSLOOKUP for all IP adresses found in IPAddresses.txt\n\n";
     print MFILE3 "///////////////////////////////////////////////////\n";
     print MFILE3 "\t\tNSLOOKUP For: " . $line;
     print "Working on " . $line . "\n";
     print "Starting with A Records\n";
     print MFILE3 "**************** A Records: ****************\n";
     my @results = nslookup(domain => $line, type => "A");
     if (@results == 0)
     {
          print MFILE3 "\tNo A Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for PTR records\n";
     print MFILE3 "**************** PTR Records: ****************\n";
     my @results = nslookup(domain => $line, type => "PTR");
     if (@results == 0)
     {
          print MFILE3 "\tNo PTR Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for CNAME records\n";
     print MFILE3 "**************** CNAME Records: ****************\n";
     my @results = nslookup(domain => $line, type => "CNAME");
     if (@results == 0)
     {
          print MFILE3 "\tNo CNAME Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for MX records\n";
     print MFILE3 "**************** MX Records: ****************\n";
     my @results = nslookup(domain => $line, type => "MX");
     if (@results == 0)
     {
          print MFILE3 "\tNo MX Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for NS records\n";
     print MFILE3 "**************** NS Records: ****************\n";
     my @results = nslookup(domain => $line, type => "NS");
     if (@results == 0)
     {
          print MFILE3 "\tNo NS Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for SOA records\n";
     print MFILE3 "**************** SOA Records: ****************\n";
     my @results = nslookup(domain => $line, type => "SOA");
     if (@results == 0)
     {
          print MFILE3 "\tNo SOA Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print "Now for TXT records\n";
     print MFILE3 "**************** TXT Records: ****************\n";
     my @results = nslookup(domain => $line, type => "TXT");
     if (@results == 0)
     {
          print MFILE3 "\tNo TXT Records Found\n";
     }
     for my $res (@results) {
          print MFILE3  $res . "\n";
     }
     print MFILE3 "\n";
}
close(MFILE3);
close(MFILE4);

>> end code <<

And, minus the she-bang and use statements, that's the full script. This second part here was a lot more fun to work on than the first. I had never used perl's NSLOOKUP before today so I had a little fun with it which is the primary reason why I do a lookup for every possible record type that this library supports.

You might notice a LOT of print statements, both to the file MFILE3 as well as to STDOUT. I will change this as I tweak this tool and add the features I still want. However, right now I wanted as much verbosity as possible. That said, this script will print to STDOUT an output similar to:

>> Example Output <<

Working on 83.149.8.208
Starting with A Records
Now for PTR records
Now for CNAME records
Now for MX records
Now for NS records
Now for SOA records
Now for TXT records

>> end example output <<

The corresponding output that is written to the file is also somewhat verbose, or at least "pretty" if you like different symbols. :-)

>> Example File Output <<

///////////////////////////////////////////////////
  NSLOOKUP For: 83.149.8.208
**************** A Records: ****************
 No A Records Found
**************** PTR Records: ****************
gprs-client-83.149.8.208.misp.ru
**************** CNAME Records: ****************
 No CNAME Records Found
**************** MX Records: ****************
 No MX Records Found
**************** NS Records: ****************
 No NS Records Found
**************** SOA Records: ****************
 No SOA Records Found
**************** TXT Records: ****************
 No TXT Records Found

>> end example output <<


Only a portion of this section needs to be explained as the different checks are identical in nature.


First, I grab the file I just created:
open MFILE4, "<", "IPAddresses.txt" or die $!;

I copy this file to array:
@lines = ;
Created a new file for the NSLOOKUP results:
open MFILE3, ">", "NewIPLookupResults.txt" or die $!;

The script now loops through each address in the array. If the address belongs to the 192.168 space, then that line is ignored and the loop goes to the next line.
for my $line (@lines) {
     #next here if private IP space?
     if($line =~ m/[1][9][2]\.[1][6][8]/ )
     {
         next;
     }

Just some printed information for the file and STDOUT
print "Performing NSLOOKUP for all IP adresses found in IPAddresses.txt\n\n";
print MFILE3 "///////////////////////////////////////////////////\n";
print MFILE3 "\t\tNSLOOKUP For: " . $line;
print "Working on " . $line . "\n";
print "Starting with A Records\n";
print MFILE3 "**************** A Records: ****************\n";

Now, the part I really like, even as simple as it is (Which is WHY I like it because it yet again demonstrates the power that a simple script can have!!!)
Here, I create an array called results that holds the return value of the nslookup function. This function takes two arguments, the first being a 'target' of some kind. This can be domain, host, etc. The second argument is the type of record we want to look for: A, MX, SOA, etc.
my @results = nslookup(domain => $line, type => "A");
#If NO results, then print that and move on
if (@results == 0)
{
     print MFILE3 "\tNo A Records Found\n";
}
for my $res (@results) {
     print MFILE3 $res . "\n";
}

and that's really all this script does. However, it does ALSO provide a good framework for the beginnings of a multi-purpose tool for pentesters and intrusion detection analysts.

Path Forward:
I plan to make some changes over the next month, as time permits. I would like to make this a little more OO-like in that the NSLOOKUP section is one function, and other tools/sections that I want to add are also functions. These I plan to make 'active' during the scripts running via command line parameters.

Being that I work in network security, and have for a long time, I would be remiss if I didn't eventually add some code to handle errors and input, especially in terms of the files being passed as input as well as the IP address (valid, non-routed, etc). However, I can already 'see' the need for some custom switches, such as WHICH DNS records to actually get or how verbose the file or output needs to be for the user.

The final to things that I want to be able to do with this, after adding any other functionality that I think this needs without bloating it too much are:
- different output formats (how great would it be if I made this importable into the MetaSploit database!!!)
- The ability to parse files such as nmaps greppable or XML output and do more than just DNS lookups.


Unrelated and shamless promotion of an AWESOME TOOL from Doug Burks, SecurityOnion:
Google group:
http://code.google.com/p/security-onion/
http://securityonion.blogspot.com/

Tuesday, October 11, 2011

SANS560 at SANS Baltimore 2011

Just a quick one here. Today was day 2 of SANS Balitmore 2011, and I am even more impressed with the presentations we had today in SANS560 than we had in day 1. John Strand is our instructor, something a co-worker and I intentionally attempted to schedule, and it's been well worth it so far. It's not every day I get time to play with nmap, nessus, scapy, hping2, and tcpdump (well...tcpdump is pretty much everyday for me), but we spend some actual FUN time in those today. At least it was fun for me. There did appear to be some that struggled with the exercises due to a lack of non-familiarity. However, it seems as though everyone is enjoying it.

My employer paid for part of this training, but a chunk of change still had to/has to come from me. Had the class been boring or non-informative, I think I would be a little ticked off. However, even with having some experience pen-testing and having gone through other pen test training, I am so far thinking that I have gotten over 1000% ROI and that this has been one of the better classes so far...or it at least rivals the SANS507 I took earlier this year from David Hoelzer.

One of the nice things about most of today just being review...I could rather quickly run through the examples and work on installing both BackTrack 5r1 AND the newest release of Doug Burk's SecurityOnion (which there really is no excuse for anyone NOT to have by now). I am just having too much nerdy fun this week!

Monday, June 22, 2009

SecurityOnion Unleashed...Get Yours Now!

If you want the be an Intrusion Analyst of any caliber, you must have the best tools available. These tools start with Intrusion Detection and the best place to download a comprehensive, and free, Intrusion Detection distro is at the below link. Doug has put a lot of time and energy into this distro and has included in it tools for testing, configuring, and installing a top-of-the-line IDS on your system.

Doug's Blog posting for this distro better explains what it is, what it does, and why you MUST have this distro:
http://securityonion.blogspot.com/2009/06/security-onion-livecd-is-now-available.html

Tuesday, May 19, 2009

Its the little things

After I finally figured out what was breaking the client/server communication in GuardianEdge, I ran accross another issue: "Not enough server storage is available to process this command." This error message popped up everytime I attempted to access a share on the encrypted drive. After some quick research, I determined this to be caused by the IRPStackSize registry setting. After some trial and error with the size and machine, I determined that setting this DWORD to (dec)20 on the domain controller was the correct fix. Apparently, this setting is either changed or removed by some versions of Norton AV.
Although annoying, it was a fairly easy fix. Now it is time to turn my attention to McAfee's Policy Auditor and to getting back into the *nix world.
At home I am currently playing around with the SecurityOnion LiveCD from Doug Burks, Fedora 10 as a client, Fedora 10 as a Server, and CentOS 5. These should keep me busy for awhile.
If you haven't checked it out yet, you should look at Doug's blog: http://securityonion.blogspot.com/
Doug is a packet guru and the SecurityOnion LiveCD is an excellent tool for intrusion analysis/detection.