tag:blogger.com,1999:blog-73317527868319223282024-02-19T15:53:26.647-08:00Autosnortda_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.comBlogger40125tag:blogger.com,1999:blog-7331752786831922328.post-36898754307435018272014-01-05T01:45:00.002-08:002014-01-05T01:45:44.554-08:00Moving Autosnort BlogGreetings Autosnort Users,<br />
<br />
It's been some time since I've posted here. I haven't been idle this whole time however, I've been focusing on other things.<br />
<br />
Last fall I came across a guide on Ars Technica on how to build your own secure webserver with NGINX. Curious, I decided to read it. I was never one for being a "web admin" or "webmaster", since I've never been in those roles in my life, I decided I would live up to my reputation and learn how set up a webserver on NGINX along with several web applications.<br />
<br />
Sure I have some experience with Apache and setting up/configuring web interfaces for snort, but NGINX was an entirely different beast to me. So I decided to dive in. Only I decided to modify the Ars Technica guide ever so slightly. They decided to use Ubuntu server for their guide, and that's fine, but I'm an individual that likes a good amount of challenge to my projects. I decided that following the exact same cookie cutter recipe wasn't what I wanted to do, so I settled on CentOS. In spite of RHEL-based operating systems being the preference in the corporate world of Linux, no one really has any guides for doing a damn thing in RHEL-based operating systems. I decided that wasn't fair or cool and dove in.<br />
<br />
For the most part, it was pretty smooth sailing, but there were a couple of rough spots I had to be aware of and resolve myself, SELinux and how it wants the system to interact with UNIX domain sockets was one such example.<br />
<br />
So, why was I spending time on all this? I'm moving away from blogspot and want to host things internally. So, I'm proud to introduce <a href="https://haxthruhere.dyndns-server.com/">BlindSeeker</a>, My new self-hosted website. The URL will read:<br />
<br />
haxthruhere.dyndns-server.com<br />
<br />
I'm using dynamicdns for DNS, since I have a dynamic IP, and while I could have chosen a better dyndns hostname, I think it fits, so it stays for now.<br />
<br />
My site hosts 4 services:<br />
<br />
A wordpress <a href="https://haxthruhere.dyndns-server.com/blahg">blog</a> that I will be using to post product updates, etc. <u><span style="color: red;">This will be acting as the new Autosnort blog</span></u>. Update your bookmarks, and watch for news here.<br />
<br />
A <a href="https://haxthruhere.dyndns-server.com/forum">forum</a> that can be used for discussing whatever you'd like, including questions related to Autosnort, etc.<br />
<br />
A <a href="https://haxthruhere.dyndns-server.com/wiki">wiki</a> that I'll be updating this heavily as I go along. I plan on releasing all core <a href="https://haxthruhere.dyndns-server.com/wiki/Autosnort">Autosnort</a> guidance and documentation on this wiki, along with screenshots, etc. I'll also be hosting my guide on how I built <a href="https://haxthruhere.dyndns-server.com/wiki/Blind_Seeker">BlindSeeker</a> on CentOS here eventually and perhaps even more things down the line.<br />
<br />
An <a href="https://haxthruhere.dyndns-server.com/etherpad">etherpad</a> instance -- Etherpad is essentially a multi-user instance of notepad with some chat capabilities built in, etc. It's very nice for collaboration/troubleshooting. Think of it as a no-hassle version of google docs. That can be used for collab.<br />
<br />
Just to re-iterate the above, BlindSeeker, the server in my basement will be acting as the replacement for the Autosnort blog. I feel that I need to manage my own web applications and be responsible for securing my own stuff to grow as a security professional.<br />
<br />
Things to be aware of:<br />
1) The certificate for the site IS self-signed. Sorry, I don't believe in giving free money to CAs, not when they can be infiltrated and have wildcard certificates generated before anyone notices and investigates.<br />
<br />
The certificate is issued by Triptych Security Inc for BlindSeeker.com (which doesn't match my dyndns hostname... I know, I know...) just so you know what to look for, If you are the (rightly so) paraniod type who needs to verify the details of the certificate, before you blindly accept self-signed certs. I may fix the details of the cert eventually, but it will always be self-signed.<br />
<br />
2) Registration for the forums and to be a contributor on the wiki are both a manual process right now. You'll have to register for the forum or wiki (whichever you are interested in) and send me an e-mail with the username you registered in order for me to give you rights to do anything. Sorry, but that's just the way it is. It's more secure, prevents spam, and aside from initial access overhead is more tenable security-wise.<br />
<br />
Also e-mail is required to register on the forums, but since I don't have a mail-relay set up, you won't get e-mail from my forums for anything. Same goes for registering to the wiki -- don't bother with your e-mail address there. I may fix this at some point, but not right now :\ <br />
<br />
3) I've established a Regular maintenance schedule. Saturday at 3:30am the system has updates applied and is rebooted. Sunday at 3am, all current etherpads are wiped from the server to maintain your privacy, and limit my liability for things copied to them. If you have anything important you want to preserve on your Etherpad instance(s) Save it before the Sunday weekly wipe.<br />
<br />
Join me and become a BlindSeeker today.<br />
<br />
Cheers,<br />
<br />
DA_667<br />
da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-71911987331680575222013-10-21T18:43:00.004-07:002013-10-21T18:43:47.098-07:00By the gods, he lives! (Part 2: Secret weapons that never were)So,<br />
<br />
Last post I had talked about MDC3, and my role along with the rest of the unallocated team in making it to the finals. Sadly, we didn't win, but even worse, we never got to utilize the secret weapons we were planning on bringing with us. Once again, I had my involvement on the secret weapons front.<br />
<br />
Most of our weapons weren't exactly that secret -- we had plans to bring massive password cracking wordlists with us from freely available sources, and essentially bring a package of updated tools with us.<br />
<br />
My job was to re-spin Kali with the most up-to-date tools available for use, as well as provide us with some (not-so) secret weapons that are tailored towards CTF usage. Unfortunately, they outlawed use of your own special software or tools for the competition (in my opinion, that didn't keep others from downloading their tools and using them, but we played by the rules, regretfully)<br />
<br />
So I worked at this shell script only to find out we couldn't use it for our CTF event. Well, our loss is now your gain. I present to you, updater.sh<br />
<br />
What does updater.sh do?<br />
<br />
Updater is a script specifically for Kali Linux that performs the following tasks:<br />
<br />
.5: checks to see if you're root. If you're running on Kali, you should be, but still.<br />
<br />
1. Generates new ssh host keys for your Kali installation, starts the ssh daemon and makes it start on boot -- this was something that was somewhat of an annoyance to me. Kali has every other service and capability known to man on it, but doesn't have sshd started by default. Well, I fixed that.<br />
<br />
2. Adds the Kali Linux bleeding edge repository -- There isn't that much to say that hasn't already been said <a href="http://www.kali.org/kali-monday/bleeding-edge-kali-repositories/">here</a>. Basically there are certain tools that update frequently that were included by default with Kali. The bleeding edge repo was Kali's answer to those tools. Right now, the bleeding repo only has a small subset of tools, but dammit I want the latest and greatest, so I added the bleeding repo to Kali's /etc/apt/sources.lst<br />
<br />
3. The almighty apt-get update and apt-get -y upgrade (dist-upgrade) -- What would an update script be without apt-get update and upgrade? I know, this is braindead simple stuff, but I wanted to automate it regardless. Just to give you fair warning: make sure you have ample time when running this script. This is the longest portion of the script. Why? Default Kali install pulls 400+ packages of varying size (some over 100+mb), then has to install all that.<br />
<br />
You might wonder, why the hell would I choose to use dist-upgrade as opposed to just upgrade? I noticed when I ran the updates initially there was a number of packages that were "held back". Doing my homework, held back packages can be force updated via dist-upgrade when updating packages. I don't see a reason to hold back security tool packages, so I opted for the simplest way to fix it.<br />
<br />
4. Msfupdate -- So you've updated your OS installations core tools and bleeding edge tools, what next? Kali's heart is metasploit. So msfupdate seemed logical to me. Takes a moment or two, but not nearly as drawn out as the apt-get package pull and the benefits are definitely noticable if you have any tasks where you'll be using or relying on the framework.<br />
<br />
5. If you have the flash installer package for linux (.tar.gz) and/or the Nessus .deb package (with a home or professional feed provided to the script), they are automatically installed -- drop the adobe flash play for linux package in the root ("/") directory and/or the nessus installer package and provide the shell script with a home or professional feed key, and the script will auto install both.<br />
<br />
Some of the more security conscious saw flash player and probably did one of <a href="http://i1.kym-cdn.com/photos/images/original/000/100/670/Nope20110725-22047-kmp4zf.png">these</a> , but flash is required for a wide variety of web consoles (nessus included), so I included the option of installing it if the script detects you downloaded it and have it in the right place. If you don't want it installed, just don't download flash. That simple.<br />
<br />
6. Couple of minor customizations -- As a part of the updater, some packages that I found to be missing on a deafault Kali install I configured apt-get to install:<br />
<br />
armitage -- The popular graphical front-end to the metasploit framework by Raphael Mudge of Strategic Cyber. Also installs the teamserver (armitage collaboration) program. Was very surprised this was not installed by default.<br />
mimikatz -- a popular program for dumping plaintext passwords -- basically if a user is logged in, lsass stores a plaintext copy of that user's password within lsass' memory space in memory. mimikatz can dump it and reveal the passwords stored.<br />
terminator - a terminal emulator program that supports tabbed terminal sessions and also has a unique feature that allows you to split your terminal screen vertically and horizontally as many times as you want. For those with an OSX background, think of this as the Linux version of iterm/iterm2<br />
unicornscan - a leightweight asynchronous network scanner. Doesn't have all the fancy bells and whistles of nmap, but sometimes all you want is a list of open ports. unicornscan does this fast and it does it well.<br />
zenmap - the graphical front-end to the ever popular nmap scanner. Was also very surprised that this was not installed by default as well.<br />
<br />
7. A collection of scripts and tools from other CTF veterans and pentesters alike who were willing to share their armaments, including:<br />
<br />
1. The github collection of Cortana .cna scripts for automated red-teaming and post-exploitation. Cortana is touted as a "Red team force multiplier". Translated from cyber-ese, Cortana is a bot platform for armitage. Basically you provide scripts to Cortana and they can do things ranging from updating functionality in Armitage and allowing you to do new things to, automated scanning, to automatically throwing exploits at new targets seen on the network that have certain points open and/or listening services to post-exploitation modules to maintain persistence to hard-won hosts. If you're familiar with the sleep language, (The strange perl dialect that much of Armitage is written in along with java) then you can write your own, or simply modify the pre-existing scripts to suite your needs.<br />
<br />
2. Unsploitable tools: Unsploitable is a collection of tools/scripts that when you feed them the results of a nessus scan will tell you what exact patch will fix the vulnerabilities listed. Good for situations where you have to perform triage quickly.<br />
<br />
3. Defense Tools for the Blind (DTFTB): a set of scripts for unix systems that sort of allow you to ghetto rig security for unix systems and kinda triage the system/provide emergency defensive countermeasures for when you don't have the time or resources to fully patch out your vulnerabilities. For example, one script is a while true that scans ps output for /bin/sh or nc or netcat and kills the associated processes, killing post-exploit shells and simple backdoors.<br />
<br />
4.New custom build of smbexec by Brav0hax. Basically this is a copy of the smbexec functionality found in metasploit re-written to get around some security products catching metasploit smbexec and flagging it as a non-legitimate service installation.<br />
<br />
That's it. Lot of simple things, that make Kali that much more awesome and makes it that much easier for you to gear up for the CTF or pentest.<br />
<br />
As with the autosnort scripts, the script tells you what it's doing and gives you success or failure indicators. If there's a failure the script bails.<br />
<br />
The script logs the entirety of output for each of the installation steps to a dedicated log file in /var/log named kali_updater.log<br />
<br />
If you're looking for a challenge, troll through it, figure out what failed, fix it, contact me, tell me my script is broken and how you fixed it. If you're lazy or not looking for a challenge, tell me my script is broken and ship me a copy of the updater log.<br />
<br />
As usual, along side any post where I announce a new tool or script, it's available via <a href="https://github.com/da667/auto-kali">github</a><br />
<br />
My final installation in the 'what the hell have you been doing series: BSIDES DC!da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-42883816081252376742013-10-20T17:46:00.002-07:002013-10-20T17:46:52.870-07:00By the gods, he lives! (Part 1, MDC3)Hello again,<br />
<br />
It's been quite a long time since I've posted anything here or posted any updates on github for autosnort OR H1N1 for that matter. well, let me tell you what I've been up to lately, this'll probably be over multiple posts, so I hope you're ready to be shotgunned with updates >:) so let's start with MDC3.<br />
<br />
For those who don't know about MDC3, what it is and why I'm interested in it, it's a yearly event sponsored by SAIC among other organizations. It's mainly a "suitcon", where managers in industry meet up, and a bunch of security vendors come on down to the Baltimore convention center with whitepapers and statistics and other things as to why you want to buy their wares.<br />
<br />
In addition to that, MDC3 hosts a yearly cyber challenge event that I use as a sort of whet stone for keeping myself sharp. There are 5 rounds in total. The first 4 rounds are done online/offline with friends at a place of your choosing, with the final round at the "suitcon" live.<br />
<br />
Out of the four online/offline rounds, the first two are practice rounds while the next two rounds are qualifier rounds for the finals. The practice and qualifier rounds are very similar -- either you're given VM images to examine, or you are given forensic and crypto challenges to perform. -- things ranging from "Here's a VM with an operating system of some sort running on it. It's owned in various ways and has several security holes. Close the holes." to "Here's a PCAP, answer these questions", where the questions range from "What was the admin on this box doing while the system was being compromised?" to "The attacker used FTP to exfil data off the system. Give us the name and an md5sum of the files downloaded."<br />
<br />
We skipped the practice rounds this year, though in retrospect, I kinda wish we had gotten the files so I could practice more. So for the first qualifier round, we ended getting a windows server VM that was owned in various ways. The server was running IIS and had simple TCP services enabled. In addition to that, no patches, no security countermeasures, no firewalls, several netcat backdoors, user applications (firefox and chrome installed -- plus firefox was backdoored with another netcat listener), etc.<br />
<br />
The round was scored out of 20 points or 20 vulnerabilities to remediate. Our team ended up getting 19 out of 20 and passing the round. Essentially all we did was more or less manually revert the host back to a clean,default install with DISA STIG recommendations applied, full patches, all services disabled, user account passwords changed and other common sense things you would do to a system that was compromised. We had no requirements to keep IIS running or core services on the VM that were required to be running, so we just uninstalled everything.<br />
<br />
Some of you may be running, how would SAIC know what was going on with the VM and whether or not you remediated something? They had a really crappy java client called cybernexs installed on the VM with a special account running a service that would start on boot, that you would register to a scoring server. This service would phone home and say what you had fixed.<br />
<br />
Theoretically, you could reverse engineer the client and make it pretend to call back stating everything was fixed, but we never got around to doing that. I know I'm not skilled enough to do that, but there were some on our team that probably could have done it.<br />
<br />
Back to the competition. So overall I'll call round 1 a success, however it's disappointing: In a real-live production environment, your server is responsible for providing a service (at minimum 1 service, sometimes many), the fact that we were given free reign to uninstall all services and applications installed on the server flies in the face of reality.<br />
<br />
So the second round this year was network forensics and crypto. We were given a packet capture to analyze and the following questions:<br />
<br />
<div>
<div class="im">
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">1. What files were transferred from the victim?</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span></div>
</div>
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">2. What directory were files initially copied to?</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span></div>
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">3. What is MD5 hash of files transferred to the attacker? (Use lowercase letters)</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">4. What port is the backdoor listening on?</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span></div>
<div>
<div class="im">
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span><br />
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">5. What was the admin doing during attack?</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span></div>
</div>
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">6. What is the name of the backdoor user?</span></h2>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;"></span></div>
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">7. What is the password of the backdoor user?</span></h2>
<div class="yj6qo ajU">
<div class="ajR" data-tooltip="Hide expanded content" id=":1oe" role="button" tabindex="0">
<img class="ajT" src="https://mail.google.com/mail/u/0/images/cleardot.gif" /></div>
</div>
<div class="adL">
</div>
</div>
<div class="im adL">
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">8. What is root's password?</span></h2>
</div>
</div>
<div class="im adL">
<div>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;"></span></h2>
<h2 dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 10pt;">
<span style="background-color: transparent; font-family: 'Trebuchet MS'; font-size: 17px; font-style: normal; font-variant: normal; font-weight: bold; text-decoration: none; vertical-align: baseline;">9. What software on the victim allowed the attack?</span></h2>
</div>
</div>
</div>
<span style="background-color: transparent; font-family: Arial; font-size: 15px; font-style: normal; font-variant: normal; font-weight: normal; text-decoration: none; vertical-align: baseline;">10.</span> Repair the zip file and answer the challenges within.<br />
<br />
I managed to do most of these questions easily. The only tools I used this were Wireshark, Network Miner, md5sum and DiskInternals zip repair utility. Managed to answer all the questions except question 8.... a portion of the pcap showed the attack managed to get a copy of /etc/shadow. Even after throwing JohnTheRipper at it for 24 hours straight, I never cracked the password or got any hint in the pcap as to what root's password was. Bummer.<br />
<br />
Question 10 was a multi-parter. Part of the forensic challenge indicates there were files transferred during the attack. One of the files was a zip file. It was in plaintext and was easy to single out with wireshark and tcp stream separation. After exporting the bytes of the TCP stream, I was able to reconstruct it as a zip file. The problem was that the zip file was broken. Another one of our team members who knew more about forensics than me was able to manually fix it. There was some sort of discrepency between the zip file's size and the zip file record's reported size that needed to be repaired. I ended up using diskinternal's zip file repair utility and that fixed it for me. That was as far as I got there, I relied on other team members to resolve the crypto challenges since I'm absolutely terrible at crypto and cipher schemes.<br />
<br />
We did well enough as a team to make it to the finals. The format of the final round is completely different from the previous rounds. It's essentially a king of the hill style CTF challenge. There are several systems (with more being added over the duration of the event) that are vulnerable and very exploitable. The goal is to get on the system, and plant your flag (a flag.txt file with a hash that represents your team in a specific directory on the host) and keep it there. You can lose shell access to a system, but as long as your flag is there, the system is still yours.<br />
<br />
Well, I was in charge of exploiting windows systems, and here was my run-down: Most of the Windows 2000, w2k3 and XP systems were vulnerable to some fort of MS08-067 (If you don't know what this is, it's essentially a 4+ year old SMB exploit for windows versions ranging from windows NT to Server 2003 as well as several service pack revisions, it's pretty old, but is still used as a point of reference for many security conferences and classes because it's very reliable and a shining example of Remote Code Execution exploitation) MS03-026 (this exploit is mainly focused around windows 2000, early versions of XP and early versions of server 2003. It's an RPC DCOM exploit that is also another popular remote code execution exploit used as an example in lots of training courses.), etc.<br />
<br />
The most unique windows box I had to throw against in the network, another team member found was vulnerable to file upload via webdav, and handed off to me to finish owning. There's a metasploit module that exploits the file upload and uploads an ASP script which then gives you a meterpreter shell as an unpriveleged user. At that point, you could plant the flag as an unpriv'd user, or you could be like me, rummage through armitage and metasploit's post-exploit modules and find a privilege escalation that would give you SYSTEM access...As an attacker, why would I want system access? Well, there are a number of reasons, we'll get into that in a moment. after several unsuccessful tries, I managed to get system through ms11-080. I wish I was smart enough understand how it worked, but the gist of it is that it's a driver that executes in ring 0 (kernel space, SYSTEM space) and through some voodoo magic or another, you load shellcode into memory and tell this driver to refer to your shellcode, and BAM you have a system shell (smarter hackers will skewer me... but I did what I could with what I know.)<br />
<br />
So, what was the point of gaining system access the windows boxes? system access enables you to utilize a post-exploitation module known as hashdump. hashdump allows you to dump the contents of the SAM (Security Accounts Manager) database. This contains hashes for all the users on the system, from the lowliest of users to all system administrators.<br />
<br />
What good are hashes without having the cracked, you may ask. Well, in windows, you don't necessary need to crack the hashes in order to be able to utilize them. A common exploit for windows is a technique called "Pass the Hash". PTH exploits a weakness in windows filesharing that allows you to authenticate to a remote windows system by simply giving the remote system a copy of that user's hash as opposed to the actual password and having the remote system do hash checking. Pass the hash can be used to do anything that user can do -- map drives, execute commands, upload and execute metasploit payloads, etc.<br />
<br />
So, when you exploit a windows system, the first thing you want to do is esclate privs and get system access as soon as you can. After you have system access, you want to dump hashes and get hashes for admin users, since it's extremely easy to gain system access as an admin user. Once you have hashes for admin users, this allows you to use psexec/pass the hash to maintain access to an exploited host, or easily regain access to the host if you've somehow lost your initial access.<br />
<br />
So, in spite of getting hashes for multiple systems and repeatedly managing to get back on as SYSTEM, we didn't get very far in terms of placement, because others would simply beat us to our targets and had better methods of planting their flag and keeping it there. I didn't know enough about acls and cacls to figure out how to fix file permissions to undo what they did to their flag file to leave it on the host, then drop our file and lock it to where other teams couldn't modify it. It was really frustrating. Also, in addition to that, I would repeatedly lose my meterpreter shells in spite of doing things the right way (e.g. migrate processes and load meterpreter into a system process that an adversary would not want to kill, etc.)<br />
<br />
While I was thrashing windows boxes, others were doing everything they could in linux and unix hosts. And once again, we would get access (managed to plant our flag briefly on one), and lose it, then the hole would be closed, locking us out of that host.<br />
<br />
So, in spite of all things, and not having won the competition, I was satisfied because of the fact that I did manage to pop some windows boxes and be a massive annoyance to other teams. I was annoyed because either the network was incredibly unstable, or the hosts we were attacking were incredibly unstable. I'm guessing a combination of the two, but the systems we attacked and got on to would get REALLY bogged down after a little while. I was also disappointed. SAIC didn't give us much swag this year for making it to the finals. Last year, we got challenge coins for making it to the finals, this year, we got a craptastic backpack. registration for the event was something like 300 dollars per team in the professional level. What gives? Sigh. Oh well.<br />
<br />
So, that's a run-down of my MDC3 adventures.<br />
<br />
Part 2: the secret weapons that never were. Look forward to a script release...da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-23145416168215603262013-08-26T15:54:00.005-07:002013-08-26T15:58:09.498-07:00Project H1N1: An introduction.Hello Autosnort viewers, today I'm going for a change of pace and going to introduce a bold, new project that could have a monstrous impact on the IDS and Network Intelligence realm. I'd like to introduce groundbreaking for the new Unallocated Space collaboration project, H1N1:<br />
---------- <br />
<b>H1N1 – Abstract:</b><br />
<br />
H1N1 is a project that is meant to integrate the PRADS Passive Operating System Detection with Snort, the popular Intrusion Detection System package. The end goal is a system where Passive OS fingerprinting and IDS both work off one another to present a bigger picture:<br />
<br />
- Snort benefits would benefit from Passive OS fingerprinting by having the Passive OS fingerprinting software inform it as to what operating systems are in its HOME_NET, and use that information to build Preprocessor policies, specifically frag3 and stream5 reassembly policies, that control how snort handles reassembling traffic for those hosts. Eventually this gathered information could be used to make snort rule recommendations based on hosts, client service banners observed in the HOME_NET as well.<br />
<br />
- PRADS would (eventually…) benefit from snort, by existing as a preprocessor in the “stack”, benefitting from snort’s native ability to reassemble fragmented packets and reassemble TCP streams for both Operating System identification and Client/Server banner grabbing from the wire.<br />
<br />
- Users would be able to review information for assets in their HOME_NET detected off the wire, alone with their intrusion events, offering greater network intelligence and a bigger picture.<br />
<br />
The problem is, I’m a complete derp when it comes to anything programming or development. I know shell scripting, I’ve done some introductory python, but beyond that, I’m pretty much helpless. The key to completing this project lies in the Unallocated space motto: Teach, Learn, Build -- We'll teach one another something, We will learn in order to fill in the gaps of knowledge we may lack in making this project a reality, and the end goal will be to Build something awesome.<br />
<br />
So that's the general abstract and overall goal of this project. Yesterday afternoon, I did a presentation about the project at my local hackerspace, <a href="http://www.unallocatedspace.org/uas/">Unallocated Space </a>The goal was to find others in my area who would want to collaborate and be interested in making the project a reality. Below is an overview of the discussion and the powerpoint slides I brought with me:<br />
---------- <br />
<b>H1N1 – Day 1: Introductions, Teach, Learn, Build</b><br />
<br />
The first day was primarily an introduction to the technology behind the project. Unallocated motto was integrated into today’s talk, in introducing H1N1:<br />
<br />
- Teach: <br />
o I introduced the audience the open-source IDS/IPS software snort, if they weren’t already familiar, as well as how it worked. After that I explained the difference between Active and Passive OS fingerprinting, then delved deeper into the various techniques used to passively fingerprint operating systems that have been researched and well-established by minds much greater than my own; such as TCP SYN flag options, Client/Server banners, ICMP fingerprints, etc. I discussed the weaknesses of Passive OS fingerprinting – network devices modifying traffic between the source and destination, duplicate fragments/segments, etc.<br />
<br />
o I then set the stage for H1N1 – why hasn’t there been a project that integrates these two technologies together and have them work together? Most of the more well known solutions are commercial, while some of the Open-Source solutions aren’t quite there yet, in terms of usability .<br />
<br />
- Learn:<br />
o I want to make this project a reality. But I next to 0 programming knowledge. I know how to “hello world” in three separate languages, but unless I have an active challenge, or a reason to extend my knowledge beyond that, I tend to lose interest and my knowledge drops off nearly immediately. H1N1 is going to be a challenge, A challenge that I don’t know where to even begin to tackle. <br />
<br />
o This is where Learning comes into play. I want to learn how to develop in different programming languages. I’m more than willing to learn from anyone willing to teach. If you know how to do it, show me. If you don’t have the time, tell me to “Go learn about X concept in Y language then come back to me.” Once I understand it, I’ll teach others. We all benefit and gain knowledge in this way. Knowledge is power, and we all deserve to wield it.<br />
<br />
- Build: The project is ambitious, but I want to start with baby steps. Let’s start with the basics.<br />
o What passive OS identification software do we want to use? <br />
o Where are we going to host the code, and eventually the alpha builds?<br />
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?<br />
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?<br />
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.<br />
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?<br />
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET<br />
---------- <br />
Finally, We ended the conversation with a review of the slides, Q + A and what direction to take the project -- a review of the Build portion of my slides where I wanted to establish project milestones for H1N1:<br />
---------- <br />
<b>H1N1 Q + A:</b><br />
<br />
o What passive OS identification software do we want to use? <br />
<br />
Answer: We all primarily agreed that PRADS has the most features out of the options presented, and it made the most sense to build off it.<br />
<br />
o Where are we going to host the code, and eventually the alpha builds?<br />
<br />
Answer: For the time being, we all have infrastructure in our own homes that we can build snort and prads on, Forgotten offered to create an unallocated space github account for hosting the project code there. Eventually, when we have a workable alpha release, or beta release, or SOMETHING, we can talk to hunter and UAS Keyholders to either get a physical box or virtual machine to demo things. <br />
<br />
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?<br />
<br />
Answer: This should be very easy for us to do. compile/build a snort sensor (snort, barnyard2, a web interface of choice), then compile PRADS. Set them both to run on startup (either via rc init script, or via rc.local), throw traffic at it. If it doesn't explode in a fit of rage, I'm going to call it a victory.<br />
<br />
o The current Prads2db script is in perl… Hell, most of the prads utils are in perl. Should we fix that? Can we make them better?<br />
<br />
Answer: There's a general fear and loathing of perl that's understandable, along with a love of python. Additionally there's been talk at our first session that it would be trivial to write a parser to drop this information into a database. Any volunteers for reviewing the prads2db.pl script as well as the prads2snort.pl script, and prads.sql data and determining whether or not porting it all to python would be feasible?<br />
<br />
o We can output the prads data to a database, to host attribute XML, but currently, there’s no web interface to display this data on.<br />
<br />
Answer: Ruby on rails has been suggested. I don't know enough about web application technology to make this happen, but I'm not opposed to trying this. Another technology that I've been curious about is node.js.. A lot of new up and coming infosec projects have used node.js, and it's supposed to be incredibly fast. I wanna learn more.<br />
<br />
o (This is probably something that will happen much later) Is there host timeout functionality integrated in with PRADS? If not, how can we make it?<br />
<br />
Answer: It was suggested that we turn this into a rolling time window sort of thing that's user configurable. Instead of taking the first fingerprint we see and associating it to an IP address, we can keep fingerprints associated to an IP address seen over a period of time, and based on results over X time period, Have Y% confidentiality that this IP address is this type of operating system. This is likely something that will have to come much further down the line, as it seems to be something that will require considerable effort to code.<br />
<br />
o Automating the prads2snort script (rewritten in something that isn’t perl), and having it run on a regular interval, given to snort, and passing snort SIGHUP to read the new hosts identified in HOME_NET<br />
<br />
Answer: This should be fairly straightforward to do: Basically read the database, and generate a host_attributes.xml the same way the current perl scripts read the prads log and generate output.<br />
<br />
---------- <br />
That just about sums up the discussion about this project. This project is still very much in its infancy. No hard timelines for ANY of the milestones established have been set. The reason for that is that I want this to be a project that anyone can come into with any level of programming knowledge, say "this part of the project interests me", take charge of it, learn the concepts necessary to complete it, come back to the group, teach what they learned, and implement in a way that helps meet the overarching goal of the project -- Teach, Learn, Build. To make this happen, setting hard timelines isn't feasible since everyone learns at different rates.<br />
<br />
<br />
<br />
I hope to drum up support for this project as far and as widely as I possibly can. I'm not looking for anyone to do the code and solve the problems for me, or folks wanted to collaborate on this project. Even if your contribution to this project is "This task would be best suited to this programming language. Go learn about this concept in this language and come back to me."<br />
<br />
A good friend of mine, Forgotten has started a collaboration github account on github, by the namesake of this project:<br />
<br />
https://github.com/Unallocated/H1N1<br />
<br />
Currently there isn't much there other than the readme; I'm hoping to change that if not on my own, then with your help, slowly but surely.<br />
<br />
Hope to see you on the list of contributors,<br />
<br />
DA_667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-57698407742096172462013-08-23T11:10:00.003-07:002013-08-23T11:25:17.081-07:00autosnort: compatible with Linux MintThis is a really quick post. I've installed Linux mint on my person desktop at home, and out of curiousity, decided to try to run autosnort on mint to verify whether or not any of my build scripts were compatible. Well, the ubuntu autosnort script is 100% compatible with mint.<br />
<br />
I'm aware that mint is primarily a desktop operating system, but if you're interested in running it on a Mint desktop as a sort of personal single workstation IDS, here's what to do:<br />
<br />
1. Get a root shell: sudo /bin/bash<br />
2. wget http://www.github.com/da667/Autosnort/Archive/master.zip<br />
3. unzip master.zip<br />
4. copy the autosnort-ubuntu-[date].sh script and an interface installation script to /root<br />
5. run "bash autosnort-ubuntu-[date].sh"<br />
6. run through the prompts as normal.<br />
7. At the very end, when the script asks you whether or not you want to reboot, choose NO.<br />
8. sudo vi or sudo gedit /etc/rc.local and modify the ifconfig eth0 line.<br />
It initially reads: ifconfig eth0 up -arp -multicast promisc<br />
make it read: ifconfig eth0 up promisc<br />
9. save the file.<br />
10. either reboot, or run "sudo bash /etc/rc.local"<br />
11. Open firefox, or the web browser of your choice. type "localhost" in the address bar. You should be greeted by the web UI of your choosing.<br />
12. ps -ef | grep snort will confirm whether or not snort and/or barnyard2 are running. <br />
<br />
Yes, I know I've said in the past that managing your IDS on the same interface you're sniffing on, or having your sniffing interface be addressable isn't a good thing, but those are for DEDICATED IDS installations, this little "hack" is meant for users who want to drop snort on their personal workstation as an added layer of security.<br />
<br />
Cheers,<br />
<br />
DA_667 da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-84276566652547597022013-08-18T20:39:00.000-07:002013-08-18T20:46:27.437-07:00Changing of the seasons; RHEL/CentOS code push/update; Autosnort milestones posted. So here we are, at the end of August. Defcon has came and went, summer vacation is coming to close, and labor day is right around the corner. I don't consider summer officially over until Labor Day has come and passed, but why postpone it?<br />
<br />
On that note, I've been busy in the lab, and have a whole host of updates that I'm dropping tonight for Autosnort. 99% of these updates are specific to the RHEL/CentOS release, that has been long neglected -- much longer neglected than the other distro scripts. The last update you all saw for RHEL/CentOS was sometime in April. The last major blog post you saw was in regards to the 9 layers of hell I traversed to make Snorby work on CentOS with SELinux enabled, then I disappeared for summer break. So, without further adieu, here's what's happening:<br />
<br />
RHEL/CentOS:<br />
- Updated the entire look and feel of the main autosnort installation script. CentOS/RHEL users now have the metasploit like prompts just like the Debian and Ubuntu users. Only things the user should be aware of are printed to the screen now:<br />
<br />
- Status updates are in blue (e.g. <span style="color: cyan;">[*] <span style="color: white;">this indicates what autosnort is doing currently</span></span>)<br />
- Notifications are in yellow (e.g. <span style="color: yellow;">[*]</span> this indicates something the user needs to pay attention to (such as a prompt, or something they may want to note somehow))<br />
- Successful modifications are in green (e.g. <span style="color: #6aa84f;">[*]</span> this indicates whatever autosnort was doing was successful)<br />
- Unsuccessful modifcations/installations are in red (e.g. <span style="color: red;">[*]</span> something bad happened. You'll probably want to get a hold of me and give me the log files for your installation, so it can be resolved)<br />
<br />
- Speaking of logging, the installations scripts no longer spew output all over your screen buffer. Thanks to neat trick I picked up from stack exchange, the output of every major command is saved in two separate log files in /var/log:<br />
<br />
-/var/log/autosnort_install.log -- contains output from all the major commands ran from the main autosnort installation script<br />
-/var/log/[interfacename]_install.log -- contains output from all the major commands ran from the interface installation script for the interface you chose to install.<br />
<br />
- The main autosnort installation script and all the web interface installation scripts have been updated with the new metasploit-like prompts and the background logging. This includes:<br />
<br />
-autosnort-CentOS-[date].sh<br />
-snortreport-CentOS.sh<br />
-base-CentOS.sh<br />
-aanval-CentOS.sh<br />
-syslog_full-CentOS.sh <br />
-snorby-CentOS.sh<br />
<br />
- All web interface installation scripts for RHEL derivatives have had their DocumentRoot and Directory directives reconfigured to serve out the web interface of your choice. This means all you have to do is point your web browser to the ip address of your sensor's management interface, and provided you reconfigured ip tables to allow port 80 inbound, your web interface will pop up automatically. <br />
- All web interface installation scripts for RHEL-based distros are 100% compatible with SELinux<br />
- All web interface installation scripts for RHEL-based distros have had the ownership of DocumentRoot changed to the apache user and group<br />
-Fixed minor grammatical and syntactical errors littered throughout the script. <br />
<br />
Ubuntu/Debian:<br />
- Apparently at some point between now and june, the passenger output directory for the mod_passenger.so binary changed the name of the directory from "libout" to "buildout". sigh. consistency is awesome, don't you agree? I only discovered this during testing passenger during the CentOS testing process.<br />
- In an effort to make the mysql installs uniform between all autosnort builds and promote better security, I've made the mysql-server installation for Ubuntu and Debian silent, but now, just like with the CentOS script, the /usr/bin/mysql_secure_installation script is ran as a part of autosnort. huzzah for better secured databases.<br />
- Same as the CentOS script, found minor grammatical and syntactical errors littered all over the script. Found and fixed what I could.<br />
<br />
Code push should be happening tonight before init 1 for the night. As usual, the scripts are open source and are available on the autosnort github:<br />
<br />
https://github.com/da667/Autosnort<br />
<br />
While we're on the topic of github, I've posted some milestones that officially lay out where I want to take autosnort next -- things I want to accomplish with it. Have a look, see if I'm missing something:<br />
<br />
https://github.com/da667/Autosnort/issues/milestones?with_issues=no<br />
<br />
And last, but not least... The new project ideas I spoke of in my last blog post? I'm holding a meeting at our local hackerspace about one of them in particular, the passive OS fingerprinting project, trying to get some helping hands with it and make it more of a success. If you're in the Maryland/DC/VA area, come to unallocated space on the 25th so we can get a project outline hashed out.<br />
<br />
Cheers,<br />
<br />
DA_667 <br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-59550032495105892272013-08-05T18:48:00.001-07:002013-08-05T18:48:33.707-07:00End of my Summer vacation; new projects to consider -- want feedback!Dear autosnort users,<br />
<br />
I just got back from Defcon. Summer is almost over. You're probably wondering if this lazy louse is going to get off his ass and start scripted again. Well, yes, but, I have some details to announce.<br />
<br />
1. I will definitely be continuing the Autosnort project. I never really had the intention of taking the summer off, but now I'm kinda realizing that it makes sense to do this. Summer is practically the only time I get to spend with other hackers locally and at Defcon, and one of the few times a year that I get to see family back home.<br />
<br />
First on my order of things to do is to finish testing on CentOS for pulled pork. I released the selinux module I painstaking build through a couple of weekings of gnashing teeth and cursing, but I want to have the selinux module generated by the snorby install script for centOS instead of having use have to bring another item with them for the installation. Right now, I have the script echoing out the source of the module that I got to work and building that generated file. It looks kludgy in the code, but it works wonderfully.<br />
<br />
2. I have an ambitious project that I really want to get some help doing. I was a former Sourcefire employee. That being said, I'm familiar with RNA or what they call firesight right now. The general gist of this technology is to gain insight as to what operating systems are running in your network, and make one's snort ruleset more efficient based on that -- You're not going to care about X11 exploit rules if you're not running Linux boxes with publically listening X servers, the same as you wouldn't care about seeing alerts about SMB/windows malware attacks if you have your HOME_NET defined as a network that is solely a groupe of freeBSD servers not running samba.<br />
<br />
p0f -- passive OS fingerprinting has been around for years, at least a few decades. I was present at shmoocon. The project had been idling for a while up until a group of folks decided to request access to oversee the project and continue on with it. This was a talk at shmoocon over a year ago. The project is alive and kicking.<br />
<br />
What I want to be able to do: take p0f signatures, have them monitor a defined network, and develop a measure of confidence as to what is running in your home network.<br />
<br />
take this intelligence and use it modify pulledpork -- enable/disable sids based on p0f results, set ip defragmentation and tcp stream reassembly policy by majority of X hosts in your HOME_NET, etc.<br />
<br />
the thing is, I'm not quite sure where to start. If anyone wants to help me with this in any way... I want to make this happen.<br />
<br />
3. Malware analysis wiki. this inspired by my friend @forgottensec. Forgotten ended up providing the Capture the Flag community the CTF wiki. Well, I want to provide a resource for the information security community as well:<br />
<br />
There seems to be information scattered to the seven corners of the internetz. I want to gather as much information as I possibly can into one way for malware analysis techniques. For example, I don't the first thing about using debuggers to debug malware, but I know lots of interesting things to look for, when it comes to dynamic malware analysis. Why not put it some place publically accessible and easily contributed to?<br />
<br />
Let me know what your thoughts are on these new developments I'm thinking about, until then... I'm gonna enjoy the end of my summer before I have to get my lazy ass back to workda_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com2tag:blogger.com,1999:blog-7331752786831922328.post-81765878744058847622013-07-22T18:51:00.000-07:002013-07-22T18:51:09.183-07:00Still Out here!Hello Autosnort Users,<br />
<br />
This is just a quick update to inform you all that I'm still out here and still consider autosnort an active endeavor. I guess you could say that I'm on summer break, and it wouldn't be too far off. I went home some time in July for vacation, been studying Python after hours at work, Enjoying the steam summer sales with my sparse spare time, and I'm looking forward to going to Defcon/Bsides in the coming week. <br />
<br />
In spite of rumored... hostilities real, imagined, thinly-veiled or otherwise, I'm a hacker and security researcher first, and above all else. I enjoyed Defcon the last time I went, and I'm sure this time will be just as enjoyable.<br />
<br />
Until then, I ask that you be patient.<br />
<br />
Cheers,<br />
<br />
DA_667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-17887937582427020862013-06-23T13:05:00.000-07:002013-06-23T21:43:38.888-07:00Autosnort-CentOS progress -- SELinux, ROR, passenger, and Snorby all working in HarmonyI've been working pretty hard on getting The CentOS autosnort build up to par with the Debian and Ubuntu autosnort builds, and for the most part, I'm nearing the end of the road there.<br />
<br />
Aside from work and my regular everyday life, I've been spending my weekends mostly working on getting Snorby to run on CentOS with SELinux enabled. I'm a firm believer that in this day and age you shouldn't have to turn off SELinux to make your application work.<br />
<br />
According to Wikipedia, SELinux has been around since the year 2000 and mainlined into the 2.6 kernel since 2003. It's been close to over ten years since SELinux was rolled out. Turning it off isn't a solution. It's a work-around, and pardon my french, an incredibly shitty and lazy work-around at that.<br />
<br />
Now, I've made it no secret that I do not like ROR at all. This could be for a number of reasons -- I'm a newb programmer, I haven't developed webapps, I don't know what I'm talking about -- take your pick. Do not take this as a personal attack if you love ROR for one reason or another. Ruby OTOH has given us pretty interesting things, such as the Metasploit Framework.<br />
<br />
In troubleshooting this how to get Snorby and SELinux to behave I had to learn how to write SELinux policy modules. As a side note, I would like to thank whoever on github posted this gist:<br />
<br />
<a class="ot-anchor" href="https://gist.github.com/2-718/708659" rel="nofollow">https://gist.github.com/2-718/708659</a><br />
<br />
The code that I am dropping below is HEAVILY based on this individual's work getting passenger to work under SELinux without turning it off. I don't know who you are, but I salute you.<br />
<br />
Let me give you a bit of background. SELinux is incredibly modular, there are several different ways you can tell SELinux to allow an application to do certain things, access certain resources, etc. You can use chcon to tell SELinux to allow a process to access files (think of this as another layer on top of the file access controls that we all know and love with chmod/chown), there are booleans you can set that, almost windows registry-like tell SELinux to allow a process to be able to interact with a mysql database or connect over the network.<br />
<br />
Then there is the ability to write your own modules via selinux development tools to load into SELinux and in turn load into the kernel. You would generally do this if the application is very complex and needs to get its hands into a lot of places.<br />
<br />
The research I did on this over the weekend varied. Most places suggest just running the application over and over again -- each iteration, just running audit2allow to determine what it is that httpd wants access to and building a policy module out of it.<br />
<br />
I kept doing this, and more and more things would be allowed, then of course, the next thing in the way would break. It felt like dependency hell all over again.<br />
<br />
Eventually I found that block of code by someone who had apparently been here before and decided to iterate through audit2allow probably hundreds of times to develop a single policy for passenger. I took it, ran with it, and improved it. Over the last few evenings I expanded upon it, and finally got Snorby to a point to where it will run with 0 errors and full functionality with SELinux enforcing and in targeted mode.<br />
<br />
Have a look; I'll be posting this code to github soon, but I wanted to copy it here just to give you an idea of what the hell this application has access to on your system: <br />
<br />
### begin code ### <br />
module passenger 1.0;<br />
<br />
# Not an expert at SELinux module building, but this is similar to library declarations in C programming -- these are things that the module needs to be able to do and contexts the module needs to be able to understand/communicate with<br />
<br />
require {<br />
type init_t;<br />
type initrc_t;<br />
type system_cronjob_t;<br />
type mysqld_t;<br />
type usr_t;<br />
type syslogd_t;<br />
type system_dbusd_t;<br />
type abrt_dump_oops_t;<br />
type dhcpc_t;<br />
type kernel_t;<br />
type auditd_t;<br />
type udev_t;<br />
type mysqld_safe_t;<br />
type postfix_pickup_t;<br />
type sshd_t;<br />
type crond_t;<br />
type getty_t;<br />
type anon_inodefs_t;<br />
type httpd_tmp_t;<br />
type devpts_t;<br />
type user_devpts_t;<br />
type httpd_sys_script_t;<br />
type security_t;<br />
type httpd_t;<br />
type unconfined_t;<br />
type selinux_config_t;<br />
type hi_reserved_port_t;<br />
type httpd_sys_content_t;<br />
type httpd_sys_rw_content_t;<br />
type var_t;<br />
type cert_t;<br />
type postfix_qmgr_t;<br />
type postfix_master_t;<br />
class file { getattr read create append write execute execute_no_trans open };<br />
class process { siginh signal noatsecure rlimitinh setpgid getsession };<br />
class unix_stream_socket { read write shutdown };<br />
class chr_file { read write append ioctl };<br />
class capability { setuid dac_override chown fsetid setgid fowner sys_nice sys_resource sys_ptrace kill };<br />
class fifo_file { setattr create getattr unlink };<br />
class sock_file { write getattr setattr create unlink };<br />
class lnk_file { read getattr };<br />
class udp_socket name_bind;<br />
class dir { write read search add_name getattr };<br />
}<br />
<br />
#This stuff below is more of an access control list -- these are things the contexts below are requesting to be able to do in order to run properly.<br />
#============= httpd_sys_script_t ==============<br />
allow httpd_sys_script_t abrt_dump_oops_t:dir { search getattr };<br />
allow httpd_sys_script_t abrt_dump_oops_t:file { read open };<br />
allow httpd_sys_script_t anon_inodefs_t:file { read write };<br />
allow httpd_sys_script_t auditd_t:dir { search getattr };<br />
allow httpd_sys_script_t auditd_t:file { read open };<br />
allow httpd_sys_script_t cert_t:dir { search getattr };<br />
allow httpd_sys_script_t cert_t:file { read getattr };<br />
allow httpd_sys_script_t cert_t:lnk_file read;<br />
allow httpd_sys_script_t crond_t:dir { search getattr };<br />
allow httpd_sys_script_t crond_t:file { read open };<br />
allow httpd_sys_script_t devpts_t:chr_file { read write };<br />
allow httpd_sys_script_t dhcpc_t:dir { search getattr };<br />
allow httpd_sys_script_t dhcpc_t:file { read open };<br />
allow httpd_sys_script_t getty_t:dir { search getattr };<br />
allow httpd_sys_script_t getty_t:file { read open };<br />
allow httpd_sys_script_t httpd_sys_content_t:fifo_file setattr;<br />
allow httpd_sys_script_t httpd_sys_content_t:sock_file { create unlink setattr };<br />
allow httpd_sys_script_t httpd_sys_rw_content_t:file { execute execute_no_trans };<br />
allow httpd_sys_script_t httpd_t:dir { search getattr };<br />
allow httpd_sys_script_t httpd_t:file { read open };<br />
allow httpd_sys_script_t httpd_t:unix_stream_socket { read write };<br />
allow httpd_sys_script_t httpd_tmp_t:fifo_file setattr;<br />
allow httpd_sys_script_t httpd_tmp_t:sock_file { write create unlink setattr };<br />
allow httpd_sys_script_t init_t:dir { search getattr };<br />
allow httpd_sys_script_t init_t:file { read open };<br />
allow httpd_sys_script_t initrc_t:dir { search getattr };<br />
allow httpd_sys_script_t initrc_t:file { read open };<br />
allow httpd_sys_script_t kernel_t:dir { search getattr };<br />
allow httpd_sys_script_t kernel_t:file { read open };<br />
allow httpd_sys_script_t mysqld_safe_t:dir { search getattr };<br />
allow httpd_sys_script_t mysqld_safe_t:file { read open };<br />
allow httpd_sys_script_t mysqld_t:dir { search getattr };<br />
allow httpd_sys_script_t mysqld_t:file { read open };<br />
allow httpd_sys_script_t postfix_master_t:dir { search getattr };<br />
allow httpd_sys_script_t postfix_master_t:file { read open };<br />
allow httpd_sys_script_t postfix_pickup_t:dir { search getattr };<br />
allow httpd_sys_script_t postfix_pickup_t:file { read open };<br />
allow httpd_sys_script_t postfix_qmgr_t:dir { search getattr };<br />
allow httpd_sys_script_t postfix_qmgr_t:file { read open };<br />
allow httpd_sys_script_t self:capability { setuid chown fsetid setgid fowner dac_override sys_nice sys_resource sys_ptrace kill };<br />
allow httpd_sys_script_t self:process { setpgid getsession };<br />
allow httpd_sys_script_t sshd_t:dir { search getattr };<br />
allow httpd_sys_script_t sshd_t:file { read open };<br />
allow httpd_sys_script_t syslogd_t:dir { search getattr };<br />
allow httpd_sys_script_t syslogd_t:file { read open };<br />
allow httpd_sys_script_t system_cronjob_t:dir getattr;<br />
allow httpd_sys_script_t system_dbusd_t:dir { search getattr };<br />
allow httpd_sys_script_t system_dbusd_t:file { read open };<br />
allow httpd_sys_script_t udev_t:dir { search getattr };<br />
allow httpd_sys_script_t udev_t:file { read open };<br />
allow httpd_sys_script_t unconfined_t:dir { search getattr };<br />
allow httpd_sys_script_t unconfined_t:file { read open };<br />
allow httpd_sys_script_t unconfined_t:process signal;<br />
allow httpd_sys_script_t user_devpts_t:chr_file { read write append ioctl };<br />
allow httpd_sys_script_t usr_t:file execute;<br />
allow httpd_sys_script_t var_t:dir { write read add_name };<br />
allow httpd_sys_script_t var_t:file { read getattr create append };<br />
#============= httpd_t ==============<br />
allow httpd_t hi_reserved_port_t:udp_socket name_bind;<br />
allow httpd_t httpd_sys_content_t:fifo_file { create unlink getattr setattr };<br />
allow httpd_t httpd_sys_content_t:sock_file { getattr unlink setattr };<br />
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure };<br />
allow httpd_t httpd_sys_script_t:unix_stream_socket { read write shutdown };<br />
allow httpd_t httpd_tmp_t:fifo_file { create unlink getattr setattr };<br />
allow httpd_t httpd_tmp_t:sock_file { getattr unlink setattr };<br />
allow httpd_t security_t:dir search;<br />
allow httpd_t self:capability { fowner fsetid };<br />
allow httpd_t selinux_config_t:dir search;<br />
allow httpd_t var_t:file { read getattr };<br />
allow httpd_t var_t:lnk_file { read getattr }; <br />
<br />
### end code ###<br />
<br />
Admittedly there are a number of things above that make sense that Snorby would need access to -- sockets, file execution, making its own fifos, managing its own files and process execution options, etc. but then there are other things that just made me go WTF. Why does the webapp need access to crond? to getty sessions? pts? sshd? cronjobs? files and directories under the unconstrained context? dhcp files? auditd files?<br />
<br />
I could be blowing this entirely out of proportion, but I worked with snortreport, BASE and aaval, and there were a minimal number of things I had to enable to get each of those interfaces to work under SELinux. Maybe PHP is just better integrated into SELinux, or maybe SELinux knows that PHP is beyond hope and doesn't even try to constrain it. I don't know, but reading through the module and seeing what it has access to is kinda crazy to me.<br />
<br />
Okay, so now that I'm off my soapbox, you're probably wondering when to expect a code push for CentOS.<br />
<br />
The answer is: soon. I know that's not the answer you all want to hear, but it's the best I can give right now -- The rewrite of the main script is mostly done. At this point, I'm working on re-writing the child shell scripts, prettying them up, and also ensuring that Snorby plays nice.<br />
<br />
I'm going to re-iterate again, that this isn't any sort of a personal attack on any developer of any web interface, or against any platform, just my (probably ill-informed) opinion based on my observations.<br />
<br />
Until next time,<br />
<br />
DA_667<br />
<br />
Addendum: I thought I would add a note stating that the I've posted the code above into an SELinux module that is available via autosnort's github under the CentOS autosnort directory, in a subdirectory called "PolicyModules". the directory contains passenger.te as well as a PolicyModulesNotes.txt file that details how to actually compile the passenger.te file into an SELinux module. This is for those who may not necessary care to use autosnort, may not care to use Snorby, but may need some help trying to figure out what accesses Ruby, Rails, and Passenger want on SELinux enabled systems.<br />
<br />
I hope that it is some help to the Linux community.da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-74132770260029388052013-06-14T22:22:00.002-07:002013-06-14T22:23:51.433-07:00New Autosnort Release, support for more distros and much more!Hello,<br />
<br />
Lots to talk about, so let's get started.<br />
<br />
I finally got around to finishing testing for the new, improved, and much cleaned up build of Autosnort that I had been hyping for a little while. For those who didn't see the last blog post, or the screen shot, I've done a bit of housekeeping with Autosnort.<br />
<br />
Instead of puking the output for every single command all over the screen buffer, Autosnort's output has been significantly minimized and cleaned up where it could be cleaned up. Output is now very metasploit-like:<br />
<br />
<span style="color: blue;">[*]</span> are things that the script is doing<br />
<span style="color: #ffd966;">[*]</span> are things the user should pay attention to<br />
<span style="color: #38761d;">[*]</span> are successful results<br />
<span style="color: #990000;">[*]</span> are unsuccessful results<br />
<br />
"Okay, so what if something goes wrong? All I have is a generic 'something went wrong' comment." Well, instead of hoping whatever you need was caught in the screen buffer, autosnort now logs the output of the ENTIRE installation to /var/log/autosnort_install.log, and /var/log/[interface you chose to install here -- for example, snort_install.log], So now, instead of having to hope the screen buffer caught the relevant bits of a problem with my script, you now have an entire log of what the script was actually doing for review, or to send to me to debug the script and get it to work properly.<br />
<br />
The script will now actually tell you where I installed things, instead of you having to hunt and guess (sorry about that..) <br />
<br />
Additionally, this release sees support for Ubuntu 13.04 and Debian 7. Currently in the process of Verifying support for Kali Linux (Backtrack's newer, younger sibling), but since it's all supposed to based off Debian and follows the Debian software methodology, it should be pretty straightforward.<br />
<br />
The child installer scripts all got this little makeover, and as previously mentioned also have logging built in, and write to their own log files in /var/log.<br />
<br />
The only thing of note that changed here in addition to the minimizing of output would be that I finally added a prompt to run Aanval's BPU processes on boot via rc.local. That's something I've been meaning to do for a while.<br />
<br />
So now that this is over with, the next step would be for me to focus on Getting CentOS updated -- Snorby and the cleaned up autosnort script. That is next up on my plate before enabling anymore features on any platform. period.<br />
<br />
After that is finished, here's what I'd like to focus on:<br />
<br />
- All web interfaces should have SSL/HTTPS enabled by default. No exceptions.<br />
- Remove database/barebone sensors should have a method to secure database transactions to the "Master Console"<br />
+ some point way far down the line, I want to begin experimenting with p0f. The project has recently gotten some new blood (as mentioned in a recent shmoocon), and there are some interesting possibilities I can think of where p0f and snort could play incredibly well off of one another:<br />
--have p0f run for a set period of time, sample traffic off the network, fingerprint operating systems and write results to a database<br />
--script something out that takes the database results and helps write frag3/stream5 reassembly policies based off p0f results.<br />
<br />
Same as always, the scripts are available via <a href="https://github.com/da667/Autosnort">The Autosnort Github Repo</a><br />
<br />
That's about it for now. Happy snorting, hope you enjoy the new release!<br />
<br />
DA_667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-35374077422429706372013-06-07T22:48:00.000-07:002013-06-07T22:53:33.337-07:00Autosnort: MSF editionWorking on some changes to Autosnort.<br />
<br />
After seeing Darkoperator's <a href="https://github.com/darkoperator/MSF-Installer">MSF Installer</a> script, I wanted to change how Autosnort operates a little bit.<br />
<br />
You see, one of the cool things about metasploit is that It will log to hell and back if things are or are not working, but while you're actually running it, It only tells you what you need to know:<br />
<span style="color: blue;"> "This is what I'm trying to do right now"</span><br />
<span style="color: lime;">"This good thing happened"</span><br />
<span style="color: red;">"This bad thing happened"</span><br />
<span style="color: yellow;">"This is something to be aware of."</span><br />
<br />
Keeping this in mind, and heavily ganking the notification printing code from darkoperator, in combination with a crazy named pipe trick I found via stack overflow, I'm changing how autosnort presents information.<br />
<br />
As it stands currently, Autosnort, to put it bluntly, pukes all over the terminal/screen buffer. If something exploded in a bloody mess or failed to install correctly, you may see it and may be able to capture it in a screen shot and report it back to me, or you may not. Digital gods only know.<br />
<br />
The way I've re-written the script, the only thing that gets printed to the screen are status messages indicating what the script is doing, good/bad messages to let you know if something failed or succeeded, and notifications that are sort of a "I need your input here" or "Pay attention to this!"<br />
<br />
Apt-get (with the exception of the mysql-server installation that REQUIRES user input), configuration, compiler and all other output is redirected to log files. <br />
<br />
For those of you who like seeing autosnort puke all over the screen or actually seeing what's going on behind the scenes, I found a nifty hack via <a href="http://stackoverflow.com/questions/3173131/redirect-copy-of-stdout-to-log-file-from-within-bash-script-itself">stack overflow</a> that uses mkfifo and named pipe magic to log everything from the script into a log file. No more running script to log output, no more screenshots, if you have a problem, you can e-mail me the output from the main autosnort script and/or the child interface installation scripts.<br />
<br />
As of right now, I'm piloting this out on Debian, and it just looks <i>slick. </i>So far, I have the main script re-written and snorby's installation script re-written in this format. The other interface installers should fall in line easily enough, Snorby is the most complicated install I scripted out.<br />
<br />
I haven't officially released either scripts out to github because I'm working on a couple other issues as well:<br />
<br />
-- Support for both Debian 6 AND Debian 7 in the autosnort-debian main script<br />
The only problem I'm seeing here at this point is that libmysqlclient.so (for barnyard2) installs in three different places in Debian 6 32/64 and Debian 7 32/64:<br />
/usr/lib (Deb 6 32 and 64 bit)<br />
/usr/lib/i386-linux-gnu (Deb 7 32)<br />
/usr/lib/x86_64-linux-gne (Deb 7 64)<br />
<br />
so I'm testing out a work-around involving the 'find' command and 'dirname' to fix this once and for all.<br />
<br />
-- Support for Ubuntu 13.04<br />
It's a short-term release, but some want to see support for it. It also appears to have an issue finding libmysqlclient.so<br />
<br />
My theory is, if I can get find/dirname tested/working on Debian 6/7, likely I can get it to work between Ubuntu 12 and 13.04, hell I might be able to merge the Debian and Ubuntu autosnort scripts into a single script (since this was one of slight differences between the two).<br />
<br />
So there's that.<br />
<br />
I'm going to try and include a screenshot down here to preview what to expect, but so far, Blogger has somehow managed to not get my photos attached to my blog posts every time I've tried to use them.<br />
<br />
First try:<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO3N4R-RAZITk-V3hnogozswJWX4X52MgTXeysVleiLxLl3JDGsDrtfp6MuDNPanGx8FZqj4U7prcdyeedBGMsTMrdKQ7h360S76fLAh6pcJMpT8pO7PI6kx_qVsHg3hs-g7Trwnp3Wr9M/s1600/auto-snortMSFedition.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" class="gdmdujpmmvrkqsayfuvv" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgO3N4R-RAZITk-V3hnogozswJWX4X52MgTXeysVleiLxLl3JDGsDrtfp6MuDNPanGx8FZqj4U7prcdyeedBGMsTMrdKQ7h360S76fLAh6pcJMpT8pO7PI6kx_qVsHg3hs-g7Trwnp3Wr9M/s1600/auto-snortMSFedition.PNG" /></a></div>
<br />
Second try:<br />
<a href="https://twitter.com/da_667/status/343225951695552512/photo/1">Via my twitter</a>da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-67046237605715079082013-06-01T22:06:00.001-07:002013-06-02T12:05:44.392-07:00Not snort-related, but a good thing to know: How to tunnel VNC over SSH<span style="font-family: inherit;">So, this isn't strictly snort or autosnort related, but I figured I would post it anyhow. I primarily use SSH to manage my autosnort testing sensors in my virtual environment, but I also use vnc over SSH to manage my Attack system (A Kali Linux box -- was formerly Backtrack 5 r3) and thought I would share my experience on how to set up vnc server over SSH and have it look somewhat decent.</span><br />
<br />
<span style="font-family: inherit;">I've found a blog post here and a blog post there about how to tunnel VNC over ssh, but nothing really comprehensive. So I thought I'd share my knowledge on the bits of wisdom I've found strewn all over the net. If you have anything to contribute, or anything to add, please do so.<br /><br />To begin, VNC is old and insecure; It encrypts absolutely nothing. This is why we're going to wrap it over SSH. In addition to a lack of encryption, VNC4's password functionality only allows 8-character passwords. This means the password can be broken fairly easily, even with a random password.<br /><br />Tunneling VNC over SSH allows you to use stronger authentication (keys or huge long passwords, or both) in additional to the VNC password, setting up a basic form of multifactor authentication.<br /><br />Most debian-based distro package sources include vnc server. It can be installed via:<br /><br />apt-get install vnc4server<br /><br />Afterwards, you will need to run vnc4server manually or vnc4passwd to specify a password for the current user for using VNC. again, the password can only be 8 chars long.<br /><br />Additionally, in the user's .vnc folder (e.g. ~/.vnc or /home/[user]/.vnc/ ) is a file entitled xstartup<br /><br />xstartup must be executable, and looks something like this:<br /><br />#!/bin/sh<br /># Uncomment the following two lines for normal desktop:<br />#unset SESSION_MANAGER<br />#exec /etc/X11/xinit/xinitrc<br /><br />[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup<br />[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources<br /><br />#xsetroot -solid grey<br />#vncconfig -iconic &<br />#x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &<br />#x-window-manager &<br /><br /> Change the file to look something like this:<br /><br />#!/bin/sh<br /># Uncomment the following two lines for normal desktop:<br /><br />unset SESSION_MANAGER<br />exec /etc/X11/xinit/xinitrc<br /><br />[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup<br />[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources<br /><br />#xsetroot -solid grey<br />#vncconfig -iconic &<br />#x-terminal-emulator -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &<br />#x-window-manager &<br />startx &;<br /><br />if the .vnc directory doesn't exist, try running "vnc4server" to start up vnc. This should give you a .vnc directory and the file above. After starting it, immediately kill it via kill -9 or killall vnc4server.<br /><br />Next, we need to make an init script to start up vnc at boot. I found this init script via<br /><br />http://www.isnull.com.ar/2010/03/vnc4server-boot-script-working-in.html<br /><br />I've made some minor improvements, however. Copy these contents to /etc/init.d/vncserver:<br /><br /><br /><br /># /etc/init.d/vnc4server<br />#<br /># Some things that run always<br /><br />touch /var/lock/vnc4server<br /><br /># Carry out specific functions when asked to by the system<br />case "$1" in<br /><br />start)<br />echo "Starting script vnc4server "<br />su root -c 'vnc4server -depth 24 -pixelformat RGB888 -localhost -geometry 1440x900 '<br />;;<br /><br />stop)<br />echo "Stopping script vnc4server"<br />su root -c 'killall Xvnc4'<br />;;<br /><br />*)<br />echo "Usage: /etc/init.d/vnc4server {start|stop}"<br />exit 1<br />;;<br /><br />esac<br /><br />exit 0<br /><br />The line that is doing the all the work of running the vnc server is this line:<br /><br /> vnc4server -depth 24 -pixelformat RGB888 -localhost -geometry 1440x900<br /><br />This line is essentially saying "start the vnc server with 24-bit color depth, with this RGB mapping and a resolution of 1440x900, and only allow it to listen on 127.0.0.1" (This last part is important! do not forget the -localhost line!) You can change the -geometry line to any resolution you wish, but I had to figure out the -depth and -pixelformat lines on my own, and mainly through trial and error. <br /><br /><br /><br />next you'll have to make the file executable (chmod u+x /etc/init.d/vncserver)<br /><br />after making the file executable, run:<br /><br />update-rc.d vncserver defaults<br /><br />or<br /><br />update-rc.d vncserver start [runlevels you want the server to run on]<br /><br />finally, the file make the xinitrc file executable. I've found that vnc won't work properly unless this file is executable:<br /><br />chmod u+x /etc/X11/xinit/xinitrc<br /><br />The higher the bit depth and resolution, the more packets you need to be able to push over the network (and your SSH tunnel) to keep things running smoothly. For this reason, I recommend that if you're going to use this configuration that it be over a high-speed link, or a local network. try changing the depth to 16, or making the resolution lower if you find the VNC session to be laggy.<br /><br />So to summarize what we just did above we:<br /><br />installed vnc4server<br /><br />set up a vnc password for your user<br /><br />made an init script for vnc4server<br /><br />made all necessary preparations to host vnc4 server.<br /><br /><br />In this section I'll show you how to SSH tunnel to your VNC server either from windows or linux.<br /><br />We'll start with windows. I use an awesome program called MRemoteNG for managing remote connectivity via a number of remote protocols -- VNC, RDP, SSH, .ICA (citrix), HTTP/HTTPS (xulrunner-- a bit buggy), etc. I can't stress how awesome MRemoteNG is for managing multiple connections. For those worried about having the app store connection information, it also allows you to encrypt the connection configuration files to keep your creds safe.<br /><br /><br />Download and Install MRemoteNG. Open it up and click Tools::Options:: and click advanced. Click "Launch Putty"<br /><br /><br />Here is where we're going to configure the portforwarding settings. Under Category, go down to Connections, click the plus sign on SSH, then click tunnels.<br /><br />This page looks confusing, but it's really simple. <br /><br />The only things you need to modify are<br /><br />Source Port: set this to any arbitrary port number you want. Doesn't really matter. Just remember what it is. If you can't remember, you can always come back to this page.<br /><br /><br /><br />For destination type this in exactly: 127.0.0.1:5901<br /><br />The more intrepid may ask "uh.. why am I putting localhost in as the destination?"<br /><br />Because this is localhost on the REMOTE server (e.g. the system where VNC is listening on loopback (127.0.0.1) only. So what this tunnel is saying is:<br /><br />"After this user has successfully authenticated to me, have the client open up source port:[source port you choose]. If you get a connection on [source port you chose], funnel it over port 22. When it reaches the remote end, connect it to 127.0.0.1:5901 where the VNC server is listening."<br /><br />Save your putty session by scrolling up, clicking on sessions, putting in a name under "saved sessions" then clicking save. Afterwards, you can close putty.<br /><br /><br />You'll need to create two mremoteng sessions here:<br /><br /><br />the first Mremote session, select ssh version tool as the protocol, enter the IP address (user name and/or password if you want) and under PuTTY session, click the drop down and save the session you made.<br /><br /><br />the second Mremote session, you'll choose VNC as the protocol. Enter the IP address "127.0.0.1" and the source port that you entered when you created the putty session above. For the password, enter the password you entered when you ran vnc4passwd or vnc4server previously.<br /><br /><br />Next, double click on your ssh session in mremoteng, then double click on your localhost VNC session. You should have your remote system's desktop.<br /><br />If you're doing this over Linux, it's not that much harder to do. Make sure your linux connecting to the remote SSH (and VNC) server has an ssh client and a vncviewer application of some sort.<br /><br /><br />Open up a terminal window and type:<br /><br />ssh -L 5901:localhost:5901 username@[hostname/ipaddress]<br /><br />The -L line above is the secret sauce and works exactly the same as the what the putty session does:<br /><br />[Source Port to listen on locally]:[target remote ip address]:[remote port to connect to]<br /><br />So we tell SSH to open a listener on 5901 if your local workstation gets a connection on 5901, forward it over the SSH connection and send it to 5901 on the remote server's loopback address.<br /><br />Next, just tell your vnc client to connect to 127.0.0.1:5901 and you're done.<br /><br /><br /><br /><br /><b>Note:</b> Some of the more intrepid among you may notice that there's now a listener on 6001/tcp. I've searched long and hard for the reasoning behind this. 6001/tcp is the default port for the first X server screen to use when X is told to listen for remote X client connections.<br /><br /><br />Some of you are probably freaking out. you don't want your server to allow connections to X windows. Don't freak out just yet; Sure enough, if you get NMAP scanned, NMAP will say the port is open. Netcat will connect and promptly get dropped. PuTTY RAW sessions stay open (probably because the remote X server has no idea what the heck the PuTTY RAW session is trying to do.) No remote X clients will be able to connect to the x server. While you are on your vnc session, If you type "xhost" in a terminal window "access control enabled, only authorized clients can connect" should be the response you get. In the olden days, way before even my time, No one thought to tunnel X over SSH. so they would use xhost to authorize remote users to connect to that system's X windows server. The format was usually xhost +{ip address} to allow a remote ip address to connect to your X server. Even more common was for most to just type xhost + (no ip address). This is the same as saying "Allow anyone to connect to my X server". You can probably imagine why this isn't a good idea.<br /><br /><br />So why am I telling you about this? Because by default, your X server (the one that VNC uses), for some stupid reason has your X11 X windows server listen on 6001/tcp. <b>From what googling I've done, there's no reason for this, and there's no way to configure X (without modifying the source code) to just listen on localhost.</b> I've tried to find a solution that isn't "turn on your firewall, or just configure firewall rules to block it." That's a work-around, not a solution (A viable work-around, by the way, but not the point.) and I haven't find any (other than the just a firewall rule)<br /><br /><br />For those of you who aren't firewall gurus, you're in luck. by default, xhost doesn't authorize ANY remote users at all to connect to your X server. That means, as soon as anyone tries to connect to your X server, the session is dropped by X's own authorization system. <b>The bottom line is: Don't freak out; no one is allowed to connect to it. You're safe. But if you know how to make X listen on 127.0.0.1 only, I'd be very interested...</b><br /><br /><b>Final Note:</b> On some sshd servers, TCP Forwarding is disabled. TCP forwarding is the magic by which all this tunneling happens. Meaning if it's disabled, then none of this works. Check /etc/ssh/sshd_config if you see the line "AllowTcpForwarding no" it means tcp forward is turned off. Conversely, if it is set to yes, then you're good to go. If you don't see this line in your sshd_config file, then you're good to go as well. It's implicitly allowed by default.<br /><br /><br /> </span><br />
<span style="font-family: inherit;"><br /></span>
da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-32486333796087623752013-05-24T15:56:00.000-07:002013-05-24T16:12:30.261-07:00Troubleshooting your Snort deploymentI recently had a discussion with a user new to snort and autosnort who
wanted to know some troubleshooting techniques that can be done to see
if snort is working and/or snorby or the web interface of your choosing
is working. After thinking about it, I decided it might be a good idea
to post my troubleshooting steps here to assist users of snort and
snorby in general to determine if things are working okay.<br />
<br />
Before we begin here, realize that there are a number of moving parts with any IDS/IPS deployment. Understanding the basics of networking (OSI/TCPIP stacks, collision domains and/or broadcast domains) really help you in understanding why snort can or cannot see traffic for certain parts of your network. If you have no way of copying traffic from the network segment you want to protect, then snort will not be able to see anything.<br />
<br />
Now that I got that part out of the way, there are a couple of basic components in any snort deployment:<br />
<br />
1) the network<br />
<br />
How busy is your network? If the network isn't particularly active, it may take a while before you see any sort of alerts from snort.<br />
<br />
2) the method you are using to pass network traffic to snort<br />
<br />
How are you copying traffic to snort's sniffing interface? Do you have an old hub? a professional grade network tap or hobbyist network tap? A switch that can do port mirroring/span ports? Is snort sitting in a VM? does that virtual machine have a way to sniff traffic off of the vswitch?<br />
<br />
Any IDS/IPS deployment needs a reliable method to clone/copy traffic off of the network. If you plug snort into a regular switch port or SOHO router, you're usually only going to see broadcast traffic (usually UDP broadcasts, CDP broadcasts, Spanning tree traffic, and ARP requests) and will be absolutely useless to you.<br />
<br />
You need to have the equipment or means to copy traffic to snort somehow. <br />
<br />
3) Snort itself and how it's configured<br />
<br />
If you have a light ruleset (say the balanced ruleset from pulledpork, or the connectivity over security ruleset), you won't be seeing very many alerts, unless those rules are a really big deal, like big enough to be included in those rulesets, and/or if your network is particularly infested with bad traffic.<br />
<br />
4) Barnyard2, how it's configured and/or the database it is logging to<br />
<br />
Autosnort is configured to use barnyard2 and log to a local database. normally this is the "snort" database, but some web interfaces require their own database (e.g. Aanval uses the aanval database and snort database, snorby uses the snorby database). Does barnyard2's database user have the right access to insert events to the database? does the database user have the right credentials?<br />
<br />
For other barnyard2 logging options, such as syslog, is the remote host allowing connections from your sensor's management interface? is the SIEM solution configured to log syslog events properly?<br />
<br />
So, to summarize IDS/IPS deployments have a number of parts that have to work together to provide you with a working solution: The network itself, the method you are using to copy network traffic to snort, snort or the IDS/IPS solution you are using and what its configured to alert on, and the method by which you are logging intrusion events (barnyard2/database/syslog).<br />
<br />
Here are some basic troubleshooting methods I've devised:<br />
<br />
<div>
<b>Basic Steps:</b></div>
<div>
<b><br /></b></div>
<b>1) are snort processes running? If you're using Snorby or another specialized logging interface, are the processes that interface relies on running?</b><br />
<br />
ps -ef | grep snort<br />
<div>
ps -ef | grep delayed</div>
<br />
<div>
you are looking for this output from ps -ef | grep snort:<br />
<br />
root 1853 1258 0 17:54 pts/0 00:00:00 grep snort<br />
snort 1883 1 0 May18 ? 00:00:47 /usr/local/snort/bin/snort -D -u snort -g snort -c /usr/local/snort/etc/snort.<wbr></wbr>conf -i br0<br />
root 1912 1 0 May18 ? 00:00:53 /usr/local/bin/barnyard2 -c /usr/local/snort/etc/<wbr></wbr>barnyard2.conf -d /var/log/snort -f snort.u2 -w /var/log/snort/barnyard2.waldo -D</div>
<div>
<br />
you are looking for this output from ps -ef | grep delayed:<br />
<br />
root 1869 1258 0 17:55 pts/0 00:00:00 grep delayed<br />
root 2161 1 0 May18 ? 00:11:01 delayed_job<br />
</div>
<div>
If snort and barnyard2 BOTH are not running, check /var/log/messages (cat /var/log/messages [or /var/log/syslog depending on your distro] | grep snort) to see if you can determine why. <b>Look for error, critical or fatal messages as they indicate reasons why snort or barnyard2 refused to run</b>. We'll talk about snorby's delayed_job process in a moment.</div>
<div>
<br /></div>
<b>2) ifconfig -a</b><br />
<br />
-- which interface is snort sniffing traffic on? is it in promiscuous mode?<br />
<br />
<div>
You're looking for output that looks something like this
on the interface that snort is sniffing traffic on, pay attention to the
lines in bold face:<br />
<br />
eth1 Link encap:Ethernet HWaddr 00:0c:29:8b:bb:ca<br />
inet6 addr: fe80::20c:29ff:fe8b:bbca/64 Scope:Link<br />
<b> UP BROADCAST RUNNING NOARP PROMISC</b> MTU:1500 Metric:1</div>
<div>
<br /></div>
<div>
The most important lines above are UP RUNNING PROMISC, because the interface must be up, must be running, and likely should be in promiscuous mode to pick up traffic. the NOARP line isn't entirely necessary, but it's there to ensure that the sniffing interface doesn't respond to arp queries in case attackers are probing the network to try and find your IDS installations.</div>
<div>
<br /></div>
<b>3)
How are you passing traffic to snort? is snort's sniffing interface
attached to a switch span? a hub? a network tap? if it's a virtual
machine on ESXi or something of that nature, is the vswitch snort is
sniffing off of configured to allow promiscuous mode network cards?</b><br />
<b><br />
</b><br />
If you're in a corporate environment, and are a proficient network administrator, I'm going to assume you know what a switch span port is. These are also referred to as mirror ports. Most professional grade switches have an option to copy ALL traffic seen on a switch to a single interface. You would plug snort's sniffing interface into this mirror interface for snort to see traffic for that entire network segment.<br />
<br />
If you're a security reasearcher and don't have money for a procurve or cisco switch that does port mirroring, here's some awesome alternatives:<br />
<br />
http://routerboard.com/RB260GS<br />
<br />
This is a 5-port switch from microtik. Very very affordable and capable of port mirroring.<br />
<br />
Alternatively, if you want a bigger name-brand switch, I personally use netgear's GS108T switch for my home network, since it was the cheapest switch I was aware at the time that allowed port mirroring:<br />
<br />
http://www.newegg.com/Product/Product.aspx?Item=33-122-381&IsVirtualParent=1<br />
<br />
An alternative to span/mirror ports are network taps. On the professional/corporate side, Net Optics, Gigamon and several other vendors offer network tap solutions. Often ridiculously priced, but without all of the possible problems that come with setting of span/mirror ports. These devices are solely dedicated to creating exact clones of network traffic passing over the wire and nothing else.<br />
<br />
For those on the cheap side, there are several results via google on how to make your own network tap, but be aware that these sorts of taps are usually for 10/100 networks and usually do not support tapping gigabit networks.<br />
<br />
Finally for vmware environments, I posted a specialized tutorial on how to "hack" vmware player on how to bridge traffic from one physical interface or another, using the vmnetconfig.exe from vmware workstation (check the pdf document available in my autosnort github if you're interested...)<br />
<br />
But for professional deployments or network labs running vmware ESX/ESXi, it's pretty easy to configure a vswitch to allow promiscuous mode nics. That's really all you have to do is change vswitch security settings, allow promiscuous mode NICs and just configure the snort VM to sniff off of that vswitch.<br />
<br />
<br />
<b>4) run tcpdump on snort's sniffing interface:</b> <br />
<br />
tcpdump -i ethX not arp and not port 22<br />
<br />
X
is the ethernet interface number snort is sniffing traffic on. the "not
arp and not port 22" is telling tcpdump to ignore ssh traffic and arp
broadcasts.<br />
<br />
<div>
while tcpdump is running, on another system on the network, try doing something to generate network traffic (ping <a href="http://google.com/" target="_blank">google.com</a>,
go to a web page, etc.). did tcpdump see your traffic? If not, you may
need to investigate how you're mirroring traffic to snort.<br />
<br />
<div>
<b>5) Check and see if the snort.u2 file is greater than 0 bytes:</b></div>
<div>
ls -al /var/log/snort</div>
<div>
check the output of the ls command. You're looking for the snort.u2 file, it should look something like this:<br />
<br />
-rw------- 1 snort snort 67261 May 19 17:39 snort.u2.1368917933<br />
</div>
the
numbr "67261" in the middle is the file's size. If your snort.u2 file
is 0 bytes, that means snort hasn't generated any alerts.<br />
</div>
<div>
So those are the basic steps. You confirm that snort is
running, confirm that the interface is in promisc mode, and confirm that
mirroring device is actually pushing traffic to where snort can see it, and confirm snort is logging events.</div>
<div>
<br /></div>
<div>
<b>Snorby-specific troubleshooting steps:</b></div>
<div>
Here's a couple of things you can
try to confirm that barnyard2 and snorby are working together:<br />
<br />
<b>1) ps -ef | grep delayed</b></div>
<div>
- You are looking for an entry that looks something like this:<br />
<br />
root 2161 1 0 May18 ? 00:11:00 delayed_job</div>
<div>
if the delayed_job process is NOT running, run this command:<br />
<br />
cd /var/www/snorby && ruby script/delayed_job start</div>
<div>
then run this command to see if the sensor_cache needs to be updated:<br />
<br />
cd /var/www/snorby && rails runner 'Snorby::Jobs::SensorCacheJob.<wbr></wbr>new(false).perform; Snorby::Jobs::DailyCacheJob.<wbr></wbr>new(false).perform'</div>
<div>
note: I do not know if you need root permission to run
the commands above, but if the above commands fail without root
privileges, run the command:<br />
sudo su -</div>
<div>
to get a shell with root privileges and re-run those commands.</div>
<div>
<br /></div>
<div>
<b>2) you'll want to check the contents of barnyard2.conf and snorby's database.yml to make sure they match:</b><br />
</div>
<div>
cat /usr/local/snort/etc/<wbr></wbr>barnyard2.conf<br />
</div>
<div>
<b>on the log mysql line, check these values and make sure they match:</b><br />
</div>
log,mysql, user=snort password=[password you gave the snort database user] dbname=snorby host=localhost<br />
<br />
cat /var/www/snorby/config/database.yml<br />
<br />
<b>verify these lines in database.yml:</b><br />
<br />
snorby: &snorby<br />
adapter: mysql<br />
username: snort<br />
password: [same password in the barnyard2.conf file]<br />
host: localhost<br />
<br />
development:<br />
database: snorby<br />
<<: *snorby<br />
<br />
test:<br />
database: snorby<br />
<<: *snorby<br />
<br />
production:<br />
database: snorby<br />
<<: *snorby<br />
<br />
the
most important lines to check are the dbname: and database: line under
production are the same database, and that the password= and password:
lines are the same to make sure that barnyard2 and snorby agree on the correct password to use to log to and read from that same database.<br />
<br />
If the
database lines and password lines match, at the very least, we know that
barnyard2 and snorby are talking to the right database.<br />
<br />
<b>3)
One last check you can perform is to verify that the snort user has the
privileges to talk to the snorby database. run this command:</b><br />
<br />
mysql -usnort -p[snort database user's password, no spaces] snorby -e "show tables;"<br />
<br />
<div>
<b>your output should look like this:</b><br />
<br />
+-------------------+<br />
| Tables_in_snorby |<br />
+-------------------+<br />
| agent_asset_names |<br />
| aggregated_events |<br />
| asset_names |<br />
| caches |<br />
| classifications |<br />
| data |<br />
| delayed_jobs |<br />
| detail |<br />
| encoding |<br />
| event |<br />
| events_with_join |<br />
| favorites |<br />
| icmphdr |<br />
| iphdr |<br />
| lookups |<br />
| notes |<br />
| notifications |<br />
| opt |<br />
| reference |<br />
| reference_system |<br />
| schema |<br />
| search |<br />
| sensor |<br />
| settings |<br />
| severities |<br />
| sig_class |<br />
| sig_reference |<br />
| signature |<br />
| tcphdr |<br />
| udphdr |<br />
| users |<br />
+-------------------+</div>
<div>
This confirms that the snorby database exists and that the schema was configured properly during installation.<br />
<b><br /></b></div>
<div>
<b>4) If the snort.u2 file in /var/log/snort is
NOT 0 bytes, and you confirmed the snort database user was able to see
the tables in the snorby database, there's one last set of commands you
can run:</b><br />
</div>
<div>
mysql -usnort -p[snort database user's password] snorby -e "select * from event\G;"<br />
</div>
<div>
if
you get "empty set" as the return value from that command, snorby
doesn't have anything. If you get a bunch of data from this command,
snorby should have events in the "events" tab on the web interface.<br />
</div>
<div>
you can also run this command:<br />
</div>
<div>
mysql -usnort -p[snort database user's password] snorby -e "select count(*) from event;"<br />
</div>
<div>
you should get something like this:<br />
<br />
+----------+<br />
| count(*) |<br />
+----------+<br />
| 5284 |<br />
+----------+<br />
</div>
I
have a boatload of events, because I have a testing suite that causes
snort to trigger alerts like crazy, but basically, you're looking for
the count number to NOT be 0. If the count is 0 there's no events for
snorby to report on.<br />
<br />
<br />
Hope this helps you all out<br />
<br />
Cheers,<br />
<br />
DA_667 da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-85463478566914136072013-05-19T14:45:00.000-07:002013-05-19T14:56:54.969-07:00Autosnorby Follow-up: Support to Debian officially released, distributed installations under testing.Hello again,<br />
<br />
As I had mentioned a few blog posts ago updates to autosnort and/or support for snorby were probably going to be staggered out across platforms, since I have to do testing to ensure that things aren't horribly broken on release, that I have the right packages for the right platform that puts the right stuff in the right place, etc.<br />
<br />
That being said, porting over the changes to autosnort and support for snorby to Debian went fast. Like, really fast. I should have figured this would be the case since Ubuntu and Debian share similarity in packages installed and package management utilized. It was almost quite literally a copy/paste job -- copy the code from ubuntu autosnort and it its child shell scripts, integrate it in with debian's existing scripts (and some custom things that Debian needs to work right) and just test it to make sure nothing exploded in a fit of errors and incompatibility.<br />
<br />
Therefore, it brings me great pleasure to release a new version of autosnort for Debian as well as a snorby child shell script for Debian-based systems, and code improvements to debian autosnort and child shell scripts.<br />
<br />
I'm not going to bother going over all of the changes I made to the script(s), since more or less the changes are practically identical to the ubuntu/autosnorby post I made yesterday (e.g. code cleanup, doing things that make sense to make the code easier to manage, installing relevant packages only when they are needed for a particular interface/function, etc.) except to note that I fixed a small bug in the remote database/experimental distributed sensor installation support (In both Ubuntu and Debian)<br />
<br />
Speaking of the distributed installation support, I have a rough guide to doing a distributed install. This is very, very rough right now, expect some official or at least "better" guidance soon:<br />
<br />
1. Perform a standard autosnort install on your "master console" system, and choose the interface you wish to install. Bear in mind that aanval requires licensing to support more than one snort sensor, and that snort report doesn't really clearly delinate which sensor an event came from. Reboot.<br />
<br />
2. Edit /etc/mysql/my.cnf and reconfigure mysql to accept connections globally (e.g. listen on 0.0.0.0; also note that you'd better have a security measure of some sort up to limit connections to your other sensors (e.g. a firewall) if you plan on having this system accessible in *any* way over the internet)<br />
<br />
3. run mysql -uroot -p[password here]<br />
<pre>GRANT ALL ON snort.* TO snort@'1.2.3.4' IDENTIFIED BY 'my_password'; </pre>
<br />
snort@'1.2.3.4' should be the snort database user on the remote sensor you plan to have store events on your master console, likewise the IDENTIFIED BY 'my_password'; should be the password you place into barnyard2.conf to talk to the master console.<br />
<br />
4. Run the autosnort installer on your barebones sensor (choose option 2 to NOT install apache or mysql), somewhere down the line, the script will ask if you have a remote database that barnyard2 will be logging into. Enter the username (snort), the remote database name (snort), the remote database ip (e.g. the management interface for your 'master console' sensor), and the password you entered above on the mysql statement on the master console<br />
<br />
5. finish the autosnort install (when it gets to the what interface do you want to install phase, just select option 6 for no interface at all.)<br />
<br />
6. On the barebones sensor, install mysql-client (apt: apt-get install mysql-client) and try to connect to the database on the master console:<br />
<br />
mysql -uroot -psnort -h [master console ip address]<br />
use snort;<br />
show tables;<br />
<br />
If you get output, and a list of database tables, that's a very good sign. Otherwise you have some troubleshooting to do. note that by default autosnort installs libmysqlclient to allow barnyard2 to talk to the remote database, however, I'm having you install mysql-client in the event you want to troubleshoot and verify that you can talk to the database as a regular user. libmysqlclient won't let you test things out with manual queries, etc.<br />
<br />
I can't re-iterate this enough, but allowing mysql to listen globally opens up some security risks (which is why I've trying to move to having the traffic SSL wrapped and tunneled between sensors/consoles...), so I would most definitely make sure the network your barebone sensor and master consoles are talking over is protected, trusted, and your master console host is firewalled to hell and back, only allowing 3306/tcp connections from your barebone sensors. Know the risks before you take this leap.<br />
<br />
Check out the autosnort github and happy snorting!<br />
<br />
Cheers,<br />
<br />
DA_667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com2tag:blogger.com,1999:blog-7331752786831922328.post-89039596972262780852013-05-18T22:27:00.000-07:002013-05-19T07:55:12.956-07:00Autosnorby, updates to autosnort, and the updated to-do listHello Snort and Autosnort users.<br />
<br />
I've got a lot to talk about today, so let's get started.<br />
<br />
First and foremost, I've finally managed to work in support for snorby into autosnort. The snorby script installs the necessary packages, a compatible version of ruby (via rvm), all the necessary gems and configures the right files with the right info needed to get snorby up and running. Additionally, I've managed to work out away to drop privileges from the root database user to another user (the snort user in our case)<br />
<br />
One thing to be aware of: the delayed_job and the sensor cache jobs do NOT start up on boot. Initial runs of the script had me trying to put commands into rc.local to start the delayed_job and sensorcachejob commands on startup... but they aren't working. I'm working on having a reliable method to start them on boot, but until that is discovered, any time the system is restarted, you'll want to, at a minimum start the delayed_job script:<br />
<br />
cd /var/www/snorby && ruby script/delayed_job start<br />
<br />
optionally, these commands run the Sensor and Daily cachejobs as well:<br />
<br />
cd /var/www/snorby && rails runner 'Snorby::Jobs::SensorCacheJob.new(false).perform; Snorby::Jobs::DailyCacheJob.new(false).perform'<br />
<br />
There are options to start the snorby worker process via the web UI, but I find the direct approach to my liking.<br />
<br />
Another note is that at first you may notice alerts coming in and displaying properly in the events tab, but the dashboard may not updated at first. If this is the case, on the dashboard page, there is an option to force cache update. Select this option, wait 10 seconds, and reload the page. the graphs should update.<br />
<br />
Next up on the list, is the main autosnort script itself. I've done a bit of spring cleaning.<br />
<br />
- I've reduced the number of packages installed by default with autosnort.<br />
--By default all we install are the packages necessary to install daq, libdnet, snort, and barnyard 2 with the ability to write to a remote database (more on this in a minute)<br />
--I introduced a quick check that asks the user if they plan on installing a web interface as a part of the autosnort installation, or if they just want a stripped-down barebones install. If you're not sure what option to pick, select option 1.<br />
<br />
- I've added a couple of functions to the script near the beginning for pulled pork to facilitate code re-use. this is because:<br />
<br />
-- I've added support to download snort rules from previous versions of snort; up to four versions prior.<br />
<br />
Why: I ran into a little problem recently where the free rules for version 2.9.4.5 were not available yet, and snort version 2.9.4.6 had just came out. The current version of the script only checks for the current version of snort rules, and one version prior. So now, you have a choice for four versions of rules:<br />
<br />
1) the current version (if you have a VRT subscription oink code; e.g. 2.9.4.6)<br />
2) the previous version (the kind that registered users usually get access to; e.g. 2.9.4.5)<br />
3) two more prior versions (in the event that they are needed and/or a similar situation arises)<br />
<br />
- If the user has elected to not install a web interface, the script asks them if they have a remote database they want barnyard to log to. I haven't officially tested this feature yet, but theorhetically, this allows for distributed installations... Any volunteers to test this? :)<br />
<br />
- The child shell scripts all have functionality to install the packages necessary for them to work individually Again to reduce clutter and excess packages installed by autosnort (e.g. reduce attack surface)<br />
<br />
- thanks to DK1844, I have a couple of code cleaniness fixes that I have added, and future todo list items.<br />
<br />
I've achieved most of the stuff I intended to do when I initially started this little project, but I still have more that I can do. <br />
<br />
Speaking of to-do list items:<br />
<br />
- SSL for all web interfaces (generate a default, self-signed SSL cert, use mod-rewrite and mod-ssl to force ssl usage for all web interfaces)<br />
- Further testing with distributed installations (Can I get a master console to register events from a remote system?)<br />
- Encrypted comms between master console and remote sensor (e.g. have barnyard dump database updates to the master console over a secure channel) <br />
- Kali Linux testing! Since Kali is fully compliant with Debian standards, will the debian autosnort script work with it?<br />
<br />
<br />
The updates to autosnort.sh, snorby, aanval, snortreport and base child shell scripts are being pushed to ubuntu tonight, with support for other operating systems (debian and centOS) to come soon.<br />
<br />
Report bugs, problems, praise, feature requests, etc. to:<br />
<br />
deusexmachina667 [at] gmail [dot] com<br />
<br />
As always the code is on my <a href="https://github.com/da667/Autosnort">github repo</a>.<br />
<br />
Happy snorting,<br />
<br />
DA_667<br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-85279281418050016732013-05-13T13:34:00.002-07:002013-05-13T13:34:18.757-07:00Another quick post - fix to aanval installer scriptHello AS users,<br />
<br />
A recent message from an Autosnort user, sm00th brought a problem to my attention regarding the aanval installer script. I've discovered that there is a problem with the wget command used to download the aanval installer. This is what happens when I attempt to wget the file manually:<br />
<br />
root@CG:~# wget https://www.aanval.com/download/pickup -O aanval.tar.gz<br />--2013-05-13 16:13:59-- https://www.aanval.com/download/pickup<br />Resolving www.aanval.com (www.aanval.com)... 173.160.180.147<br />Connecting to www.aanval.com (www.aanval.com)|173.160.180.147|:443... connected.<br />ERROR: no certificate subject alternative name matches<br /> requested host name `www.aanval.com'.<br />To connect to www.aanval.com insecurely, use `--no-check-certificate'.<br /><br />
There is some sort of a certificate problem with aanval.com. The wget command says to try using --no-check-certificate:<br />
<br />
root@CG:~# wget https://www.aanval.com/download/pickup -O aanval.tar.gz --no-check-certificate<br />--2013-05-13 16:14:27-- https://www.aanval.com/download/pickup<br />Resolving www.aanval.com (www.aanval.com)... 173.160.180.147<br />Connecting to www.aanval.com (www.aanval.com)|173.160.180.147|:443... connected.<br />WARNING: no certificate subject alternative name matches<br /> requested host name `www.aanval.com'.<br />HTTP request sent, awaiting response... 200 OK<br />Length: 6703589 (6.4M) [application/octet-stream]<br />Saving to: `aanval.tar.gz'<br /><br />100%[=========================================================================================================================================================>] 6,703,589 586K/s in 12s<br /><br />2013-05-13 16:14:40 (529 KB/s) - `aanval.tar.gz' saved [6703589/6703589]<br /><br />root@CG:~# echo $?<br />0<br />
<br />
good news: This allows you to pick up the tarball for installing aanval<br />
bad news: The certificate for aanval.com isn't being checked -- this means we're still using SSL to connect to aanval.com and pick up the package, but we aren't checking the certificate to see who signed it, and/or what site it was signed for.<br />
<br />
Unfortnately, the problem is out of my hands. I submitted a quick fix to github.com that adds the --no-check-certificate option to allow us to fix the package.<br />
<br />
Regards,<br />
<br />
DA_667<br />
<br />
p.s. Yes, I'm still working on snorby. Hit a bit of a road bump. I thought I had the full installation down, and now, for some reason the snorby database refuses to update. at all. So, as I said before, I want to run through the entire snorby installation process without a single error. Once I can do that... I'll release the Ubuntu snorby script, then Debian, Then probably CentOS last.<br />
<br />
Cheers! <br />
<br />
<br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-62934396750580824082013-05-05T19:52:00.001-07:002013-05-05T19:56:59.989-07:00Snorby script progress, and a rundown of how to perform the installation.Hello Autosnort users,<br />
<br />
Still working on the Snorby release for Autosnort, and even then, It's probably going to be a staggered release -- first Ubuntu, then Debian, and Finally moving to CentOS. I imagine that based on some of the issues I have been experiencing, Getting Snorby to play with with SELinux is going to be a lot of fun.<br />
<br />
I managed to get it to work with Aanval, snortreport and BASE, so I can do it again.<br />
<br />
Anyhow, for those of you who can't wait for me to release a script, here's a basic run-down of the commands I'm running in Ubuntu 12.04 that I've used that work. this assumes you've ran autosnort up to the point where web interface installation takes place.<br />
<br />
Don't be alarmed when it says you're downloading 400m of packages. that's about right:<br />
<br />
apt-get install libyaml-dev git-core imagemagick libmagickwand-dev wkhtmltopdf libssl-dev libxslt1-dev libsqlite3-dev libmysql++-dev libcurl4-openssl-dev apache2-prefork-dev default-jre-headless<br />
<br />
this installs rvm. rvm is a nice little program that can be used to automatically install ruby:<br />
<br />
\curl -\#L https://get.rvm.io | sudo bash -s stable<br />
/usr/local/rvm/bin/rvm autolibs enable<br />
source /etc/profile.d/rvm.sh <br />
<br />
this is a cute little hack that I've used for installing the latest stable version of snort, DAQ, and determine what version of snort rules are available via snort.org. From what I gather ruby updates frequently. very, very frequently. This string of commands tells us the latest ruby 1.9.x release available for installation. Why not install ruby 2.0.0? because snorby doesn't support it yet. Submitted an issue to snorby's github. We'll see where that takes us:<br />
<br />
wget http://ruby-lang.org/en/index.html -O /tmp/index.html<br />
rubyver=`cat /tmp/index.html | grep -e "ruby-" | head -4 | grep released | grep -v Continue | cut -d"/" -f8 | cut -d" " -f2 | tail -1`<br />
rvm install ruby-$rubyver<br />
<br />
After all the packages you need to install, there's also a boatload of gems that need installation. and oh, we haven't pulled down the snorby web UI yet:<br />
<br />
gem install thor i18n bundler tzinfo builder memcache-client rack rack-test rack-mount rails rake rubygems-update erubis mail text-format sqlite3 daemon_controller<br />
gem install passenger<br />
update_rubygems<br />
cd /var/www/<br />
git clone http://github.com/Snorby/snorby.git<br />
cd snorby/config<br />
<br />
Make copies of database.yml.example and snorby_config.yml.example and rename them to database.yml and snorby_config.yml:<br />
<br />
cp database.yml.example database.yml <br />
cp snorby_config.yml.example snorby_config.yml <br />
<br />
modify snorby_config.yml. this should be the only change that needs to be made:<br />
sed -i 's/usr\/local\/bin/usr\/bin/' snorby_config.yml<br />
<br />
modify database.yml the snorby section at the top, you MUST enter the root database user's password. this is necessary for the rake snorby:setup portion<br />
<br />
Next, we have to compile the mod_passenger apache module. this will take a little bit of time.<br />
passenger-install-apache2-module<br />
<br />
If the passenger-install command above bombs, try running "gem install passenger --pre" and running the command again.<br />
<br />
The passenger-install command will ask you to modify a couple of files. First we have to point apache to the passenger module:<br />
<br />
echo "" >> /etc/apache2/apache2.conf<br />
echo "# This stuff is to make Snorby work properly mod_passenger is required for snorby to work." >> /etc/apache2/apache2.conf<br />
echo "" >> /etc/apache2/apache2.conf<br />
echo "LoadModule passenger_module /usr/local/rvm/gems/ruby-$rubyver/gems/passenger-4.0.0.rc6/libout/apache2/mod_passenger.so" >> /etc/apache2/apache2.conf<br />
echo "PassengerRoot /usr/local/rvm/gems/ruby-$rubyver/gems/passenger-4.0.0.rc6" >> /etc/apache2/apache2.conf<br />
echo "PassengerDefaultRuby /usr/local/rvm/wrappers/ruby-$rubyver/ruby" >> /etc/apache2/apache2.conf<br />
<br />
Next, we create a virtualhost for snorby and set the documentroot to snorby's public directory, then disable the default site. This effect means that if you navigate to http://[ip address] you automatically get the index page for snorby:<br />
<br />
echo "<VirtualHost *:80>" >> /etc/apache2/sites-available/snorby<br />
echo " ServerName snorby.localhost" >> /etc/apache2/sites-available/snorby<br />
echo " # !!! Be sure to point DocumentRoot to 'public'!" >> /etc/apache2/sites-available/snorby<br />
echo " DocumentRoot /var/www/snorby/public" >> /etc/apache2/sites-available/snorby<br />
echo " <Directory /var/www/snorby/public>" >> /etc/apache2/sites-available/snorby<br />
echo " # This relaxes Apache security settings." >> /etc/apache2/sites-available/snorby<br />
echo " AllowOverride all" >> /etc/apache2/sites-available/snorby<br />
echo " # MultiViews must be turned off." >> /etc/apache2/sites-available/snorby<br />
echo " Options -MultiViews" >> /etc/apache2/sites-available/snorby<br />
echo " </Directory>" >> /etc/apache2/sites-available/snorby<br />
echo "</VirtualHost>" >> /etc/apache2/sites-available/snorby<br />
<br />
<br />
<br />
<br />
<br />
All this has just been setup so we can successfully run bundler and rake to actually install snorby:<br />
<br />
cd /var/www/snorby<br />
<br />
bundle install --deployment<br />
<br />
note: if the bundle install command fails or gives you an error referencing to the gemlock file or a gem called psych shield, you may have to run "bundle install --no-deployment" then run "bundle install --deployment" for things to work right.<br />
<br />
finally, the moment you've been waiting for...:<br />
<br />
rake snorby:setup<br />
<br />
note: do not try to create the snorby database prior to running rake snorby:setup. If the database already exists, rake will bomb and exit.<br />
<br />
At this point, provided rake snorby:setup ran, you should have a web interface that you can log into. default creds for snorby are: snorby@snorby.org with a password of snorby.<br />
<br />
If you reboot your sensor, the worker jobs and the delayed_run jobs, processes necessary for populating the dashboard on the web UI do not automatically start with the system. You need to run these commands on reboot: <br />
<br />
cd /var/www/snorby && ruby script/delayed_job start<br />
cd /var/www/snorby && rails runner 'Snorby::Jobs::SensorCacheJob.new(false).perform; Snorby::Jobs::DailyCacheJob.new(false).perform'<br />
<br />
What I am working on:<br />
- Every time I've ran the installation, I've varied one thing (e.g. the first time through I tried installing with ruby 2.0.0, the second time around, I installed and found out daemon_controller was a needed gem that no install guide referenced, the third time around I tried installing by creating the snorby database and granting the snort database user access to the database. This is also when I encountered the problem with bundler complaining about the gemlock file and the psych shield gem and had to re-run bundler with the --no-deployment option.<br />
<br />
I need to re-run the installation until I get absolutely zero errors. I want this fully repeatable with no errors.<br />
I want to investigate the possibility of editing the database.yml post-installation: using the snort database user, and using mysql commands to grant the necessary privs to the snort mysql user instead of root. Having the root mysql user's privs in plaintext in a file that's world readable by default sounds like a terrible idea to me.<br />
<br />
possibly adding the delayed_job and SensorCacheJob commands to rc.local to ensure they are ran upon reboot.<br />
<br />
Getting support for Snorby is my highest priority right now. After that is done, I have some efficiencies and changes to autosnort I'll talk about in another post. Until then,<br />
<br />
Cheers from DA. <br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com5tag:blogger.com,1999:blog-7331752786831922328.post-47046351324297463702013-05-01T18:29:00.002-07:002013-05-03T11:46:15.648-07:00Short and SweetAutosnort users,<br />
<br />
Two things to be aware of:<br />
<br />
1) the pulledpork auto rule download functionality appears to be broken right now. This is due to a lack of forethought on my part on believing that there wouldn't be less than 30 days between two versions of snort being released. Working on fixing this as we speak.<br />
<br />
2) I'm working pretty hard on automating installation of Snorby. Snorby is an ambitious project and a beautiful web interface, but the Documentation hasn't seen updates in over a year, and things that should be simple now have Ruby, rails and all the dependency hell that comes with it. It's coming together, slowly but surely.<br />
<br />
Until next time.<br />
<br />
Update: yesterday evening the snort 2.9.4.5 rules were made available to registered users. This sort of invalidates the fix I'm putting into autosnort, but I'm still going to do it to prevent this from happening again. Also still working on a snorby script. da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-4286357249325849942013-04-21T16:27:00.001-07:002013-04-21T16:28:06.905-07:00Sometimes the old ways are the best ways (support for BASE and Syslog_Full output)Hello AS/snort users,<br />
<br />
Got two new features in this latest build of autosnort.<br />
<br />
First and foremost is support for the BASE web interface. BASE is by and far one of the older and more well-known web interfaces for snort alerting. While the interface isn't going to win for prettiest interface, it is by and far very functional. Some of the cool things include the ability to download alerts as pcap and actual tshark/pcap parsed output for each alert.<br />
<br />
This has been added as an installation option in the interface selection menu. The installation is painless and straight forward. After the system reboots, just point your browser to http://[your ip]/base.<br />
<br />
The web page initial setup will check for all of the required pre-requisite settings on the first page. On the second page, it will ask you where adodb, a pre-requisite package, is installed. Autosnort and most linux distros install adodb to /usr/share/php/adodb (put that in for the path to adodb). It will also, of course ask you for database information and credentials:<br />
database name: snort<br />
database host: localhost<br />
database port: 3306 (can leave blank if you'd like)<br />
database username: snort<br />
password: (the snort database user's password)<br />
<br />
Unless you have an archive database configured, leave that part blank.<br />
On the last page, it will ask if you want to set up auth to get into the web page to review events. That is entirely up to you.<br />
<br />
After that, you should be all set to get events to the BASE web interface.<br />
<br />
The next feature I have to announce is support for syslog output as another output interface choice. I've added a child script that configures barnyard2 to output to syslog_full format to port 514/udp. I have not FULLY tested this feature, but preliminary tests show that splunk picks up and parses the events with no issues whatsoever. A couple of troubleshooting recommendations:<br />
<br />
-Ensure that the sensor's management interface, if it is firewalled, has port 514/udp open and allowed outbound.<br />
-Conversely, ensure that your SIEM or syslog aggregator has port 514/udp open inbound to accept events -- I hosted splunk on a CentOS box and was puzzled why tcpdump says we were sending events out, but they were never making it to be indexed by splunk. I ran system-config-firewall-tui and added a rule for 514/udp inbound (and port 8000/tcp inbound for the actual web UI), and everything was fine.<br />
<br />
The child scripts have been made available to Debian, Ubuntu and CentOS.<br />
<br />
One last thing:<br />
<br />
I've made some minor changes to the script at the recommendation of maintainer of the barnyard2 project. Instead of using sed to modify the copy of barnyard2.conf included with the barnyard2 source, I'm making the script generate a barnyard.conf on-the-fly.<br />
<br />
- the script keeps a copy of the original barnyard2.conf in /usr/local/snort/etc/ named barnyard2.conf.origin<br />
- the script generates a barnyard2.conf with only the directives necessary to run barnyard2 (e.g. where are the reference and classification config files, the gen/sid-msg.map files, input format to accept, output format to output to, etc.)<br />
- if you choose to configure output to syslog format, the child script disables output to the database automatically.<br />
<br />
As always, the scripts are up on github, along with updated READMEs. Previous versions are available in the Previous_Rel directory as well.<br />
<br />
Happy Hunting..<br />
<br />
DA_667<br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-53472378180865581062013-04-13T23:32:00.001-07:002013-04-13T23:33:37.477-07:00New AS release, New init scripts, bug fixes and more!Hello AS users,<br />
<br />
Got a lot to talk about today, so let's get down to business:<br />
<br />
First and foremost I've finally gotten around to writing half-decent documentation for autosnort. I've pushed a pdf file to github featuring documentation with screenshots on how to install Autosnort via vmware player, including an interesting hack on how to get bridging to work on multiple interfaces on vmware player 5.<br />
<br />
I chose CentOS as the vmware player operating system, but the instructions should be easy to follow for Debian Ubuntu or Backtrack. Any major differences were noted. All said and done it was about 23 pages of documentation with screenshots peppered in.<br />
<br />
I focused on using VMware player this time around, and generally speaking the VMware player guidance can be used just as well for VMware Fusion or Workstation. I may do an alternate document for ESXi and/or Virtualbox in the near future.<br />
<br />
I've also included general troubleshooting steps and things you *should* see after running autosnort.<br />
<br />
Next in line is an update to the autosnort script for Debian, Ubuntu, and CentOS. Banyard2.13 BETA2 has changed how barnyard2 behaves. As a result of this, I had to change how arguments are passed to barnyard2 in Autosnort. The details are available for each operating system's readme files. Suffice to say, everything works fine now.<br />
<br />
Finally, I've gotten around to testing and posting init scripts for Ubuntu and Debian to control snort and barnyard2. The Ubuntu and Debian init scripts support start, stop and restart functions and are pretty easy to implement. Implemtation details are also available via the Readme files for Ubuntu and Debian Autosnort scripts, but suffice to say, its incredibly easy.<br />
<br />
I may release a modification to the init script that detects if you installed aanval and automatically start/stop the BPUs along with snort and barnyard2, but that will come a little later.<br />
<br />
The documentation, new scripts, readmes and init scripts should all be available via github as of now.<br />
<br />
Cheers,<br />
<br />
DAda_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com3tag:blogger.com,1999:blog-7331752786831922328.post-51420199406284061942013-03-31T15:27:00.000-07:002013-03-31T15:28:09.736-07:00Redhat/CentOS init script!Hello AS and regular snort users,<br />
<br />
I wanted to announce that I have developed an init script compatible with CentOS/Redhat variants for autosnort installations (of course, this script can easily be adapted to other snort snort installations. <br />
<br />
This init script can be used to replace /etc/rc.local as the primary method of starting up snort and barnyard2, and includes the added bonus of allow you to start/stop/restart snort and barnyard2 without requiring a reboot or sourcing /etc/rc.local if you need to make changes to snort or barnyard2. To add this script to CentOS 6.x perform the following tasks as root (or via sudo/root permissions):<br />
<br />
1. Copy the snortbarn script to /etc/init.d<br />
2. Edit the variables near the top of the script to suit your snort installation (the only variable that you should need to modify is the snort_iface variable if you installed snort/barnyard2 via autosnort)<br />
3. Make the snortbarn script is executable for the root user (chmod 700 snortbarn)<br />
4. Run chkconfig --add snortbarn<br />
5. Remove the entries for ifconfig, snort, and barnyard2 from /etc/rc.local (note: you may want to make a backup of the rc.local script in case you run into bugs/problems with the init script!)<br />
6. Kill your current snort/barnyard processes that ran from rc.local (killall snort && killall barnyard2)<br />
7. Run the command "service snortbarn start"<br />
8. check the process list to ensure that snort and barnyard2 are running after calling the init script. ( "ps -ef | grep snort" will return snort and barnyard2, if either/both processes are running. If only one process or the other is visible, something is wrong)<br />
<br />
Troubleshooting steps: I'm not entirely sure why but there are CRLF/LF formatting problems with this script. If you get a bunch of errors stating that a file/command doesn't exist, try running dos2unix on the file to resolve the CRLF/LF errors.<br />
<br />
If you install the init script and upon reboot find that only the snort process is running, it is because the init script for snortbarn ran BEFORE the init script for mysqld ran. To Determine when mysqld is configured to run it its runlevels, check /etc/init.d/mysqld. You'll want to pay attention to this line in particular:<br />
<br />
# chkconfig: - 64 36<br />
the first number, 64 indicates what number the rc startup script will get on startup. Linux rc scripts determine what services run or are killed on a particular run level. Every rc script as a K for Kill order, an S for Start order, followed by a number and the name of the symlinked script from /etc/init.d. RC scripts are read in numeric order. So if the rc script for snortbarn has an S number lower than 64, it will run before mysqld. snort will start up fine, but barnyard fails because it has no database to connect to.<br />
<br />
To remedy this, you can modify the /etc/init.d/mysqld script to have a lower number than the snortbarn script in any of the /etc/rc[2-5].d directories, or modify the snortbarn script to have a higher number than the mysqld directory. This is a little confusing, so let's look at an example:<br />
<br />
run this command: ls -al /etc/rc?.d/S*snortbarn<br />
<br />
this command shows you each runlevel snortbarn is configured to start on.<br />
<br />
now, run this command: ls -al /etc/rc?.d/S*mysqld<br />
<br />
this command shows you the runlevels mysqld is set to run on. Don't worry about how many results you get.<br />
<br />
If mysqld's number is higher than snortbarn's number, the mysqld process will not be running before snort and barnyard are configured to run. No database running means barnyard2 won't run. Let's say snortbarn had a number of 63, and mysqld has a number of 64. edit /etc/init.d/mysqld and change the chkconfig to something like this:<br />
<br />
# chkconfig: - 62 36<br />
<br />
save your changes and run chkconfig --add mysqld. This should fix the problem. <br />
<br />
I've added the above documention to the other notes section of the CentOS readme. The snortbarn script is now available via github. <br />
<br />
Special Note: Would like to thank Tactical FLEX/Aanval for hosting the initial version of this init script that I based this one off of. Would also like to thank Mike Miller for the initial idea of moving away from rc.local and building out a legitimate init script for autosnort.<br />
<br />
Happy Snorting,<br />
<br />
DA667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-21479750645661223012013-03-30T19:49:00.000-07:002013-03-30T19:50:37.146-07:00Hammering out AanvalHello Autosnort Users,<br />
<br />
Today I would like to announce support for Tactical Flex's Aanval Web Console on CentOS and Debian platforms in addition to last weekend's Ubuntu release<br />
<br />
I've implemented the same changes for the CentOS and Debian scripts that I've implemented on the Ubuntu script, namely the modularization of autosnort, starting with the web interface choices snortreport and aanval.<br />
<br />
I've updated the readme files in each operating system's directory to more of a "release notes" format, that will be easier to read and follow. <br />
<br />
One issue that I'd like to write about that I encountered while working on getting Aanval running on CentOS in particular is SELinux. Most people see SELinux as an annoying hindrance that keeps them from getting done what they want to get done. I use to be one of those people as well. But with a little bit of research, most problems with SELinux can be resolved easily, without disabling it or setting it to permissive mode (making it essentially useless).<br />
<br />
I ran into a problem during aanval installation where it failed to connect to the mysql database on localhost with the creds I gave it. Thinking I fat-fingered the creds, I did it again and it immediately failed again.<br />
<br />
At this point, I check the logs. Nothing interesting in /var/log/messages or the httpd error_logs, so I move to the audit log. For those of you who are not aware, SELinux usually logs to /var/log/audit/audit.log. It's log format is pretty strange, but its easy enough to pick out the relevant pieces to determine if SELinux is interfering with what you you need your system to do. run tail -f on audit.log and try entering the database credentials again and an entry pops up for SELinux, denying access to 3306/tcp for the httpd process. I do a google search for a small portion of the audit log message, and immediately get a relevant result. Long story short, run this command:<br />
<br />
<code>setsebool -P httpd_can_network_connect_db 1</code> <br />
<br />
This explicitly states to SELinux that the httpd process requesting connections to the database/database port are perfectly fine. Always remember: disabling SELinux is NEVER the answer.<br />
<br />
Happy Easter and Happy Snorting,<br />
<br />
DA667da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-7238453688318803622013-03-17T18:07:00.003-07:002013-03-17T19:21:53.110-07:00Dropping the hammer on the Aanval (The Aanval Update)Hello Autosnort Users,<br />
<br />
I am proud to announce a new, pilot release of Autosnort that will give users another web interface choice: <a href="http://www.aanval.com/">Aanval!</a><br />
<br />
For those of you who have no idea who or what Aanval is, Aanval can serve as a web UI choice for snort and/or suricata as well as a SIEM for events sent to it via syslog. There's the free edition that supports one sensor, and their commercial releases that support a large number of sensors and/or varying sources.<br />
<br />
Aanval is a product of Tactical FLEX -- They're a nice bunch of people. I have yet to meet any of them in person, but I have spoken with both the CEO and the designer of the console over twitter a few times. They are very nice, very personable, and down-to-earth. If you get around to installing Aanval, be sure to drop them a line to let them know how awesome their console is!<br />
<br />
This Autosnort release introduces some change you need to be aware of, so let's get to it:<br />
<br />
-As indicated above this is a PILOT release. I've tested it extensively over the weekend, but I can't plan for every contingency and problem. Try it out, let me know if you run into problems. The bugs you report help me, other Autosnort users, and the open-source community overall.<br />
<br />
-The new version of the script begins an effort for me to attempt to modularize Autosnort a little bit. Individual interface choices are their own child shell scripts now, called from the main shell script. This is a design choice I made to make it easier to add new and troubleshoot existing functionality.<br />
<br />
-When I refer to "main" and child shell scripts, I mean, the main script is the large Autosnort script we all know and love. The child shell scripts are much smaller shell scripts dedicated to a single purpose, like installing one particular web interface. For this update, there are two child shell scripts:<br />
<br />
snortreport.sh -- as the name implies is responsible for installing Snort Report<br />
aanval.sh -- responsible for installing aanval<br />
<br />
-The main autosnort script should be able to be ran anywhere, but the child shell script for the interface you wish to install must be placed into the /root directory for the script to complete successfully.<br />
<br />
-As a matter of good practice, I would advise having the main and the child scripts in /root when you run it. The main script expects to find the child script in /root when you make it to the interface choices menu, and call the child script for the interface you wish to install. The script checks to see that the child script completed with an exit state of 0. If it does not, the main script will NOT continue.<br />
<br />
-As another matter of good practice, I've decided that from here on out, I will keep the latest version of Autosnort available via github as well as one previous version back. This way, if you find there is some major problem with the current version of Autosnort, and you find that I am not working fast enough to resolve your problem, you can at least try to install the previous version to see if that works for you instead. In the Ubuntu Autosnort directory, there should be a Previous_Rel directory that contains the last version of Autosnort.<br />
<br />
I've updated the readme in the Ubuntu directory to reflect this information. Provided there are no major deal-breaking problems in this pilot release, I hope to push support for Aanval to Debian and CentOS in the near future as well.<br />
<br />
Update: <br />
<br />
Aanval Post-Setup notes:<br />
<br />
- It is highly advised that you reboot your system before continuing to the aanval console to continue the installation via the web interface. I ran into a problem prior to rebooting where the aanval console would not recognize that the php mysql module did exist and was loaded until the system was rebooted.<br />
<br />
- During the initial setup, aanval will want to know the name of the aanvaldb user and password.<br />
<br />
Username:snort<br />
Password:password you gave the snort database user during the autosnort installation<br />
<br />
- Aanval has a set of processes that are used to bring events over from the snort database that barnyard2 will dump to, and bring them over to the aanvaldb that aanval reads from. The console interface will let you know if they are not running. To start them, navigate to /var/www/aanval/apps and run idsBackground.pl -start --- I plan on adding an rc.local entry that will do this for you in the near future!<br />
<br />
- In order for Aanval to manage events for your snort sensor you need to enable it on the aanval console. click the gear symbol in the lower corner of the web interface. This will bring you to a page called configuration. Click the "Settings" option under the "Snort" section. On the next page, check the enabled checkbox and enter the information for the snort database:<br />
<br />
database name: snort<br />
database hostname: localhost<br />
database username: snort<br />
database password: the password you assigned to the snort database user during autosnort installation<br />
<br />
then click update. It may take a few minute for intrusion events to show up on the aanval interface. Be patient, they'll start coming in shortly!<br />
<br />
- At this time, Autosnort does not support the sensor configuration options that Aanval includes. This is a limitation on my part; I need to figure out where Aanval expects to find the rule files, snort.conf and other configuration files before this will be possible!<br />
<br />
- For more guidance and information specific to aanval, pay the folks at Tactical FLEX a visit at aanval.com<br />
<br />
Happy St. Patty's day and happy snortin' to ye.<br />
<br />
<br />da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-62564190038090236012013-03-08T09:52:00.001-08:002013-03-08T10:02:03.305-08:00Snort 2.9.4.1 and some Minor EnhancementsHello Autosnort Users,<br />
<br />
As most of you may know, snort 2.9.4.1 released a few days ago. I didn't find out until about a day after it released. Since then I've been busy testing autosnort against all supported operating systems to ensure that everything continues to work like clockwork.<br />
<br />
Here are the new features as reported on Snort.org:<br />
<br />
<blockquote class="tr_bq">
<br />
[*] Improvements<br />
<br />
* Updated File processing for partial HTTP content and MIME attachments.<br />
* Addition of new config option max_attribute_services_per_host and
improve memory usage within attribute table.<br />
* Handle excessive overlaps in frag3.<br />
* Stream API updates to return session key for a session.<br />
* Reduce false positives for TCP window slam events.<br />
* Updates to provide better encoding for TCP packets generated for respond and react.
<br />
* Disable non-ethernet decoders by default for performance reasons.
If needed, use --enable-non-ether-decoders with configure.</blockquote>
<br />
Just to serve as a reminder for new autosnort users, If you are using the registered user ruleset from snort.org, we're in the 30-day holding period before a rule tarball with compatible SO rules will be released. This comes into play when autosnort walks you through installing your rules manually or via pulled pork.<br />
<br />
During this time you will have to use a 2.9.4.0 rule tarball and disable the SO rules. If you choose to do this via pulledpork in the autosnort script, this is done for you automatically if you download the 2.9.4.0 rule tarball -- it is pulled down and pulled pork is configured to install text-based rules only.<br />
<br />
If you happen to have a VRT subscription oink code, you can install the latest rule tarballs with no issues whatsoever.<br />
<br />
Normally I would have had the blog post out sooner to correspond to the release of 2.9.4.1, but I made a couple of minor tweaks to the script that I've been meaning to do as well. So here are the improvements I have made:<br />
<br />
<br />
1. During the snortreport install for all versions of the script, instead installing snortreport to /var/www/snortreport-1.3.3 (for Ubuntu/Debian) or /var/www/html/snortreport-1.3.3 (for CentOS), removed the trailing version number.<br />
<br />
Now the directory path is /var/www/snortreport or /var/www/html/snortreport. This has been done to make it easier to point your web browser at the snort report front-end post-install. Now all you should have to type in your web browser is http://[ip address]/snortreport to gain access to the web UI.<br />
<br />
2. Updated the online scripts to pull the barnyard2 source tarball from the barnyard2 github.<br />
<br />
It was brought to my attention a little while ago over e-mail that the version of barnyard2 I was using in the script, as well as where I was downloading it from was a little dated and no longer recommended, so I rectified that. autosnort should be installing the latest master tarball via github now.<br />
<br />
<br />
That's all for now.<br />
<br />
Happy Snorting.<br />
<br />
p.s: Most of you will notice that new code has been posted for every version BUT the BT5r3 version of the script that's because quite frankly, the BT5r3 version of the script had no need to be updated whatsoever. I tested the script and it works perfectly fine as-is. The backtrack script does not install a web front-end, or barnyard2. That can change if there's enough of a desire for it...da_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0tag:blogger.com,1999:blog-7331752786831922328.post-59198186614277228252013-03-03T15:16:00.002-08:002013-03-03T15:16:34.390-08:00Modifications to autosnort offline scripts: support for Debian 6 32/64-bitHello Autosnort users,<br />
<br />
I wanted to inform you all that I've recently made changes to autosnort offline scripts to include support for Debian 6 32-bit and 64-bit. I was able to make some minor changes to both scripts to do OS checks to fix issues specific to Debian while re-using code for portions of the script that are identical to the Ubuntu 12.04 32/64-bit offline install.<br />
<br />
I've tested the scripts against Ubuntu 12.04 and Debian 6 -- 32 and 64-bit versions with a completely base install with absolutely no updates or extra packages added whatsoever -- with the exception of sshd.<br />
<br />
The steps are pretty much exactly the same as the first version of the offline script:<br />
<br />
1. Run the stage 1 shell script with create-sidmap.pl and dpkgorder text file for your OS and arch on a system with internet access that is as close to identical to your offline system as possible (meaning same ARCH, same OS version, and SAME installed packages), or to an system that is a completely baselined OS install with the same OS and arch as the offline operating system you plan to use the stage 2 shell script on.<br />
2. Copy the rule tarball and the tarball created from the stage 1 shell script on your offline system. Answer the prompts, just like the regular, online autosnort installation script.<br />
3. Reboot and you should be golden.<br />
<br />
<br />
The dpkgorder file is a complete list of .deb files for each supported operating system (Debian or Ubuntu) and each supported arch (i686 or x86_64) that assumes a base OS install with nothing but sshd on it.<br />
<br />
If you run the stage1 shell script from a completely base install of the same operating system and arch as your offline IDS system, you'll have absolutely everything you need to get snort and snort report up and running.<br />
<br />
If you choose to to clone an exact copy of the offline system to run the stage1.sh script, that's fine too, you just have to make absolutely sure the two operating systems are as close to identical as you can get them to ensure that there aren't any missing packages, because if there's one thing I've learned from this whole offline installation endeavor is that a single missing dependency will cause the whole house of cards to come tumbling down, leaving you with a VERY ugly mess.<br />
<br />
While I had the luxury of a VM, a baseline snapshot and a revert icon (I had to revert the Debian vms for testing more times than I can count this weekend), some of you won't have that luxury, so pay VERY close attention!<br />
<br />
The scripts were committed right before this blog post and should be available via the autosnort github, located under the <a href="https://github.com/da667/Autosnort/tree/master/Autosnort%20-%20Ubuntu/Offline">Ubuntu 12.04/offline directory</a>.<br />
<br />
The README should answer any remaining questions you might have or clarify steps pretty well. As always, if you have any further questions, I can be reached via twitter @da_667 or deusexmachina667 at gmail dot com.<br />
<br />
Thank you all for using autosnort, and happy snorting!<br />
<br />
~DAda_667http://www.blogger.com/profile/12074166621621209623noreply@blogger.com0