firewall rules...

RouterOS Beginner Basics
1

Hello,

I have some question:

My OpenWrt routers have per default about 20 rules for securing the WAN/LAN ports.
On most mikrotik tutorials I always saw that there are only few rules necasarry (see attached ruleset).

On OpenWrt invalid packets must be filtered seperatly - how does it work with mikrotik rulesets?

Whats about these rules?

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Will these rules automatically added on mikrotik routers in background?

I want to realize a router which should be able to restrict connections from inside to outside/dmz.
Where can I find some examples?

Best Regards

2

When constructing an outbound policy, it’s best to think “allow everything except ___”

I usually start a forwarding policy with rules to accept established and related connections. This way, your chains can get pretty complicated without adding too much performance overhead because the first rule matches the majority of packets under normal circumstances.

For anything more than a simple wan/lan router, I like to make custom chains for the different networks.
e.g. wanpolicy, dmzpolicy, lanpolicy, guestpolicy

I would make a simple rule matching in-interface to choose the correct policy chain:
add in-interface=LAN action=jump jump-target=lanpolicy

Now anything you want to enforce on lan1, you can add it to the custom chain without worrying how it will affect other networks such as DMZ. You could, for example, add a rule to block smtp on the Internet if you run a local mail server, and don’t want spam clients.

Make a rule:
add chain=lanpolicy protocol=tcp dst-port=25 action=drop

Or if you want to allow smtp to a specific server, but no others, add this in stead: (the ! means ‘not’)
add chain=lanpolicy protocol=tcp dst-port=25 dst-address = ! 190.0.2.25 action=drop

Custom chains also help you simplify your view of the firewall rules in winbox if you have more than just a few basic ones.
There is a drop-down selector at the top-right corner of the firewall window.
Changing this will filter the view of your rules to just the ones in that chain, and if you click + to add a rule, it will default to the selected chain.

Another nice thing about this methodology is that if you change the IP addresses used on the LAN, you don’t have to remember to change your firewall rules. The only criteria you used to determine it was a LAN client was the interface.

You may want to discard spoofed packets on an untrusted network. Suppose your GUEST network is 192.168.4.0/24:
add chain=guestpolicy src-address = ! 192.168.4.0/24 action = drop

Any rule that you want to apply to all policy areas would go in the main forward chain before the jump rules:
(block telnet)
add chain=forward protocol=tcp dst-port=23 action=drop


Obviously, firewall rule construction is a very big topic, and there are many different ways to accomplish the same thing. Some solutions are easier to read, some are easier to make changes without unintended side effects, some are more efficient, etc.

The most important thing is to learn how to “think like the router” and imagine a packet flowing through the rules in order until it finds the first one that matches every criteria.

3

I am a iptables-newbie. :wink:
Here I have a screenshot of my actually rules from my old router.

Could you please help me to implement this rules to my mikrotik-router?

How can fragmented packets be dropped with iptables?

4

Very easy.
There is a match criteria IP Fragment - it is in the “Extra” tab. Make a rule which has only IP Fragment selected, and action=drop.

5

Ok, thanks.

Where can I find informaton about rules which makes a firewall secure?

Are there some examlples of rulesets for mikrotik or iptables?

I always block all the traffic and then I set the rules for connection which are allowed. Why should the inverse way better?

6

Blocking all except allowed is better, security wise, for “input” and “forward”.

As far as “output” (a.k.a. “outbound”) traffic though… It’s just inconvenient. Presumably, you trust applications running on your router, considering they are by design all “from” the router, and not 3rd party ones, so it doesn’t make sense to both have a feature enabled, and then block it by the firewall. Whether you want a feature enabled/disabled, you’d do so from just one place, instead of two. On the other hand, some features might be hard if not impossible to disable for some reason, at which point it’s handy to use the firewall as a way to block the unwanted feature
=>
It’s more convenient and just as secure, to allow all except block when talking about the “output” chain.

7

Thanks.

I added all my rules from my old router and a rule which drops fragmented packets.

Which other rules should/could I add to raise the security?

Why there are no good and full examples of rulesets for mikrotik routers on the web?

Could anyone please post a typical WAN/LAN/DMZ1/DMZ2 ruleset? :slight_smile:

Thanks a lot.

8

Well, if you wanted behavior just like your old router as far as the policy wan->dmz, wan<-dmz, etc - you can do that by making chains. (I highly recommend it)

You can start by just creating the “default” rule for every combination and making sure that future rules go before these defaults, and then creating rules in the forwarding chain to jump into the various policies based on the interfaces…

