Matt Jonkman over at emerging threats was nice enough to host a CentoOS5 rpm repo for me. I have created a set of i686 kernel rpms that have been patched to include PF_RING and ipset. I did not backport libpcap to the version included with CentOS5 so you will have to recompile your libpcap based tools if you decide to use the pf_ring/libpcap based stuff for the 0.9.7 version in the repo. I also have included rpms for the latest apache etc so I suggest if you use a file to throw into /etc/yum.repos.d/ you use the include/exclude stuff options so that you only pull the items that you need/want. There are quite a few other useful tools that have been recomipled to use libpfring.
To use ipset you will have to remove your existing iptables version and replace it with the one in the repo.
link to the repo..
http://www.emergingthreats.net/emergingrepo/
I have also modified the script created by Joshua Gimer for updating the fw rules using ipset which you can download here.
http://doc.emergingthreats.net/pub/Main/EmergingFirewallRules/emerging-ipset-update.pl.txt
Subscribe to:
Post Comments (Atom)
7 comments:
Will, thanks for sharing your work of building PF_RING-enabled kernel rpms for CentOS5. I've been wanting to get PF_RING working on several CentOS5 boxes but have not been able to find anyone who actually succeeded in making it work. Did you build this based on the vanilla kernel.org kernel sources or the ones from CentOS? For that matter, would you be willing to share your notes on how you went about successfully building these RPMs?
I noticed that the -164 kernel with IPSET/PF_RING in that repo is only for 64-bit and there is no source RPM for the -164 kernel. Is there anyway you could put the source RPM in the repo so we could compile a 32-bit build? <3
Actually Ryan, you no longer need to recompile the kernel to install PF_RING. It now builds just fine as a module. Heck you don't even have to reboot ;-).
If you are running on CentOS 5 I suggest you check out rev 4079 or earlier as currently the last few revs don't work with CentOS 5 because of an added RX QUEUE check.
svn co --revision 4079 https://svn.ntop.org/svn/ntop/trunk/PF_RING/
cd PF_RING/kernel
make && make install
same for the userland/lib folder and then you can make libpcap and examples and tcpdump etc.
Will, I just ran into the same CentOS5 RX QUEUE issue and posted on ntop-misc about it (http://listgateway.unipi.it/pipermail/ntop-misc/2010-January/001554.html). So I'm working with rev 4079, too. Do you plan to make the RPMs in emergingrepo work with the new PFRING? It would be so cool if you had the time.
I've been trying to build the latest Snort against PF_RING 4.1 (rev 4079)
according to Luca's example userland/README.snort but I've had no joy. After a bunch of tweaks I can get it to complete the build but I observe that the resulting snort binary isn't linked to any libpcap library at all and that when I run snort it allocates a pf_ring ring but no packets are ever captured. Would you be willing to share a little advice with us CentOS 5 PF_RING folks on how to build snort against PF_RING these days?
I don't really have the cycles right now to do this. I've been thinking about a better way to handle this anyway. It is sort of a pain that Cent uses such an old version of libpcap. But even worse if I just want some libpcap based app that I don't want pf_ring support for. Say something just for offline analysis I have create a custom rpm for it. I think it may be better to drop everything PF_RING related into like /opt/PF_RING
and then create some sort of wrapper for the PF_RING enabled apps. This way everything else works as normal as far as installing other pcap apps.
This is probably because the readme is showing the libpcap libpfring includes/libs being passed as relative paths instead of absolute paths. In my experience this in conjunction with autoconf doesn't work properly. Try setting absolute paths and see if this fixes the problem.
Post a Comment