Hi, I've created an ebuild file and corresponding patches to make snort_inline-2.1.0 happy with the gentoo environment -- in particular with the way gentoo handles libnet. I've adapted the ebuild from the snort package (as snort_inline is a modification of snort proper). Attached is the ebuild, and the necessary patches.
Created attachment 24107 [details] ebuild for snort_inline-2.1.0
Created attachment 24108 [details, diff] snort_inline libnet patch
Created attachment 24109 [details, diff] snort_inline gcc3 fix, stolen from snort package
Created attachment 24111 [details, diff] Another patch from snort
Created attachment 24112 [details, diff] pgsql patch from snort
Created attachment 24113 [details] confd file for snort_inline
Created attachment 24114 [details] rc6 file for snort_inline
I could build the package and stuff, but I have no equipment to make sure it works as advertised. I can maintain it in ~x86 if I get the assurance that I get help keeping the software related bugs under controll. How does that sound?
BTW: last time I tested snort-inline I needed 'ebtables' in my kernel. It can be found at ebtables.sf.net. Patching gentoo-sources is pretty easy, add one more URL in SRC_URI and modify the UNIPATCH_LIST variable accordingly. I can also create the ebuild for the userland tools. My biggest problem is that I do not have the skills to fix any software bugs in the kernel or kernel related tools. BTW: IF we get snort-inline into gentoo it will be it's own package, as it is not your standard snort even if it is based on the snort codebase.
I'm willing to help test or integrate changes into the build as necessary. I would expect this package to be ~86, as it will no doubt require much work to be done by the user to customize to their particular needs anyway. (Hopefully just in the configuration realm however) Software related bugs most likely will be a result of bugs in Snort, and not in snort-inline itself. As for bugs in the snort-inline modification, I know we'll get whatever support we need. The lead developer is a great guy. As for the ebtables patch, I dont recall applying that one specifically, but I do believe you are correct in assuming that it is required for necessary functionality. Cheers!
I'd like to draw the help from the x86-kernel people to incorperate the 'ebtables' kernel patch in at least one of our kernel sources. Without this patch snort-inline won't work, which makes this request impossible to forfull. Once the patch has been incorperated I'll create ebtables userspace ebuild as well as commiting the snort-inline ebuild.
Quick update: Saw that solar@g.o have added in the ebtables userspace tools (thanks dude!). Now we only need a kernel with the ebtables patch applied and then this ebuild can be propperly taken care of ;)
Please keep me posted on what kernel 2.4.x kernel will have ebtables support. Support should be there by default in 2.6.x for ebtables,arptables
I have commited net-analyzer/snort_inline 2.1.0a to CVS, and should be available at your local rsync server in about 30 minutes. Please test and report back any success or failure with this ebuild.
I've just successfully built the snort_inline package from portage. :) Unfortunately, the init script seems to require the service "ebtables", which does not have a service startup script aparrently. ebtables was built as a dependency of snort_inline correctly (seemingly) and shows installed when queried with epm: # epm -q ebtables ebtables-2.0.6 This is a fresh build with the 2.6.4-rc1 development sources tree. One other thing I did notice, which I believe I've seen before is that both libnet-1.0.2a and libnet-1.1 are built even though the dependencies are stated as: <net-libs/libnet-1.1 >=net-libs/libnet-1.0.2a-r3 Another additional issue is that the sed part in the ebuild for changing the rulepath of snort_inline.conf is set incorrectly. Also, it is now taking the snort.conf file as the distrib file, and not snort_inline.conf. Line from portage: sed "s:var RULE_PATH ../rules:var RULE_PATH /etc/snort-inline:" < etc/sn ort.conf > etc/snort.conf.distrib From my attachment: sed "s:var RULE_PATH /etc/snort_inline/drop-rules:var RULE_PATH /etc/snort_inline/rules:" < etc/snort_inline.conf > etc/snort_inline.conf.distrib snort.conf is different from snort_inline.conf.... Also, I had it putting the rules in /etc/snort_inline/rules for a cleaner /etc hierarchy, I'm not sure if thats necessarily a good thing, and I leave that to someone else to decide, but it does seem cleaner since there can be MANY files there... I think that's probably plenty of issues for now! :) Cheers! -- Patrick
Seems like we need another go to get this one working...
Solar: could ebtables get a start/stop script that load/clear/save the ruleset just like iptables does it?
I've removed the dependency on ebtables service, as it doesn't yet exist. regarding the libnet beeing built twice.. It's a portage dependency calculation bug IMHO. I'll check with the portage guys to see if it has a propper solution. Regarding the PATH's choosen: I'd like to keep the snort_inline ebuild as close to snort vanilla ebuild to simplify maintainence. The vanilla snort ebuild put the rules in /etc/snort long before it landed in my lap, and I am quite sure that there are a few people that counts on the specific location. That said, /etc/{snort,snort_inline}/rules is much cleaner and I'll investigate how to move the rules for vanilla snort w/o breaking too much. Snort_inline does not have this legacy problem so I'll fix that one right away ;) Also, I'll update snort_inline to 2.1.1 once the ebuild is sorted out (should be a simple version bump away). So, again please try the new ebuild out (net-analyzer/snort_inline-2.1.0a-r1).. It should hit the rsync mirrors in 30 minutes or so..
Sweetness, I got it running this time.. Couple more minor bugs though: 1) /etc/conf.d/snort_inline has snort_inline running as the user "snort", but our ebuild creates the user "snort_inline Line: SNORT_OPTS="-D -Q -u snort -l $LOGDIR -c $CONF" Should be: SNORT_OPTS="-D -Q -u snort_inline -l $LOGDIR -c $CONF" 2) reference.config and classification.config in the snort_inline distributed config are being looked for in $RULE_PATH/blah.config, but they are in just /etc/snort_inline instead of /etc/snort_inline/rules The other option obviously is to change the snort_inline.conf.distrib: Old: # Include classification & priority settings include $RULE_PATH/classification.config include $RULE_PATH/reference.config New: # Include classification & priority settings include classification.config include reference.config Probably could be done with a sed line much like the RULE_PATH in the ebuild, but whatever works :) Well, those weren't too bad.. were they? Yay, working snort_inline... Happy snorting! -- Patrick
Re: ebtables init scripts I'm not sure about this. iptables has /sbin/iptables-{save,restore} and ebtables has nothing like this. Perhaps with a little work and some c loving one could barrow the code and make it work for ebtables (maybe). My plate is pretty full now so I don't think I'll be exploring that however patches are welcome.
Solar: ebtables [-t table] [--atomic-file file] --atomic-commit ebtables [-t table] [--atomic-file file] --atomic-init ebtables [-t table] [--atomic-file file] --atomic-save basically, take iptabes init script, replace 'iptables-save' with 'ebtables --atomic-file /path/to/ebtables.rules --atomic-save' and iptables-restore with 'ebtables --atomic-file /path/to/ebtables.rules --atomic-commit'
Created attachment 27735 [details] snort_inline-2.1.0a-r2.ebuild Please test this ebuild out. It should fix the last reported errors.
Created attachment 27736 [details, diff] snort_inline.confd.diff Diff file for files/snort_inline.confd
Re #21 Seeing as your requesting this, and you already know exactly what needs to be done. Feel free to do it yourself bud.
This patch/ebuild does indeed seem to address every problem I've seen :) Sorry I took so long to check this out, my hard drive decided it wanted to take a permanent vacation. (fun) Thanks for your hard work!
Closing bug...