First you need to define in pf.conf a line detection=enabled under
[trapping] section. Then you can configure either in pf.conf.defaults or
pf.conf, under [services] you should create a line snort=enabled. Then you
need to apply this couple of patches,this was making me work around the
past week and I found that was a bug in 4.1 version,
https://www.mail-archive.com/[email protected]/msg05709.html
<https://www.mail-archive.com/[email protected]/msg05709.html>,
follow the thread and you can find the couple of solutions, restart
packetfence and everything should work now.
Thank you for that (aside: I didn't need to create [services]
snort=enabled). I have also set [trapping] range=10.0.0.0/8, because I'm
using net 10 addresses.
I am trying to demonstrate this using http://testmyids.com/. This is
supposed to trigger the following snort rule:
# grep -R "id check returned root" conf
conf/snort/sid-msg.map:2100498 || GPL ATTACK_RESPONSE id check returned root
conf/snort/emerging-attack_response.rules:alert ip any any -> any any
(msg:"GPL ATTACK_RESPONSE id check returned root";
content:"uid=0|28|root|29|"; fast_pattern:only; classtype:bad-unknown;
sid:2100498; rev:8;)
So I added to violations.conf:
### LOCAL
[2100498]
desc=Malware
priority=4
template=malware
enabled=Y
actions=trap,email,log
trigger=Detect::2100498
Now when this traffic passes, I get the following in packetfence.log:
Mar 26 09:47:14 pfdetect(1550) INFO: alert received:
03/26-09:47:14.400342 [**] [1:2100498:8] GPL ATTACK_RESPONSE id check
returned root [**] [Classification: Potentially Bad Traffic] [Priority:
2] {TCP} 82.165.177.154:80 -> 10.10.0.167:52894
(main::)
Mar 26 09:47:14 pfdetect(1550) INFO: could not resolve 82.165.177.154 to
mac in ARP table (pf::iplog::ip2macinarp)
Mar 26 09:47:14 pfdetect(1550) WARN: could not resolve 82.165.177.154 to
mac (pf::iplog::ip2mac)
Mar 26 09:47:14 pfdetect(1550) WARN: pfdetect: 82.165.177.154 MAC NOT
FOUND for violation 2100498 [GPL] (main::)
and no vlan change takes place.
As far as I can tell from this message: packetfence is trying to resolve
the source address rather than the destination address (despite this
being triggered on an incoming packet). This behaviour looks to be
hard-coded in sbin/pfdetect:
$srcmac = ip2mac($srcip);
if ($srcmac) {
$logger->info("pfdetect: violation $sid [$descr]: $srcmac");
violation_trigger($srcmac, $sid, "detect", ( ip => $srcip ));
} else {
$logger->warn(
"pfdetect: $srcip MAC NOT FOUND for violation $sid [$descr]");
}
Is this an oversight? $dstip is captured in the regex, but as far as I
can see is never used.
I did a quick proof-of-concept and this seems to work:
--- sbin/pfdetect.orig 2014-03-26 10:09:07.867025814 +0000
+++ sbin/pfdetect 2014-03-26 10:13:46.951025643 +0000
@@ -83,7 +83,7 @@
pod2usage( -verbose => 1 ) if ( $args{h} || !$args{p} );
-my ($line, $sid, $descr, $priority, $date, $srcmac, $srcip, $dstip);
+my ($line, $sid, $descr, $priority, $date, $srcmac, $srcip, $dstmac,
$dstip);
daemonize() if ($daemonize);
@@ -134,6 +134,10 @@
$logger->info("pfdetect: violation $sid [$descr]: $srcmac");
violation_trigger($srcmac, $sid, "detect", ( ip => $srcip ));
+ } elsif ($dstip && ($dstmac = ip2mac($dstip))) {
+
+ $logger->info("pfdetect: violation $sid [$descr]: $dstmac");
+ violation_trigger($dstmac, $sid, "detect", ( ip => $dstip ));
} else {
$logger->warn(
"pfdetect: $srcip MAC NOT FOUND for violation $sid [$descr]");
but it might be cleaner to check which of $srcip and $dstip is contained
within trigger.range, and use that.
Thanks,
Brian.
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
