How can I do a closed firewall on mikrotik router OS?
Today my gateway is a freebsd and the politic of the firewall is “closed”, I’ve used a dynamic rules on freebsd to accept the conections started on my servers address.
Now I’m replacing the server with a RB1000 and I want to keep the firewall rules.
‘input’ contains all packets destined for the router. You want to permit everything from the LAN, permit all statefully established traffic and drop everything else.
‘output’ contains all packets generated by the router. You want to permit those, and that’s the default so no rules are needed
‘forward’ contains all packets flowing through the router. You want to permit everything from the LAN, permit all statefully established traffic and drop everything else.
Here a quick ruleset, assuming the WAN interface is named ‘outside’ and the LAN interface is named ‘inside’.
Ultimately, you dont want to permit everything as input from the LAN. Restrict it to necessity and silently drop the rest. IE: You might want the telnet server enabled over a VPN tunnel, but no telnet access from the LAN. Or dude over vpn, but not LAN. Protecting the firewall is just as important as protecting the LAN.
And he said a “closed” firewall, so I would imagine he meant restricting connections to certain ip/port pairs or using the proxy. In this case, allowing in lan, out wan, src lan-ip subnet, dst, ip/port pair, state = new.
Always use state = new on allowed input and forwarded connections. Not doing this negates the “stateful” nature of the firewall.
Always allow input and forward of established/related connections. Typically one of the earliest rules before any jumps and most importantly before the default deny input/deny forward rules at the very end.
In FreeBSD ipfw rules I’ve an option called ‘ME’. With this option I can refer all IP address configurated on the server and I don’t need to create a firewall rule for each IP address of the machine.
Are there some rule like this on the Mikrotik RouterOS firewall?
There’s a filter action for source and destination address types:
dst-address-type (unicast | local | broadcast | multicast; Default: ) Matches destination address type:
unicast - IP address used for point to point transmission local - if dst-address is assigned to one of router’s interfaces
broadcast - packet is sent to all devices in subnet
multicast - packet is forwarded to defined group of devices
src-address-type (unicast | local | broadcast | multicast; Default: )
Matches source address type:
unicast - IP address used for point to point transmission local - if address is assigned to one of router’s interfaces
broadcast - packet is sent to all devices in subnet
multicast - packet is forwarded to defined group of devices
But you can also use the chains:
There are three predefined chains, which cannot be deleted:
input - used to process packets entering the router through one of the interfaces with the destination IP address which is one of the router’s addresses. Packets passing through the router are not processed against the rules of the input chain
forward - used to process packets passing through the router
output - used to process packets originated from the router and leaving it through one of the interfaces. Packets passing through the router are not processed against the rules of the output chain
‘input’ must necessarily have a destination IP address residing on the router, ‘output’ must necessarily have a source IP address residing on the router.
If the MT has more than one address on an interface and you want to allow input on one address and not the other, you would specify a dst-address. If the you just want to block all input on the interface, you would deny in-interface=etherX. If you want to deny all input on all interfaces and all ips, dont specify an in-interface or dst-address.
You dont need to explicitly specify an ip address or interface. Absence of either one = all interfaces or all ip address.
Right. Sorry if I was unclear in my above statement. I meant that an IP flow in the ‘input’ chain will have a destination address field with a value of an IP address that resides on the router, and an IP flow in the ‘output’ chain will have a source address field with a value of an IP address that resides on the router. It is not necessary to refer to them in any of the rules in the chains, like you said. But if you need to determine whether or not an IP flow is destined to or sourced from the router you can use the ‘input’ and ‘output’ chains, alternatively you can use src-address-type=local and dst-address-type=local in other chains that may be jumped to.