If i use pfBlockerNG will that take first hit before Suricata?
-
If i use pfBlockerNG will that take first hit before Suricata inspects the traffic?
basically to relief suricata from unnecessary package inspections
-
If you are running it on WAN, no.
-
Ok, thats kind of unoptimized to inspect things that would be blocked anyway?
or is the solution to let suricata work on the LAN side only?
maybe thats a better implementation i have always thought it would be against WAN side...hmm -
Yes, set Suricata to monitor LAN so it 1) doesn't see any traffic blocked by the firewall rules on WAN, and 2) shows you which LAN IP is triggering the alert.
-
@teamits said in If i use pfBlockerNG will that take first hit before Suricata?:
Yes, set Suricata to monitor LAN so it 1) doesn't see any traffic blocked by the firewall rules on WAN, and 2) shows you which LAN IP is triggering the alert.
Yeah but what if one wants to see who is lurking your WAN and trying to get in??
Port scanning bastards are not blocked if you dont run it on WAN
-
@cool_corona said in If i use pfBlockerNG will that take first hit before Suricata?:
Yeah but what if one wants to see who is lurking your WAN and trying to get in??
A pure waste of time. Waste of CPU cycles. Waste of energy.
And all you see are IP address. As packets are dropped based on Ethernet packet header info.
The data payload, probably encrypted, can't be seen by .... any program. Except if you actually 'accept' (all/any) inbound traffic. Don't, because as soon as you start to do that, it will get known and you're signing your own DDOS death. -
@cool_corona said in If i use pfBlockerNG will that take first hit before Suricata?:
Port scanning bastards are not blocked if you dont run it on WAN
Well they are blocked by firewall rules. And for NATted servers they are still blocked. The order would be:
(internet)->(Suricata on WAN)->(firewall rules on WAN)->(Suricata on LAN)->(server on LAN)
Look for posts by the package maintainer recommending to put it on LAN instead of WAN.
-
@teamits said in If i use pfBlockerNG will that take first hit before Suricata?:
@cool_corona said in If i use pfBlockerNG will that take first hit before Suricata?:
Port scanning bastards are not blocked if you dont run it on WAN
Well they are blocked by firewall rules. And for NATted servers they are still blocked. The order would be:
(internet)->(Suricata on WAN)->(firewall rules on WAN)->(Suricata on LAN)->(server on LAN)
Look for posts by the package maintainer recommending to put it on LAN instead of WAN.
I know Steve :)
Run it on both WAN and LAN for the same reason.
-
@cool_corona I reread your post and I understand your point. I guess I don't particularly care "who" is port scanning if they can't get in. I just assume "outside is bad." :) (also I missed that you weren't the OP, from the emailed notification)
As I understand you, uour usage case is that someone scanning 10000 ports would get blocked before they get to the one open port, vs. if there was only one port open the LAN instance of Suricata wouldn't detect that as a port scan. It would trigger only if they sent a packet that would be forwarded by the one open port and blocked by the LAN instance. In that case the LAN instance is double scanning the packets, so I'm not sure there is as much benefit of scanning there? The LAN alerts might still be more useful for finding the LAN IP of outgoing traffic.
Possibly, a way to reduce the double scanning would be to have only rules for port scanning enabled on WAN?
-
@teamits said in If i use pfBlockerNG will that take first hit before Suricata?:
@cool_corona I reread your post and I understand your point. I guess I don't particularly care "who" is port scanning if they can't get in. I just assume "outside is bad." :) (also I missed that you weren't the OP, from the emailed notification)
As I understand you, uour usage case is that someone scanning 10000 ports would get blocked before they get to the one open port, vs. if there was only one port open the LAN instance of Suricata wouldn't detect that as a port scan. It would trigger only if they sent a packet that would be forwarded by the one open port and blocked by the LAN instance. In that case the LAN instance is double scanning the packets, so I'm not sure there is as much benefit of scanning there? The LAN alerts might still be more useful for finding the LAN IP of outgoing traffic.
Possibly, a way to reduce the double scanning would be to have only rules for port scanning enabled on WAN?
Exactly the way I am doing it :)
