The last Friday, I sat the GCIA exam, and passed (*crowd cheers wildly*). I offer the below observations for anyone running accross this post and looking for wisdom on this exam:
1) Either you know it or you don't! Have confidence in your answers so that you aren't second guessing yourself. As a perfectionist, and being competitive, I looked up EVERY answer for the first 100 questions. Out of this bunch, there was probably four that I really needed to look up. I missed 5 questions in the first 80, but was then rushing to complete the last 70 in little more than an hour...needless to say, the bulk of my wrong answers came at this point!!!
2) Manage your time wisely. Four hours goes by quickly if you do what I did in #1 above. I ended up not answering three questions due to time expiration!
3) Mark your books well...and study before the test, not at the test site. This goes along with numbers 1 and 2.
4) If you are a perfectionist, limit your options for "open book." Create notes on your weak areas and bring only those notes and corresponding (well-marked) books to the test table. If you are like me, then too many options to verify answers is only going to bog you down. (See #1, first sentence).
5) If the software is discussed in the book, or in the class, USE it, TEST, it, LIVE it, LEARN it! This was a big help to me as the questions regarding specific tools were the easist and the answers where right in the front of the cranial housing.
6) Have a good mentor. The mentor I had, [name withheld to protect his reputation :-)] did an excellent job with presenting the material and then took a lot of the topics a "step-further."
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
Fedora 10 versus CentOS 5.3
My initial interest in starting a Blog was to record my attempts at setting up my home server to host my family website, possibly a mail service for family, and for home networking.
Previously, I had a DELL laptop with Vista Home Premium installed (AMD TK-53 processor, 4 GB RAM, 260Gb HDD). This laptop had given me a headache for a year, and DELL tech support is a joke!
After giving up on DELL tech support, I decided to slap some *nix flavor on the box and see if it would be more stable. I chose Fedora 10. This went extremely smooth and the laptop has been working great, and stable ever since. My only outstanding issue is that I need to get the wireless working (Broadcom 43XX). I was going to use NDIS wrapper to do so, but then found out that it does not allow for promisuous mode (that does not do me any good when I *need* to sniff traffic at Starbucks LOL).
Anyway, with Fedora 10 working great on my laptop, I decided it was time to move my server from (Windows OS name withheld to avoid jeers) to Fedora 10. Boy, was this a pain! The initial install would ONLY run in text mode. This was not a problem. The problem was that it would never boot into the GUI. Now, while I tend to prefer the command line, I still wanted the GUI available, and the fact that "init 5" only caused the box to hang, really caused me concern.
What I found out was that Fedora 10 has an issue with SCSI drives. There is a 'mkinitrd' work-around for this issue, but at this point, I decided to try something else. Enter CentOS 5.3!
The first thing I noticed about CentOS 5.3 was the installation was a breeze, although I didn't do too much customizing. The second I noticed was that the issue with SCSI drives was not present...i.e., I could boot into the GUI. The only reason why I wanted this was, and it may be bad form (but I really don't care) was so that I could perform any updates and maintenance on our webpage through an IDE directly on the server. Although I have been using a different box for development, it will be quicker in my busy life to be able to use the server directly for updates and maintenance.
The only issue I had with CentOS 5.3, so far, was getting my HP printer drivers installed. What I ended up doing was getting the HPLIP (HP Linux Imaging and Printer, see link below) driver pack. Although this has the option of using an auto-installer, I opted for manual. There were some dependencies that I had to yum search for, but the install was relatively quick and easy.
After the installation, I checked to make sure that the right services were running and then I *tried* to print....AAGGHH! Something wasn't working. I restarted the box and the printer worked perfectly.
It was at this point that I realized the importance of prior planning. Why would I want my web server to host my home network printer? I didn't! So, all that work for nothing, I moved the printer to another box. As I can not see a reason to print from the Server, I will not be configuring the box to use a network printer.
As soon as I decide how I want to design our families web page, I will be moving it to the server and will be using some service, probably DynDNS, to resolve. I plan on getting a lot deeper into SAMBA in the next week or so, but I still have some other things to test elsewhere in my world, such as an Ubuntu distro on my AMD box (mentioned above).
HPLIP CentOS install help:
http://hplipopensource.com/hplip-web/install/manual/distros/centos.html
Previously, I had a DELL laptop with Vista Home Premium installed (AMD TK-53 processor, 4 GB RAM, 260Gb HDD). This laptop had given me a headache for a year, and DELL tech support is a joke!
After giving up on DELL tech support, I decided to slap some *nix flavor on the box and see if it would be more stable. I chose Fedora 10. This went extremely smooth and the laptop has been working great, and stable ever since. My only outstanding issue is that I need to get the wireless working (Broadcom 43XX). I was going to use NDIS wrapper to do so, but then found out that it does not allow for promisuous mode (that does not do me any good when I *need* to sniff traffic at Starbucks LOL).
Anyway, with Fedora 10 working great on my laptop, I decided it was time to move my server from (Windows OS name withheld to avoid jeers) to Fedora 10. Boy, was this a pain! The initial install would ONLY run in text mode. This was not a problem. The problem was that it would never boot into the GUI. Now, while I tend to prefer the command line, I still wanted the GUI available, and the fact that "init 5" only caused the box to hang, really caused me concern.
What I found out was that Fedora 10 has an issue with SCSI drives. There is a 'mkinitrd' work-around for this issue, but at this point, I decided to try something else. Enter CentOS 5.3!
The first thing I noticed about CentOS 5.3 was the installation was a breeze, although I didn't do too much customizing. The second I noticed was that the issue with SCSI drives was not present...i.e., I could boot into the GUI. The only reason why I wanted this was, and it may be bad form (but I really don't care) was so that I could perform any updates and maintenance on our webpage through an IDE directly on the server. Although I have been using a different box for development, it will be quicker in my busy life to be able to use the server directly for updates and maintenance.
The only issue I had with CentOS 5.3, so far, was getting my HP printer drivers installed. What I ended up doing was getting the HPLIP (HP Linux Imaging and Printer, see link below) driver pack. Although this has the option of using an auto-installer, I opted for manual. There were some dependencies that I had to yum search for, but the install was relatively quick and easy.
After the installation, I checked to make sure that the right services were running and then I *tried* to print....AAGGHH! Something wasn't working. I restarted the box and the printer worked perfectly.
It was at this point that I realized the importance of prior planning. Why would I want my web server to host my home network printer? I didn't! So, all that work for nothing, I moved the printer to another box. As I can not see a reason to print from the Server, I will not be configuring the box to use a network printer.
As soon as I decide how I want to design our families web page, I will be moving it to the server and will be using some service, probably DynDNS, to resolve. I plan on getting a lot deeper into SAMBA in the next week or so, but I still have some other things to test elsewhere in my world, such as an Ubuntu distro on my AMD box (mentioned above).
HPLIP CentOS install help:
http://hplipopensource.com/hplip-web/install/manual/distros/centos.html
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)