/ip firewall filter
add comment="DEFAULT" chain=wan2lan action=drop
add comment="DEFAULT" chain=lan2wan action=accept
add comment="DEFAULT" chain=wan2dmz action=drop
add comment="DEFAULT" chain=dmz2wan action=accept
add comment="DEFAULT" chain=wan2guest action=drop
add comment="DEFAULT" chain=dmz2lan action=drop
add comment="DEFAULT" chain=lan2dmz action=accept
add comment="DEFAULT" chain=dmz2guest action=drop
add comment="DEFAULT" chain=guest2dmz action=accept
...
add chain=forward in-interface=ether1 out-interface=ether2 action=jump jump-target=wan2lan
add chain=forward in-interface=ether2 out-interface=ether1 action=jump jump-target=lan2wan
...

After this is built, you just put exceptions to the various traffic path default policies into those chains, making sure they’re before the one with the comment DEFAULT.

After adding a web server and mail server to your DMZ, the wan2dmz policy might have this as the full chain:

chain=wan2dmz protocol=tcp dst-ports=80,443 dst-address=192.168.10.10 action=accept comment="web server"
chain=wan2dmz protocol=tcp dst-ports=25,110,143 dst-address=192.168.10.20 action=accept comment="mail server"
chain=wan2dmz action=drop comment="DEFAULT"

I usually put a blacklist rule that checks address lists as the very first rule in the forward, input, and output chains:

/ip firewall address-list add list=BLACKLIST address=192.168.6.6
/ip firewall filter
add chain=input src-address-list=BLACKLIST action=drop
add chain=output dst-address-list=BLACKLIST action=drop
add chain=forward src-address-list=BLACKLIST action=drop
add chain=forward dst-address-list=BLACKLIST action=drop

Afterwards, if you see some attack coming from a particular IP, you can add it to BLACKLIST and it will immediately be dropped.

I also make sure that accept rules for established/related connections come right after the blacklist commands, for the sake of performance. (No need to check each-and-every packet against dozens of rules and criteria.) So consider most of your rules to be “how to handle new requests”

If you want to handle strange packets, like new TCP requests without SYN flag, put them between the “accept established” rule and the policy jumps, because you’re going to want that to apply everywhere.

I’m usually not too keen to go put so many such rules in force though because the general policy of “if you didn’t ask for it, throw it away” pretty much covers all of that stuff anyway. Dropping too much stuff in the name of security can even cause some things to break in a subtle way, for instance throwing away all ICMP will break pings, traceroutes, and little things like path mtu discovery that are pretty important, and quite obscure to novices.

9

Thanks, very much.

When I setup a DHCP client on the WAN interface, do I also must add the firewall ruleset for port 67/68 for a dhcp-request or will this rule added in background?

This video is also very helpful - https://www.youtube.com/watch?v=ulDefmf1ces

10

My WAN is assigned by DHCP.
I don’t have a specific rule to permit it.
It works because rule #1 on my input chain is add chain=input connection-state=established action=accept

Basically, my router requests DHCP, so that is “something I asked for” when the reply comes back from the DHCP server, and it gets accepted.

11

Ok, clear.
I only will permit requests outside via port 67 and the input on port 68, then I have “double security”. :wink:

But do you have a rule for outgoing DHCP request?

Is there a simulator available to check and simulate all firewall rules?
If the firewall rulelist has a lot of entries it’s possible to lose the overview.

12

You definitely speak the truth about firewall rule chains.
This is why it’s good to make custom chains and organize rules that way - plus you can improve performance because you can create 1 rule “in-interface=LAN” which goes to a complicated chain named LANPOLICY.
If a packet didn’t come from LAN, then no need to check 25 rules needlessly because it’s going to be 25 unmatched tests.
If you need to debug packets that start on LAN, set the view to show only LANPOLICY and let the debugging begin!


Interestingly, I do have a rule to permit DHCPv6 on my WAN interface in the ipv6 firewalls - it only has a few matches, though. I don’t think it’s necessary - I made a comment with today’s date and hits counters… it will be interesting to see if I never get any more matches on that rule.

13

Ok, fragmented packets can be filtered - see above.

What’s about other invalid packets? How can I filter these?

How can I realize a SYN-flood protection?

How can I realize a “fail2ban” protection - banning IPs for some time like fail2ban makes it?

14

First comment:
Simply dropping all fragments is bad practice. You’re more likely to break legitimate stuff with this rule than you are to protect the mikrotik from a 'sploit. (imagine a website that allows packet fragmentation, and sits beyond a low-mtu link on the Internet. You won’t be able to use it)

Second comment:
If you want to do all kinds of attack signature inspection, you should set up a snort server and give it an API link to add naughty sources to a blacklist, and keep the firewall rules simple.

