I like...make that LOVE...cheat sheets and easy-to-use Quick Reference Guides. I like them so much, I make my own when time permits. So, I thought I would share one here. I got tired of looking for the latest location that I stored the latest SNORT manual at on my computer. Although I like to think I am organized, I do know that I am forgetful. So, it is not uncommon for me to forget where I have placed things. My solution was to, like I said already, to create a cheat sheet of SNORT rule options.
This cheat sheet is basically a version 1 document...only slightly past the draft stage. :-) However, it is a fairly good listing and explanation of the different options (as taken straight from the manual), and the base format, of SNORT rules. I welcome any comments, complaints, or suggestions.
The links below are for the both the PDF and PPTX version of the cheat sheet.
Snort Rules Cheat Sheet (PDF Format) Snort Rules Cheat Sheet (PPTX Format)
And....now that I am not trudging through schoolwork until 3 a.m., I can finally get back to working on a desktop app that I started for creating/validating Snort rules. Last time I worked on it, I was about 80% done with the app. However, I had also started thinking about either changing it or forking it to create a tool for the description of a good number (I forget all the protocols I had already addressed) packet standards. I started thinking of it as more of a reference and learning tool for anyone that wants to get started with intrusion detection, or even those who just want a quick desktop app reference guide.
One really, REALLY, cool thing I did already start to add was an event listener for mouse-clicks on the different sections (to include at the bit level) of the packet format displayed. This event listener would create at least one (depending on a few variables) set of statements for tools such as tcpdump (live capture or from file) or tshark (for stripping out from a pcap file those packets an analyst may want to look at more in detail.
I would be greatly interested in any feedback on this idea. I do have a website I am finishing first but I hope to have a release version of this tool, at least as a teaching/reference tool for packets, in the next 2-3 weeks. Not sure if I am going to keep the Snort rule testing part in this as Snort already has this functionality.
Showing posts with label SNORT. Show all posts
Showing posts with label SNORT. Show all posts
Wednesday, September 5, 2012
Monday, January 18, 2010
Putting off the easy things
Last May I had the opportunity to go to the DoE Cybersecurity conference at Las Vegas Lakes. While I was there, I spent some time talking with the sales rep from McAfee about ePolicy Orchestrator. It was also during this time that he convinced me to drop my card in a bowl for a chance to win a new firewall. As it turned out, I won one of two they were giving away, and recieved said wonderful piece of hardware around the end of July'09.
When I recieved this device, I was already happy with the Belkin router I was using at home and had not done enough with my server to really matter. In fact, with the exception of my wife's laptop and daughter's desktop, I have probably re-loaded all of my other computers at least three times since then. So, I really didn't see any justification for spending the time to move from the Belkin router to the SnapGear SG565. What a mistake!
Installing the SG565 was relatively simple and quick. The only issue that I had was that my cable modem required a hard restart. However, that was such a small thing compared to the immediate benefits! Unfortunately, I am fairly certain that McAfee has since discontinued this line since buying out Secure Computing.
Why am I am so happy with the SG565 (especially when I haven't even finished some of the finer set-up issues)? It really boils down to a list of features, and how easy they have been to set-up (or appear to be, in the case of those I need to finish).
These features:
-2 USB ports that I am now using for a shared printer and shared storage (negates some of the headache of a mixed OS home network).
-SNORT built-in
-ClamAV built-in
-What appears to be an excellent interface for firewall rules
-3G support (through a 3G wireless USB key)
-Stronger (but not too strong) wireless signal
In the short time I have been running the SG565, I have seen a definite improvement in network speed, as well as wireless connection states. With my Belkin, the connections were constantly having to be refreshed due to a weaker signal (over 30 feet, almost true Line Of Sight). Further, the adding of printers (to the Windows OS's so far) seemed to be easier than when I had it shared off of one of my desktops.
All in all, I am extremely happy that I FINALLY got around to setting this up. There are a few items on my to do list relating to this though: moving server to a DMZ, setting up SNORT, better F/W rules, etc. I am just glad to have such an awesome device...especially since I didn't have to pay for it at all! :-)
I am think I am going to start with the SNORT config on this. I am going to get another storage device first and setup a new db. I also want to look more into what version of SNORT this is, if it is upgradable, etc. The device appears to be able to accept syslog, other IDS, and other Firewall inputs, so I might end up not using the SNORT on the SG565, and just use the SG565 to aggregate and right down to the db. The firewall does provide a tcpdump feature to capture packets, and on-the-fly configs can be made to capture all traffic from a specific IP, MAC, rule, etc. Looks like I could really turn this into a huge project...time permitting, of course.
1 project down, 987 more for the year!
When I recieved this device, I was already happy with the Belkin router I was using at home and had not done enough with my server to really matter. In fact, with the exception of my wife's laptop and daughter's desktop, I have probably re-loaded all of my other computers at least three times since then. So, I really didn't see any justification for spending the time to move from the Belkin router to the SnapGear SG565. What a mistake!
Installing the SG565 was relatively simple and quick. The only issue that I had was that my cable modem required a hard restart. However, that was such a small thing compared to the immediate benefits! Unfortunately, I am fairly certain that McAfee has since discontinued this line since buying out Secure Computing.
Why am I am so happy with the SG565 (especially when I haven't even finished some of the finer set-up issues)? It really boils down to a list of features, and how easy they have been to set-up (or appear to be, in the case of those I need to finish).
These features:
-2 USB ports that I am now using for a shared printer and shared storage (negates some of the headache of a mixed OS home network).
-SNORT built-in
-ClamAV built-in
-What appears to be an excellent interface for firewall rules
-3G support (through a 3G wireless USB key)
-Stronger (but not too strong) wireless signal
In the short time I have been running the SG565, I have seen a definite improvement in network speed, as well as wireless connection states. With my Belkin, the connections were constantly having to be refreshed due to a weaker signal (over 30 feet, almost true Line Of Sight). Further, the adding of printers (to the Windows OS's so far) seemed to be easier than when I had it shared off of one of my desktops.
All in all, I am extremely happy that I FINALLY got around to setting this up. There are a few items on my to do list relating to this though: moving server to a DMZ, setting up SNORT, better F/W rules, etc. I am just glad to have such an awesome device...especially since I didn't have to pay for it at all! :-)
I am think I am going to start with the SNORT config on this. I am going to get another storage device first and setup a new db. I also want to look more into what version of SNORT this is, if it is upgradable, etc. The device appears to be able to accept syslog, other IDS, and other Firewall inputs, so I might end up not using the SNORT on the SG565, and just use the SG565 to aggregate and right down to the db. The firewall does provide a tcpdump feature to capture packets, and on-the-fly configs can be made to capture all traffic from a specific IP, MAC, rule, etc. Looks like I could really turn this into a huge project...time permitting, of course.
1 project down, 987 more for the year!
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
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, June 2, 2009
Setting up SNORT
As a side project, I have been setting up SNORT on a small network. The nice thing about this setup is also the annoying thing: it will never touch any other network. This is nice in a sense that traffic seen by the sensor will [hopefully] only be originating on the network and/or its interfaces. However, the annoying thing is that 99% of the packets ever viewed by SNORT are going to be normal traffic for the network. This means that the chances of anything of interest being in the logs is slim to none!
The initial setup of SNORT was actually done by someone else. I had been testing an earlier version, 2.4, successfully before we moved this to the production environment. What I didn't know was that version 2.8.4 was the one installed. There were some minor differences in the snort.conf file, but other than that, there was nothing specific to worry about for our environment.
When 2.8.4 was installed however, there were some issues that were unkown at the time (I had to leave town directly after the install). Apparently, when the installation happened and the tar files were decompressed, they were put, by the operator, into the wrong file location. With that in mind, the sequence of events goes like this:
1) SNORT installed initially
2) SNORT configured to run as a service (so the installer thought) :-)
c:\Snort\bin>snort.exe /SERVICE /INSTALL -c "c:\snort\etc\snort.conf -l "c:\snort\log" -A full -i2 ideX
3) SNORT set to start "Automatically"
- Here is where the problem/bug(?) was
At this point the installer verified that SNORT was capturing packets (with no attempt to trigger alerts). However, what the installer failed to realize at this point was that the log file being created was snort.log.XXXXXXXXXX, as opposed to the name we had set in snort.conf.
4) Returned from trip and started verifying that SNORT was running properly, or in this case, NOT running properly.
5) Investigated why SNORT was not logging packets to the right file, why it was logging all packets, and why NO alerts had been triggered over a ten day period. (With a full rule set and some of the required user actions, something should have triggered)
- I, after talking with the SNORT genius Doug Burks, stopped the SNORT service
- I restarted SNORT (in IDS mode) manually from the command line using:
>snort.exe -c "c:\snort\etc\snort.conf" -l "c:\snort\log" -A full -deX
- At this point, I realized I had a problem. Multiple errors with the snort.conf file reported.
- These errors all resolved to issues with preprocessor items.
- After some investigating, I realized that the structure of c:\snort was severly messed up! This is why at run time I was getting multiple errors...the files were not where they were supposed to be.
- In the interest of time, I removed SNORT completely and re-installed, paying attention to the folder structure from the tarballs.
- I then restarted SNORT manually using the same command as above.
- I then used HPING2 to craft some packets and sent them on their merry way.
- I also used the windows NMAP, ZenMap, to fun some noisy scans against some boxes.
- At this point, things were golden, SNORT was properly acting in NIDS mode, and all was right in the world.
6) I reconfigured SNORT to run as a service, using the command above (#1 ).
7) Took a much needed nap.
Lessons Learned:
1) Do not let someone who has never used or configured SNORT install it for you, unless you are present to help! (I should say that I didn't have a choice here)
2) When installing SNORT as a service, if the snort.conf cannot be built at runtime, SNORT will default into packet logger mode.
- ALWAYS test your deployment manually before running as a service!
- Look at the logs in \snort\log
- if they are named "snort.log.XXXXXXXXXX" then you are probably running in logger mode (a good way to know is to assign a name to the .log file in snort.conf that will be obvious to you when it is working correctly)
3) Pay close attention to the path variables in the snort.conf file...they are your friend for configuring SNORT.
The initial setup of SNORT was actually done by someone else. I had been testing an earlier version, 2.4, successfully before we moved this to the production environment. What I didn't know was that version 2.8.4 was the one installed. There were some minor differences in the snort.conf file, but other than that, there was nothing specific to worry about for our environment.
When 2.8.4 was installed however, there were some issues that were unkown at the time (I had to leave town directly after the install). Apparently, when the installation happened and the tar files were decompressed, they were put, by the operator, into the wrong file location. With that in mind, the sequence of events goes like this:
1) SNORT installed initially
2) SNORT configured to run as a service (so the installer thought) :-)
c:\Snort\bin>snort.exe /SERVICE /INSTALL -c "c:\snort\etc\snort.conf -l "c:\snort\log" -A full -i2 ideX
3) SNORT set to start "Automatically"
- Here is where the problem/bug(?) was
At this point the installer verified that SNORT was capturing packets (with no attempt to trigger alerts). However, what the installer failed to realize at this point was that the log file being created was snort.log.XXXXXXXXXX, as opposed to the name we had set in snort.conf.
4) Returned from trip and started verifying that SNORT was running properly, or in this case, NOT running properly.
5) Investigated why SNORT was not logging packets to the right file, why it was logging all packets, and why NO alerts had been triggered over a ten day period. (With a full rule set and some of the required user actions, something should have triggered)
- I, after talking with the SNORT genius Doug Burks, stopped the SNORT service
- I restarted SNORT (in IDS mode) manually from the command line using:
>snort.exe -c "c:\snort\etc\snort.conf" -l "c:\snort\log" -A full -deX
- At this point, I realized I had a problem. Multiple errors with the snort.conf file reported.
- These errors all resolved to issues with preprocessor items.
- After some investigating, I realized that the structure of c:\snort was severly messed up! This is why at run time I was getting multiple errors...the files were not where they were supposed to be.
- In the interest of time, I removed SNORT completely and re-installed, paying attention to the folder structure from the tarballs.
- I then restarted SNORT manually using the same command as above.
- I then used HPING2 to craft some packets and sent them on their merry way.
- I also used the windows NMAP, ZenMap, to fun some noisy scans against some boxes.
- At this point, things were golden, SNORT was properly acting in NIDS mode, and all was right in the world.
6) I reconfigured SNORT to run as a service, using the command above (#1 ).
7) Took a much needed nap.
Lessons Learned:
1) Do not let someone who has never used or configured SNORT install it for you, unless you are present to help! (I should say that I didn't have a choice here)
2) When installing SNORT as a service, if the snort.conf cannot be built at runtime, SNORT will default into packet logger mode.
- ALWAYS test your deployment manually before running as a service!
- Look at the logs in \snort\log
- if they are named "snort.log.XXXXXXXXXX" then you are probably running in logger mode (a good way to know is to assign a name to the .log file in snort.conf that will be obvious to you when it is working correctly)
3) Pay close attention to the path variables in the snort.conf file...they are your friend for configuring SNORT.
Subscribe to:
Posts (Atom)