Few questions reagrding FW behavior
-
Hello all,
I am about to migrate my network from Mikrotik/RouterOS to pfSense solution. I've done my homework by reading through official docs as well as several nice threads here on forum. I've also spent some time watching pfSense videos from Lawrence. My pfSense router is basically configured with the necessary stuff but before i press the button i'd like to ask few questions for which either i don't know the answer (missing pieces) or i am not 100% confident i got it properly so i just want to double check.
Thank you in advance for any comments/answers for the bellow points.
1] pfSense blocks everything incoming to WAN port by default
There is a notice under Firewall->WAN about that. But as soon as i add a specific "Allow" rule it disappears. Does it mean that the "block all" is no longer valid and i need to put that manually as a last rule on WAN? Or is it always there as a last rule no matter what. I haven't found clear statement about that in docs.2] How to "Allow Established and Related connections"
I found a thread on forum with the same question and there was only one answer... "I think a rule that implements the described behaviour is internally created by pf once you created a stateful rule" ... I don't play games with "I think" statements. I want to be sure and again this is not documented.3] How to "Drop invalid connections"
Ok this is mostly Mikrotik specific but i have to ask. Even i have very specific "allow" rules for incoming WAN connections my paranoia level tells me that there still could be a fabricated packets coming to my doors. Or a random noise/lost packets which could (on theoretical level) match on my rules. Most probably doing nothing but still. Mikrotik has internal checks for "Invalid connections" and they describe it like this:invalid - a packet that does not have determined state in connection tracking (usually - severe out-of-order packets, packets with wrong sequence/ack number, or in case of resource overusage on router), for this reason invalid packet will not participate in NAT (as only connection-state=new packets do), and will still contain original source IP address when routed. We strongly suggest to drop all connection-state=invalid packets in firewall filter forward and input chains
I wonder if there is any (internal) function in pfSense handling this.
4] VLAN vs Interface rules
I will explain this by an example. One of the physical interface (lets call it "ETH1") on pfSense is connected to L2 switch and LAN clients are connected to that one. My whole LAN is basically VLAN aware so everything is either TAGed directly or via Untagged port on switch. I have multiple VLANs configured on pfSense where the ETH1 acts as a "trunk" port. Interface ETH1 has "IPv4 Configuration Type" set to "none" since there is nothing outside VLAN so i don't need a network at all. IPv4 networks are configured on each VLAN interface either with DHCP server enabled or with static IP assignment. Each VLAN has its own subnet and there are FW rules for isolation to prevent cross-talk.I have workstation (lets call it "SYSOP") on VLAN100 which supposed to be the only one allowed to reach the pfSense admin GUI. My current rule is on VLAN100 interface allowing connection from SYSOP IP towards "VLAN100 address" and specific ports. Then second rule drops everything else reaching the same ports against "VLAN100 address".
But after doing above i've realized that this blocks only the VLAN100 clients while any clients from other VLANs can reach the pfSense by its own subnet IP. Creating the "Deny" rules for each VLAN seems a bit dumb to me.So i was thinking that i will remove the rules above from VLAN100 interface and put them on ETH1 Interface which is a physical NIC. But here i am uncertain as ETH1 has no network. So how it will work if i use "ETH1 address" as a destination condition? Will that automatically consider all of the related VLAN Interface addresses or neither one (as none is defined)? Or do i need to create an alias for all of the VLAN networks and then use it as destination on ETH1 rule?
I can not just leave destination "Any" as that would block any other connections using the same port (unlikely to happen as the port is not default but still wrong way i guess)See my brain still works with "RouterOS" way and there i have a simple rule "Allow incoming packets on ETH2 while source is SYSOP_IP and destination port is 11111" then second rule which drops everything else coming to port 11111 on ETH2.
I assume there is a simple way to say "If the destination port is this physical interface and i don't care about other stuff but port number" but i am missing it.
5] Automatically populated black-list
List of IPs can be created by aliases that is clear to me but how to add new IP automatically? See on my current configuration i have few rules which are explicitly dropping incoming connections on certain ports (RDP, 22, etc...). On top of that whenever such connection reaches my router the source IP is automatically added to a blacklist for certain amount of time as it is most probably a port-scan or a fcking botnet trying random stuff. Then one of my top FW rules is to check if the source IP is on blacklist. If so then just drop that and do not process further rules. Otherwise proceed. This is not only paranoia level over 9000 but it saves some CPU clocks as the "bad guys" are shot on sight by the one of the top rules.
Any way to achieve similar behavior on pfSense?That is all for now. I might add few more as i haven't reached all of the tiny details for specific areas.
Thanks !
Alex
-
1] pfSense blocks everything incoming to WAN port by default
Yes. Imagine that there is a hidden Deny All rule at the bottom of all interface rules. If it isn't explicitly allowed, it's denied.
2] How to "Allow Established and Related connections"
It does it by itself. pf is a stateful firewall. It automatically allows return traffic from traffic you initiated. If you really need to know all the underlying plumbing with 100% accuracy and confidence, you can look at the source code any time you like.
3] How to "Drop invalid connections"
This is handled by the stateful functionality.
4] VLAN vs Interface rules
You can create floating rules that apply to multiple interfaces, in multiple directions.
5] Automatically populated black-list
This can be done via packages like Snort or Suricata (I believe), but I don't usually bother unless you have some NATs you're trying to protect. Just let the default deny rule on WAN drop those connection attempts.
-
@KOM Thanks for a swift response!
1, 2, 3 - Got it
4 - Aha! Completely forgot about these.
5 - Oh, thanks a lot. I haven't checked the packages yet. I see Suricata is multi-thread to that one i will definetly check. And yes i have several NATs which i want to protect a bit. Nothing fancy worth targeted attack but still better safe then sorry. Most of the portscan bots are hitting the well-known ports first (3389, 21, 22, 23, 25, 53, 8291, ...) so sending them to hell at the first occurrence successfully mitigates most of the random noise. And for the rest there are specific rules.Anyway thanks again for clarification. I can now proceed :]
-
Floating rules are powerful but they can also be confusing. I've seen many cases where somebody had an issue that turned out to be a floating rule that they forgot about or misinterpreted. From most cases I have seen, floating rules are more often used to match traffic for QoS purposes. Other uses usually involve advanced configurations. Unless you have many interfaces, it can be simpler to understand if you put your interface rules on the specific interfaces they apply to.