However, if you want to do some failure rate auto-blocking to block hosts that do port scans…

Fail2ban Behavior:
Create two IP address lists: unbannable and blacklist.
The unbannable list is a list of hosts that should never get auto-blocked.
If someone realizes you have a fail2ban like this, they could start sending spoofed packets “from” some important sites (like your DNS servers) to random ports until your rule auto-blocks the DNS servers. (Yikes!)

blacklist = obvious. Make these the very first rules in their respective filter chains:

chain=input src-address-list=blacklist action=drop
chain=output dst-address-list=blacklist action=drop
chain=forward dst-address-list=blacklist action=drop
chain=forward src-address-list=blacklist action=drop

If you decide to set up a snort server, then stop here, and set up a way for the snort server to put addresses in the blacklist. (unbannable list would do nothing in this case, so delete it)

And now the hook - after your “accept connection-state=established,related” rule in the input chain, add these rules:

action=accept in-interface=!wan
action=jump jump-target=allowed-services connection-state=new limit=10,5
action=drop connection-state=invalid limit=5,2
action=drop src-address-list=unbannable
action=add-src-to-address-list address-list=blacklist log=yes log-prefix="blacklisting new host:"
action=drop

Notice the jump rule to jump to a new chain called “allowed-services”
This should be a chain of rules that match the ports you want to open services on (if any)
The last rule of this chain should be just “drop all”

example allowed-services chain:
action=accept chain=allowed-services protocol=tcp dst-port=80,443,8080,10000-11000
action=accept chain=allowed-services protocol=tcp dst-port=25 src-address-list=spamfilters
action=accept chain=allowed-service protocol=udp dst-port=53 src-address=1.2.3.4
...
action=drop chain=allowed-services

Syn floods:
There is an option that is off by default, called syncookies - You might want to read up on that to see if it’s a good option for you.

Honestly, I wouldn’t go this deep into packet rules.

15

Me again :wink:

How can I realize this rule on mikrotik webif?

iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP
16

chain=input
in-interface=ether1
protocol=tcp
connection-state=new
tcp-flags=!syn (in winbox, it’s in Advanced under TCP flags, select syn and tick the box with ! )
action=drop

17

This is a nice thread for newbies like me!

I have a question about port-forwarding.

1)
WAN (ether5) <==> DMZ (ether7)
port 80 ==> webserver 172.10.1.5
port 1024:65535 <== back to requestor

  • port 80 must be forwarded from ether5 to ether7
  • a valid http request must be answered by NAT rule (ether7 back to requestor)

2)
LAN (ether4) <==> WAN (ether5)
port 8080 ==> proxy-ip
port 1024:65535 <== proxy-ip

  • clients on LAN are allowed to use the proxy-forward
  • proxy must route requested packets back to the clients (this happens by NAT rule from LAN)

Which rules do I need?

3)
A ruleset with basic settings for securing a MikroTik router would be nice. The default rules by mikrotik (ether1=wan) are a little bit less and unsecure.
Do I find such basic rulesets on this forum?

4)
I saw some outgoing UDP packets on port 5678 in logfile (neighbour discovery) - referred to this thread: http://forum.mikrotik.com/t/port-5678-udp/17211/1
When I disabled it on my LAN ports I saw that this neighbour-discovery was disabled on ether1 per default (default WAN port).
I use ether5 as WAN port - are there some other “hidden” settings like this which should be disabled when I use any other port than ether1 as WAN port?

Markus

18

When it comes to NAT port mapping, you don’t need to specify the return path.
Any translation which gets made will be logged in a table in memory.
Packets are actually checked against this table before going to the chain - for efficiency.

So you would just make a rule that says in-interface=ether5 protocol=tcp dst-port=80 action=dst-nat to-addresses={web server internal IP}

don’t worry about the out interface.

If the proxy is explicitly configured in the browsers, then you don’t need any nat rules.
If you’re wanting to redirect people to it:
chain=dstnat in-interface=!ether4 protocol=tcp dst-ports=80 action=dst-nat to-addresses={web proxy} to-ports=8080

Make sure this rule comes after the web server pinhole rule because they both match dst-port 80, but proxy redirect rule says “not ether4” - ether5 would qualify as !ether4 also, so make sure that gets checked first. :slight_smile:

19

What is the difference between your suggest and the way to set a NAT destination rule like this one?
natdst.png
another question:

Why it is not possible to set an incoming interface for NAT?
nat.png
When I only want that ether1 and ether2 are allowed to use NAT I am not able to configure it.
nat2.png

20

Dstnat working with out interface
But srcnat not work with out interface
" tell you thats Base in nat "