Secure rule for IoT?
-
Hi,
I have set up 3 rules for my IoT network and would to like some comments if they are good or can/should be improved or is redundant;
Source: IoT, Destination: !This Firewall
Source: IoT, Destination: !RFC1918
Source: IoT, Destination: Any, Port: 80 (HTTP)This should block any communication to the firewall as well as to any private networks and only (for now) allow HTTP. I guess the second rule may cause IoT devices not to communicate with each other... If that is called for, how would this be adjusted to allow that and still be secure?
Thanks
-
@furom said in Secure rule for IoT?:
I guess the second rule may cause IoT devices not to communicate with each other
On the same network? pfsense has nothing to do with communication between devices on the same network. Doesn't matter what rule you place on pfsense, it is not evolved with devices on the same network talking to each other..
Also if those are allow rules, your other 2 rules are pretty pointless since your first rule would allow access to anything that is not a firewall IP. Local or not.
Its not really a good idea to use invert or bang rules - if you don't want stuff talking to firewall IPs, then use a block/reject rule to firewall IPs. If you don't want stuff talking to rfc1918 then use again specific block/reject rule to those IPs. Then use a any any rule to allow access to what you want.
Here is example rules for an iot sort of network, that blocks access to firewall IPs, other than icmp and dns, ntp.. Blocks access to any other local network via a rfc1918 alias, etc.
BTW as your rules are written, you wouldn't be able to use pfsense for dns.. only external. Or some other local dns that is not a firewall IP.. Since your first rule there allows anything that is not a firewall IP.
The "this firewall" rule is mostly there to block access to the wan IP of the firewall, since most of the time this would be a public IP, and could change.. The block rfc1918 would block all other access to other firewall interfaces (that are rfc1918).. But being very explicit in your rules is never a bad thing. Even if you get some duplication of rules. Could just call out the wan address in that rule. But it makes it clear to read that hey this network can not talk to any firewall IP. And would also block if you brought up more than one wan interface, or create a public vip on the wan, etc. etc.
-
@johnpoz This clears up a lot. I thought as you caught for example that RFC1918 also would block vlan-internal traffic between devices too, but now know better.
Agreed, it seems to be best practice to better to be explicit, perhaps also easier over time to see whats going on. I appreciate this, very helpful! :) Thanks -
@furom bang rules do have uses in specific use cases. And could be used as a shortcut sort of rule.
But the point about easy to read is really a good one - looking at your rules when you are very specific does make them easier to read for sure..
Always a good idea to run through your rules with a specific example of the traffic, what its source is and where its trying to go, and see what your rules would do with that example traffic.
Top down, first rule to trigger wins no other rules evaluated.
Also suggest while it might seem like a shortcut to just use the floating tab to create rules for multiple interfaces.. In the long run for ease of reading, and less likely to make mistakes is put your rules on the interface directly vs using floating tab.
The floating tab should be left for specific OUTBOUND rules only when your use case calls for such a need, which really shouldn't be all that often, etc. Most setup prob never need any rules in floating. This way your sure when looking at your rules, that your interface tab is all you need to take into consideration.
-
@johnpoz Yes, I must admit I have been tempted to use floating rules, but as you say, to get the overview and control I should take the longer road, especially since I am learning and want to get things more right than wrong... :) I did see a recommendation to create a reject as floating on WAN with destination RFC1918, feels ok to know things stay within the firewall at least.
I'm just scratching on the surface, but so impressed with it so far! :)To actually test the setup when "done", would there be a recommendation, such as using nmap or similar?
-
@furom well you could always test by trying to create connects your rules should block and set them to log and see if the block is logged, etc.
But to be honest I have never seen an issue where rules were not what they say they are.. If having problems with say block rules not working - most likely an existing state that is allowing, etc.
Being a good netizen I have an outbound rule to block rfc1918 that shouldn't go to the isp, ie if I typo something locally or something.. If there is no local network your trying to get to, then yeah pfsense would route that out the public internet, wouldn't get very far ;) But sure if you don't want to send such possible noise to your isp you could create an outbound block rule in floating for the rfc1918 space..
