Don’t feel like reading a lot of text? Just take a look at the screenshot and tell me if it looks ok.
I bought a MikroTik RB750 a few years ago, basically just because it was cheap and I wanted something to experiment with. I have never before or since seen such a small and cheap device with so many configuration options, great! But at the time I thought it was a bit too complicated, compared to my PC-based m0n0wall router (been using m0n0wall for the last 12 odd years) and after a while the RB750 ended up in a drawer. However, power isn’t cheap and I recently felt the need to replace my 40+ watt PC-based router with something less power hungry and so I dusted off the MikroTik.
I’ve got everything working, but am a little concerned about security, since RouterOS isn’t as straightforward and user friendly as m0n0wall.
I want to know if my setup looks safe based on the firewall rules, if there is something I ought to or could do differently and if there are other settings than the firewall I should think about. I’ve also created rules to block private addresses from the outside, but I’m not sure whether I should use the forward or input chain for that. Any comments and tips are welcome.
My network:
WAN connection connected to ether1-gateway, IP via DHCP from my ISP.
My wired LAN (lan1) is connected to ether2-master-local and my wireless network (lan2) is connected to ether3-master-local. lan1=192.168.100.0/24, lan2=192.168.110.0/24
Looks good to me. You could possibly pare it down a touch to get the same policy but with a few less rules, but that’s not a big deal.
Nice work.
One feature you might be interested in is the address-list feature of the firewall.
You can define lists of IP addresses/ranges as named lists, and then use the lists in your firewall rules, so only one rule can match several possible addresses/ranges all at once. The address-list uses a fast lookup, so it becomes helpful in larger sets of addresses.
e.g. your 3 rules to block RFC1918 space could be a single rule:
Thanks for the reply! Read it, but was rather busy and then sort of forgot about it.
Nice tip with the address-lists, didn’t know that.
One more question; what’s the difference between established and related traffic? On the input chain I accept only established, but on the forward chain I noticed I had to accept both established and related in order to get things to work properly.
Connection state tracking is based on a table that the Mikrotik uses to keep track of everything flowing to/through the router.
If a packet comes through, and it’s being transmitted between a pair of hosts between which the router hasn’t noticed any traffic before (this also includes the src/dst ports as well as the src/dst addresses), then the router adds a new entry to the tracking table, and this packet which caused the new entry is considered to be in the “new” connection tracking state.
When the first reply packet comes back to the sender, the router will notice this and change the state of the connection from “new” to “established”
Some services make use of multiple connections between the same hosts, but on a new port number (sometimes even different hosts) and this new connection is based on something that happened in the other “established” connection. The classic example is FTP, which makes one TCP connection to port 21 for ‘control session data’ (the login itself, and the commands from the client to the server, and the response codes from the server to the client), and also makes additional ‘data stream’ connections to the server for the actual file transfers. These data stream connections are new connections, but related to the already-existing control session connection, so these data connections are ‘related’ state. Another common ‘related’ connection type is the RTP streams (voice payload) in VoIP (SIP, MGCP, H.323) applications - and it’s not unusual for VoIP to make the RTP connections to completely different IP addresses than the SIP messages’ endpoints. These are also RELATED connections. Also, ICMP error messages from routers for things like “TTL exceeded” or “host unreachable” or (importantly:) fragmentation required… these are all related to whatever packet caused them to be generated.
You can actually check ‘established’ and ‘related’ on the same rule, which means that if either is true, the ‘connection state’ condition will evaluate as ‘true’ for that packet. This is probably faster than using two separate rules (but I’ve never tried to benchmark this).
Invalid state is pretty much just useful for TCP (if I recall correctly) because TCP has its own connection state information, and if the Mikrotik sees a TCP header with state information that doesn’t match the Mikrotik’s state tracking table data, then the packet is considered ‘invalid.’ For example: a ‘new’ TCP connection is observed, and the first packet doesn’t have SYN flag set, this causes the Mikrotik to consider this ‘invalid’ state.
