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:
----------
H1N1 – Abstract:
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:
- 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.
- 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.
- 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.
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.
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, Unallocated Space 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:
----------
H1N1 – Day 1: Introductions, Teach, Learn, Build
The first day was primarily an introduction to the technology behind the project. Unallocated motto was integrated into today’s talk, in introducing H1N1:
- Teach:
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.
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 .
- Learn:
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.
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.
- Build: The project is ambitious, but I want to start with baby steps. Let’s start with the basics.
o What passive OS identification software do we want to use?
o Where are we going to host the code, and eventually the alpha builds?
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
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?
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.
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?
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
----------
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:
----------
H1N1 Q + A:
o What passive OS identification software do we want to use?
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.
o Where are we going to host the code, and eventually the alpha builds?
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.
o Let’s make sure that Snort and PRADS can actually sniff off the same interface without causing the box to explode?
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.
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?
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?
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.
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.
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?
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.
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
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.
----------
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.
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."
A good friend of mine, Forgotten has started a collaboration github account on github, by the namesake of this project:
https://github.com/Unallocated/H1N1
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.
Hope to see you on the list of contributors,
DA_667
Monday, August 26, 2013
Friday, August 23, 2013
autosnort: compatible with Linux Mint
This 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.
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:
1. Get a root shell: sudo /bin/bash
2. wget http://www.github.com/da667/Autosnort/Archive/master.zip
3. unzip master.zip
4. copy the autosnort-ubuntu-[date].sh script and an interface installation script to /root
5. run "bash autosnort-ubuntu-[date].sh"
6. run through the prompts as normal.
7. At the very end, when the script asks you whether or not you want to reboot, choose NO.
8. sudo vi or sudo gedit /etc/rc.local and modify the ifconfig eth0 line.
It initially reads: ifconfig eth0 up -arp -multicast promisc
make it read: ifconfig eth0 up promisc
9. save the file.
10. either reboot, or run "sudo bash /etc/rc.local"
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.
12. ps -ef | grep snort will confirm whether or not snort and/or barnyard2 are running.
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.
Cheers,
DA_667
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:
1. Get a root shell: sudo /bin/bash
2. wget http://www.github.com/da667/Autosnort/Archive/master.zip
3. unzip master.zip
4. copy the autosnort-ubuntu-[date].sh script and an interface installation script to /root
5. run "bash autosnort-ubuntu-[date].sh"
6. run through the prompts as normal.
7. At the very end, when the script asks you whether or not you want to reboot, choose NO.
8. sudo vi or sudo gedit /etc/rc.local and modify the ifconfig eth0 line.
It initially reads: ifconfig eth0 up -arp -multicast promisc
make it read: ifconfig eth0 up promisc
9. save the file.
10. either reboot, or run "sudo bash /etc/rc.local"
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.
12. ps -ef | grep snort will confirm whether or not snort and/or barnyard2 are running.
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.
Cheers,
DA_667
Sunday, August 18, 2013
Changing 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?
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:
RHEL/CentOS:
- 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:
- Status updates are in blue (e.g. [*] this indicates what autosnort is doing currently)
- Notifications are in yellow (e.g. [*] this indicates something the user needs to pay attention to (such as a prompt, or something they may want to note somehow))
- Successful modifications are in green (e.g. [*] this indicates whatever autosnort was doing was successful)
- Unsuccessful modifcations/installations are in red (e.g. [*] 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)
- 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:
-/var/log/autosnort_install.log -- contains output from all the major commands ran from the main autosnort installation script
-/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.
- 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:
-autosnort-CentOS-[date].sh
-snortreport-CentOS.sh
-base-CentOS.sh
-aanval-CentOS.sh
-syslog_full-CentOS.sh
-snorby-CentOS.sh
- 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.
- All web interface installation scripts for RHEL-based distros are 100% compatible with SELinux
- All web interface installation scripts for RHEL-based distros have had the ownership of DocumentRoot changed to the apache user and group
-Fixed minor grammatical and syntactical errors littered throughout the script.
Ubuntu/Debian:
- 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.
- 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.
- Same as the CentOS script, found minor grammatical and syntactical errors littered all over the script. Found and fixed what I could.
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:
https://github.com/da667/Autosnort
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:
https://github.com/da667/Autosnort/issues/milestones?with_issues=no
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.
Cheers,
DA_667
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:
RHEL/CentOS:
- 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:
- Status updates are in blue (e.g. [*] this indicates what autosnort is doing currently)
- Notifications are in yellow (e.g. [*] this indicates something the user needs to pay attention to (such as a prompt, or something they may want to note somehow))
- Successful modifications are in green (e.g. [*] this indicates whatever autosnort was doing was successful)
- Unsuccessful modifcations/installations are in red (e.g. [*] 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)
- 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:
-/var/log/autosnort_install.log -- contains output from all the major commands ran from the main autosnort installation script
-/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.
- 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:
-autosnort-CentOS-[date].sh
-snortreport-CentOS.sh
-base-CentOS.sh
-aanval-CentOS.sh
-syslog_full-CentOS.sh
-snorby-CentOS.sh
- 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.
- All web interface installation scripts for RHEL-based distros are 100% compatible with SELinux
- All web interface installation scripts for RHEL-based distros have had the ownership of DocumentRoot changed to the apache user and group
-Fixed minor grammatical and syntactical errors littered throughout the script.
Ubuntu/Debian:
- 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.
- 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.
- Same as the CentOS script, found minor grammatical and syntactical errors littered all over the script. Found and fixed what I could.
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:
https://github.com/da667/Autosnort
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:
https://github.com/da667/Autosnort/issues/milestones?with_issues=no
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.
Cheers,
DA_667
Monday, August 5, 2013
End of my Summer vacation; new projects to consider -- want feedback!
Dear autosnort users,
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.
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.
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.
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.
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.
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.
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.
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.
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:
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?
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 work
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.
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.
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.
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.
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.
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.
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.
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.
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:
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?
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 work
Monday, July 22, 2013
Still Out here!
Hello Autosnort Users,
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.
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.
Until then, I ask that you be patient.
Cheers,
DA_667
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.
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.
Until then, I ask that you be patient.
Cheers,
DA_667
Sunday, June 23, 2013
Autosnort-CentOS progress -- SELinux, ROR, passenger, and Snorby all working in Harmony
I'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.
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.
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.
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.
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:
https://gist.github.com/2-718/708659
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.
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.
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.
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.
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.
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.
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:
### begin code ###
module passenger 1.0;
# 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
require {
type init_t;
type initrc_t;
type system_cronjob_t;
type mysqld_t;
type usr_t;
type syslogd_t;
type system_dbusd_t;
type abrt_dump_oops_t;
type dhcpc_t;
type kernel_t;
type auditd_t;
type udev_t;
type mysqld_safe_t;
type postfix_pickup_t;
type sshd_t;
type crond_t;
type getty_t;
type anon_inodefs_t;
type httpd_tmp_t;
type devpts_t;
type user_devpts_t;
type httpd_sys_script_t;
type security_t;
type httpd_t;
type unconfined_t;
type selinux_config_t;
type hi_reserved_port_t;
type httpd_sys_content_t;
type httpd_sys_rw_content_t;
type var_t;
type cert_t;
type postfix_qmgr_t;
type postfix_master_t;
class file { getattr read create append write execute execute_no_trans open };
class process { siginh signal noatsecure rlimitinh setpgid getsession };
class unix_stream_socket { read write shutdown };
class chr_file { read write append ioctl };
class capability { setuid dac_override chown fsetid setgid fowner sys_nice sys_resource sys_ptrace kill };
class fifo_file { setattr create getattr unlink };
class sock_file { write getattr setattr create unlink };
class lnk_file { read getattr };
class udp_socket name_bind;
class dir { write read search add_name getattr };
}
#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.
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t abrt_dump_oops_t:dir { search getattr };
allow httpd_sys_script_t abrt_dump_oops_t:file { read open };
allow httpd_sys_script_t anon_inodefs_t:file { read write };
allow httpd_sys_script_t auditd_t:dir { search getattr };
allow httpd_sys_script_t auditd_t:file { read open };
allow httpd_sys_script_t cert_t:dir { search getattr };
allow httpd_sys_script_t cert_t:file { read getattr };
allow httpd_sys_script_t cert_t:lnk_file read;
allow httpd_sys_script_t crond_t:dir { search getattr };
allow httpd_sys_script_t crond_t:file { read open };
allow httpd_sys_script_t devpts_t:chr_file { read write };
allow httpd_sys_script_t dhcpc_t:dir { search getattr };
allow httpd_sys_script_t dhcpc_t:file { read open };
allow httpd_sys_script_t getty_t:dir { search getattr };
allow httpd_sys_script_t getty_t:file { read open };
allow httpd_sys_script_t httpd_sys_content_t:fifo_file setattr;
allow httpd_sys_script_t httpd_sys_content_t:sock_file { create unlink setattr };
allow httpd_sys_script_t httpd_sys_rw_content_t:file { execute execute_no_trans };
allow httpd_sys_script_t httpd_t:dir { search getattr };
allow httpd_sys_script_t httpd_t:file { read open };
allow httpd_sys_script_t httpd_t:unix_stream_socket { read write };
allow httpd_sys_script_t httpd_tmp_t:fifo_file setattr;
allow httpd_sys_script_t httpd_tmp_t:sock_file { write create unlink setattr };
allow httpd_sys_script_t init_t:dir { search getattr };
allow httpd_sys_script_t init_t:file { read open };
allow httpd_sys_script_t initrc_t:dir { search getattr };
allow httpd_sys_script_t initrc_t:file { read open };
allow httpd_sys_script_t kernel_t:dir { search getattr };
allow httpd_sys_script_t kernel_t:file { read open };
allow httpd_sys_script_t mysqld_safe_t:dir { search getattr };
allow httpd_sys_script_t mysqld_safe_t:file { read open };
allow httpd_sys_script_t mysqld_t:dir { search getattr };
allow httpd_sys_script_t mysqld_t:file { read open };
allow httpd_sys_script_t postfix_master_t:dir { search getattr };
allow httpd_sys_script_t postfix_master_t:file { read open };
allow httpd_sys_script_t postfix_pickup_t:dir { search getattr };
allow httpd_sys_script_t postfix_pickup_t:file { read open };
allow httpd_sys_script_t postfix_qmgr_t:dir { search getattr };
allow httpd_sys_script_t postfix_qmgr_t:file { read open };
allow httpd_sys_script_t self:capability { setuid chown fsetid setgid fowner dac_override sys_nice sys_resource sys_ptrace kill };
allow httpd_sys_script_t self:process { setpgid getsession };
allow httpd_sys_script_t sshd_t:dir { search getattr };
allow httpd_sys_script_t sshd_t:file { read open };
allow httpd_sys_script_t syslogd_t:dir { search getattr };
allow httpd_sys_script_t syslogd_t:file { read open };
allow httpd_sys_script_t system_cronjob_t:dir getattr;
allow httpd_sys_script_t system_dbusd_t:dir { search getattr };
allow httpd_sys_script_t system_dbusd_t:file { read open };
allow httpd_sys_script_t udev_t:dir { search getattr };
allow httpd_sys_script_t udev_t:file { read open };
allow httpd_sys_script_t unconfined_t:dir { search getattr };
allow httpd_sys_script_t unconfined_t:file { read open };
allow httpd_sys_script_t unconfined_t:process signal;
allow httpd_sys_script_t user_devpts_t:chr_file { read write append ioctl };
allow httpd_sys_script_t usr_t:file execute;
allow httpd_sys_script_t var_t:dir { write read add_name };
allow httpd_sys_script_t var_t:file { read getattr create append };
#============= httpd_t ==============
allow httpd_t hi_reserved_port_t:udp_socket name_bind;
allow httpd_t httpd_sys_content_t:fifo_file { create unlink getattr setattr };
allow httpd_t httpd_sys_content_t:sock_file { getattr unlink setattr };
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure };
allow httpd_t httpd_sys_script_t:unix_stream_socket { read write shutdown };
allow httpd_t httpd_tmp_t:fifo_file { create unlink getattr setattr };
allow httpd_t httpd_tmp_t:sock_file { getattr unlink setattr };
allow httpd_t security_t:dir search;
allow httpd_t self:capability { fowner fsetid };
allow httpd_t selinux_config_t:dir search;
allow httpd_t var_t:file { read getattr };
allow httpd_t var_t:lnk_file { read getattr };
### end code ###
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?
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.
Okay, so now that I'm off my soapbox, you're probably wondering when to expect a code push for CentOS.
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.
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.
Until next time,
DA_667
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.
I hope that it is some help to the Linux community.
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.
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.
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.
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:
https://gist.github.com/2-718/708659
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.
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.
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.
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.
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.
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.
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:
### begin code ###
module passenger 1.0;
# 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
require {
type init_t;
type initrc_t;
type system_cronjob_t;
type mysqld_t;
type usr_t;
type syslogd_t;
type system_dbusd_t;
type abrt_dump_oops_t;
type dhcpc_t;
type kernel_t;
type auditd_t;
type udev_t;
type mysqld_safe_t;
type postfix_pickup_t;
type sshd_t;
type crond_t;
type getty_t;
type anon_inodefs_t;
type httpd_tmp_t;
type devpts_t;
type user_devpts_t;
type httpd_sys_script_t;
type security_t;
type httpd_t;
type unconfined_t;
type selinux_config_t;
type hi_reserved_port_t;
type httpd_sys_content_t;
type httpd_sys_rw_content_t;
type var_t;
type cert_t;
type postfix_qmgr_t;
type postfix_master_t;
class file { getattr read create append write execute execute_no_trans open };
class process { siginh signal noatsecure rlimitinh setpgid getsession };
class unix_stream_socket { read write shutdown };
class chr_file { read write append ioctl };
class capability { setuid dac_override chown fsetid setgid fowner sys_nice sys_resource sys_ptrace kill };
class fifo_file { setattr create getattr unlink };
class sock_file { write getattr setattr create unlink };
class lnk_file { read getattr };
class udp_socket name_bind;
class dir { write read search add_name getattr };
}
#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.
#============= httpd_sys_script_t ==============
allow httpd_sys_script_t abrt_dump_oops_t:dir { search getattr };
allow httpd_sys_script_t abrt_dump_oops_t:file { read open };
allow httpd_sys_script_t anon_inodefs_t:file { read write };
allow httpd_sys_script_t auditd_t:dir { search getattr };
allow httpd_sys_script_t auditd_t:file { read open };
allow httpd_sys_script_t cert_t:dir { search getattr };
allow httpd_sys_script_t cert_t:file { read getattr };
allow httpd_sys_script_t cert_t:lnk_file read;
allow httpd_sys_script_t crond_t:dir { search getattr };
allow httpd_sys_script_t crond_t:file { read open };
allow httpd_sys_script_t devpts_t:chr_file { read write };
allow httpd_sys_script_t dhcpc_t:dir { search getattr };
allow httpd_sys_script_t dhcpc_t:file { read open };
allow httpd_sys_script_t getty_t:dir { search getattr };
allow httpd_sys_script_t getty_t:file { read open };
allow httpd_sys_script_t httpd_sys_content_t:fifo_file setattr;
allow httpd_sys_script_t httpd_sys_content_t:sock_file { create unlink setattr };
allow httpd_sys_script_t httpd_sys_rw_content_t:file { execute execute_no_trans };
allow httpd_sys_script_t httpd_t:dir { search getattr };
allow httpd_sys_script_t httpd_t:file { read open };
allow httpd_sys_script_t httpd_t:unix_stream_socket { read write };
allow httpd_sys_script_t httpd_tmp_t:fifo_file setattr;
allow httpd_sys_script_t httpd_tmp_t:sock_file { write create unlink setattr };
allow httpd_sys_script_t init_t:dir { search getattr };
allow httpd_sys_script_t init_t:file { read open };
allow httpd_sys_script_t initrc_t:dir { search getattr };
allow httpd_sys_script_t initrc_t:file { read open };
allow httpd_sys_script_t kernel_t:dir { search getattr };
allow httpd_sys_script_t kernel_t:file { read open };
allow httpd_sys_script_t mysqld_safe_t:dir { search getattr };
allow httpd_sys_script_t mysqld_safe_t:file { read open };
allow httpd_sys_script_t mysqld_t:dir { search getattr };
allow httpd_sys_script_t mysqld_t:file { read open };
allow httpd_sys_script_t postfix_master_t:dir { search getattr };
allow httpd_sys_script_t postfix_master_t:file { read open };
allow httpd_sys_script_t postfix_pickup_t:dir { search getattr };
allow httpd_sys_script_t postfix_pickup_t:file { read open };
allow httpd_sys_script_t postfix_qmgr_t:dir { search getattr };
allow httpd_sys_script_t postfix_qmgr_t:file { read open };
allow httpd_sys_script_t self:capability { setuid chown fsetid setgid fowner dac_override sys_nice sys_resource sys_ptrace kill };
allow httpd_sys_script_t self:process { setpgid getsession };
allow httpd_sys_script_t sshd_t:dir { search getattr };
allow httpd_sys_script_t sshd_t:file { read open };
allow httpd_sys_script_t syslogd_t:dir { search getattr };
allow httpd_sys_script_t syslogd_t:file { read open };
allow httpd_sys_script_t system_cronjob_t:dir getattr;
allow httpd_sys_script_t system_dbusd_t:dir { search getattr };
allow httpd_sys_script_t system_dbusd_t:file { read open };
allow httpd_sys_script_t udev_t:dir { search getattr };
allow httpd_sys_script_t udev_t:file { read open };
allow httpd_sys_script_t unconfined_t:dir { search getattr };
allow httpd_sys_script_t unconfined_t:file { read open };
allow httpd_sys_script_t unconfined_t:process signal;
allow httpd_sys_script_t user_devpts_t:chr_file { read write append ioctl };
allow httpd_sys_script_t usr_t:file execute;
allow httpd_sys_script_t var_t:dir { write read add_name };
allow httpd_sys_script_t var_t:file { read getattr create append };
#============= httpd_t ==============
allow httpd_t hi_reserved_port_t:udp_socket name_bind;
allow httpd_t httpd_sys_content_t:fifo_file { create unlink getattr setattr };
allow httpd_t httpd_sys_content_t:sock_file { getattr unlink setattr };
allow httpd_t httpd_sys_script_t:process { siginh rlimitinh noatsecure };
allow httpd_t httpd_sys_script_t:unix_stream_socket { read write shutdown };
allow httpd_t httpd_tmp_t:fifo_file { create unlink getattr setattr };
allow httpd_t httpd_tmp_t:sock_file { getattr unlink setattr };
allow httpd_t security_t:dir search;
allow httpd_t self:capability { fowner fsetid };
allow httpd_t selinux_config_t:dir search;
allow httpd_t var_t:file { read getattr };
allow httpd_t var_t:lnk_file { read getattr };
### end code ###
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?
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.
Okay, so now that I'm off my soapbox, you're probably wondering when to expect a code push for CentOS.
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.
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.
Until next time,
DA_667
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.
I hope that it is some help to the Linux community.
Friday, June 14, 2013
New Autosnort Release, support for more distros and much more!
Hello,
Lots to talk about, so let's get started.
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.
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:
[*] are things that the script is doing
[*] are things the user should pay attention to
[*] are successful results
[*] are unsuccessful results
"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.
The script will now actually tell you where I installed things, instead of you having to hunt and guess (sorry about that..)
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.
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.
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.
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.
After that is finished, here's what I'd like to focus on:
- All web interfaces should have SSL/HTTPS enabled by default. No exceptions.
- Remove database/barebone sensors should have a method to secure database transactions to the "Master Console"
+ 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:
--have p0f run for a set period of time, sample traffic off the network, fingerprint operating systems and write results to a database
--script something out that takes the database results and helps write frag3/stream5 reassembly policies based off p0f results.
Same as always, the scripts are available via The Autosnort Github Repo
That's about it for now. Happy snorting, hope you enjoy the new release!
DA_667
Lots to talk about, so let's get started.
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.
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:
[*] are things that the script is doing
[*] are things the user should pay attention to
[*] are successful results
[*] are unsuccessful results
"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.
The script will now actually tell you where I installed things, instead of you having to hunt and guess (sorry about that..)
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.
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.
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.
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.
After that is finished, here's what I'd like to focus on:
- All web interfaces should have SSL/HTTPS enabled by default. No exceptions.
- Remove database/barebone sensors should have a method to secure database transactions to the "Master Console"
+ 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:
--have p0f run for a set period of time, sample traffic off the network, fingerprint operating systems and write results to a database
--script something out that takes the database results and helps write frag3/stream5 reassembly policies based off p0f results.
Same as always, the scripts are available via The Autosnort Github Repo
That's about it for now. Happy snorting, hope you enjoy the new release!
DA_667
Subscribe to:
Posts (Atom)