Hi Brian,
Is cool that now you solved the problem, from my opinion about pf isolating
the $dstip is not functional since basically you are creating a DDoS for a
client. For example, an attacker can send several attacks at several
machines in your network range, and basically you are isolating your
machines to protect from the attack, that is security but no functionality
since you are not isolating the source of the attack and the problem
continues. Maybe if you are in Hybrid mode, (VLAN + Inline), DROP the
traffic from the external attack using IPTABLES could be an idea. I'm not
an expertise in that, maybe Inverse team can give us an opinion, but
isolate the dstip for me is not a good idea.
Let me know how you solve this topic, I'm interested.
Best regards,
On Wed, Mar 26, 2014 at 5:18 AM, Brian Candler <[email protected]> wrote:
> > 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
>
>
--
JUAN CAMILO VALENCIA VARGAS
Ingeniero de Operaciones
SeguraTec S.A.S
Calle 11 # 43B-50 of 307
Medelllín Colombia
*"Choose a job you love, and you will never have to work a day in your
life"*
------------------------------------------------------------------------------
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
