Community discussions

MikroTik App
 
ukzerosniper
Member Candidate
Member Candidate
Topic Author
Posts: 129
Joined: Tue Jul 23, 2013 9:20 pm

Firewall filter rules for DNS

Sat May 31, 2014 3:46 pm

Hi Guys,

I am trying to configure it so that the outside world cannot access our router for DNS but everything on our LAN can.

I have setup filter rules as follows. However this results in nothing being able to access DNS on our router.

Oddly if I disable rule 5 DNS works everywhere.

I feel like i'm running in circles, any help you can provide is greatly appreciated.

Thanks.

/ip firewall filter> print
1 chain=input action=accept protocol=tcp in-interface=ether9 - LAN1 src-port=53
2 chain=input action=accept protocol=udp in-interface=ether9 - LAN1 src-port=53
3 chain=input action=accept protocol=udp in-interface=ether10 - LAN2 src-port=53
4 chain=input action=accept protocol=tcp in-interface=ether10 - LAN2 src-port=53
5 chain=input action=drop protocol=udp in-interface=ether1 - WAN1 src-port=53 dst-port=""
6 chain=input action=drop protocol=udp in-interface=ether2 - WAN2 src-port=53 dst-port=""
7 chain=input action=drop protocol=tcp in-interface=ether1 - WAN1 src-port=53 dst-port=""
8 chain=input action=drop protocol=tcp in-interface=ether2 - WAN2 src-port=53 dst-port=""
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sat May 31, 2014 4:09 pm

You need to match the dst-port, and not the src-port.
 
ukzerosniper
Member Candidate
Member Candidate
Topic Author
Posts: 129
Joined: Tue Jul 23, 2013 9:20 pm

Re: Firewall filter rules for DNS

Sat May 31, 2014 4:13 pm

Thanks for the reply.

On all rules?
 
ukzerosniper
Member Candidate
Member Candidate
Topic Author
Posts: 129
Joined: Tue Jul 23, 2013 9:20 pm

Re: Firewall filter rules for DNS

Sat May 31, 2014 4:21 pm

The block rule is working so i have made not changed it (at this time).

/ip firewall filter print
Flags: X - disabled, I - invalid, D - dynamic
1 chain=input action=accept protocol=tcp in-interface=ether9 - LAN1 src-port="" dst-port=53
2 chain=input action=accept protocol=udp in-interface=ether9 - LAN1 src-port="" dst-port=53
3 chain=input action=accept protocol=udp in-interface=ether10 - LAN2 src-port="" dst-port=53
4 chain=input action=accept protocol=tcp in-interface=ether10 - LAN2 src-port="" dst-port=53
5 chain=input action=drop protocol=udp in-interface=ether1 - WAN1 src-port=53 dst-port=""
6 chain=input action=drop protocol=udp in-interface=ether2 - WAN2 src-port=53 dst-port=""
7 chain=input action=drop protocol=tcp in-interface=ether1 - WAN1 src-port=53 dst-port=""
8 chain=input action=drop protocol=tcp in-interface=ether2 - WAN2 src-port=53 dst-port=""

This is my new config, I still have the same issue.
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sat May 31, 2014 4:39 pm

On all rules... yes...
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Firewall filter rules for DNS

Sat May 31, 2014 5:30 pm

Simply add:
/ip firewall filter
add chain=input in-interface=<input-wan-interface> protocol=tcp dst-port=53 connection-state=new action=drop
add chain=input in-interface=<input-wan-interface> protocol=udp dst-port=53 connection-state=new action=drop
for each of your WAN
 
ukzerosniper
Member Candidate
Member Candidate
Topic Author
Posts: 129
Joined: Tue Jul 23, 2013 9:20 pm

Re: Firewall filter rules for DNS

Sat May 31, 2014 6:15 pm

and discard my other rules?
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sat May 31, 2014 6:27 pm

and discard my other rules?
That would be the most compact way (which by virtue of being compact is also efficient), yes.

Although IMHO, it would be best (maintenance wise) to whitelist your local interfaces, and drop everything else, i.e.
/ip firewall filter
add chain=input protocol=tcp dst-port=53 action=accept in-interface=LAN1
add chain=input protocol=udp dst-port=53 action=accept in-interface=LAN1
add chain=input protocol=tcp dst-port=53 action=accept in-interface=LAN2
add chain=input protocol=udp dst-port=53 action=accept in-interface=LAN2
add chain=input protocol=tcp dst-port=53 action=drop
add chain=input protocol=udp dst-port=53 action=drop
If you had only a single local interface (even if it's a bridged one - just... have it be one), you could've most easily just have the following two rules
/ip firewall filter
add chain=input protocol=tcp dst-port=53 action=drop in-interface=!LAN
add chain=input protocol=udp dst-port=53 action=drop in-interface=!LAN
(which would be both efficient and easier to maintain)
 
ukzerosniper
Member Candidate
Member Candidate
Topic Author
Posts: 129
Joined: Tue Jul 23, 2013 9:20 pm

Re: Firewall filter rules for DNS

Sat May 31, 2014 6:49 pm

Simply add:
/ip firewall filter
add chain=input in-interface=<input-wan-interface> protocol=tcp dst-port=53 connection-state=new action=drop
add chain=input in-interface=<input-wan-interface> protocol=udp dst-port=53 connection-state=new action=drop
for each of your WAN
This works perfectly.

Can you explain a couple of items so that I understand why yours works and mine did not.

I notice the difference is that you chose connection state new and destination port.

What is this rule saying/doing that mine wasn't?

Thanks.
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sat May 31, 2014 8:08 pm

This works perfectly.

Can you explain a couple of items so that I understand why yours works and mine did not.

I notice the difference is that you chose connection state new and destination port.

What is this rule saying/doing that mine wasn't?

Thanks.
The key is the dst-port. It's what the "input" chain matches, while in "output", it would've been the "src-port", but THAT rule would be pointless... But in more detail:

Let's say we have two devices - "A" and "B".

When "A" connect to "B" via TCP or UDP, it needs to connect to a particular port on "B". In order for "B" to respond back to "A", "A" (kind of) creates a temporary server on itself, at a random port, where it waits for response from "B", until the connection is over for one reason or another. "A" sends that temporary port to the port on "B" from which it wants answers, and similarly, when "B" answers, it puts the original port to identify itself.

So what's happening is that the in-interface receives the following message
"I'm looking for <server IP>, and I'm <client IP>. I'd like to ask <server port> to answer me on <client port>. Can you do that please?"
and if the server decides to respond, that same interface would send back a packet that would mean
"I'm looking for <client IP>, and I'm <server IP>. I want to tell <client port> that I can indeed answer its requests to <server port>."

And here's the tricky part... when a router ("B") sees the first message (AND <server IP> is its IP address on in-interface), it assigns it on the "input" firewall chain, where the "src-address" is the address of the device that looked for it ("A"), the "src-port" is the source where the device wants answers, and "in-interface" is the interface where the packet came from. The router's IP that the client wants is the "dst-address", and the port that it wants answers from is the "dst-port".

If the packet is accepted, the router proceeds to answering, at which point, the "output" firewall chain is triggered, where the src-* and dst-* stuff are reversed, and the "in-interface" is now actually the "out-interface".


As for the connection state... It doesn't really make a difference here, but in theory, you could for example allow an initial exchange like above, but then forbid the actual data from being given. If you omit the connection state, the router will not bother answering on any event. With connection-state=new, if the client claims to have already been connected previously, the router will check whether that's true, and answer if so. Since new connections are forbidden, it will fail to see that's true, and thus not answer. So... yeah... it won't answer in any event either way.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Firewall filter rules for DNS

Sat May 31, 2014 9:26 pm

If "my way" are used, specifyng "NEW", not legit DNS reply request FROM INTERNET is blocked.

Usually one DNS query are (from RB input/output point of view):

1.2.3.4:34473 UDP device request -> 5.6.7.8:53 UDP RouterOS receive
5.6.7.8:34526 UDP RouterOS Request new packet -> 8.8.8.8:53 UDP Receive
8.8.8.8:53 UDP Reply (new packet RELATED on one ESTABILISHED virtual connection-> 5.6.7.8:34526 UDP Receive
5.6.7.8:53 UDP reply to device -> 1.2.3.4:34473 UDP device receive

source port can vary, the fixed port is the destination port
for example source port vary if a device are natted and the request go directly to 8.8.8.8 (on forward point of view):

192.168.88.7:32345 UDP request packet send -> NAT -> 5.6.7.8:32666 UDP src masquerade -> 8.8.8.8:53 UDP receive request
8.8.8.8:53 UDP reply -> 5.6.7.8:32666 UDP -> connection tracking dst masquerade -> 192.168.88.7:32345 UDP device receive

From Internet the reply ESTABILISHED/RELATED connections must pass.
Only the NEW (unsolicited) connection from Internet must be blocked.

The source port CAN BE 53.

EDIT: remove too much "not" and extended the example for remove misunderstand.
Last edited by rextended on Sun Jun 01, 2014 12:31 am, edited 2 times in total.
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sat May 31, 2014 9:40 pm

If "my way" are not used, not specifyng "NEW", also legit DNS reply FROM INTERNET is blocked.

Reply must go to RB, or can not solve DNS query.
You're wrong.

Try it my way, and clear your DNS cache, to see your clients successfully filling it back up. I tried it with my router just now (just in case you had a point...), and as expected, it still works flawlessly.

I assume that by "to", you mean as in "Device sends a DNS query to ROS, ROS sends a query to another DNS server, the other DNS server answers to ROS, ROS answers device"?

When ROS does that, it will use a different UDP/TCP port as the source port of its DNS query, and will use 53 as the destination port of the remote device. Therefore, the legitimate DNS reply will never be matching rules with dst-port=53, but will instead use as dst-port whatever ROS gave as its src-port upon making the DNS query. Why will ROS do that? Because it can't receive replies on the same port is expects requests from. In other words, the DNS client and DNS server are two different services.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11968
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Firewall filter rules for DNS

Sun Jun 01, 2014 12:32 am

I expand the previous post, on the way to explain better what I want to write...
 
User avatar
boen_robot
Forum Guru
Forum Guru
Posts: 2400
Joined: Thu Aug 31, 2006 4:43 pm
Location: europe://Bulgaria/Plovdiv

Re: Firewall filter rules for DNS

Sun Jun 01, 2014 5:33 pm

source port can vary, the fixed port is the destination port
Right. When RouterOS sends a DNS query, the dst-port (in the "output" chain) is fixed to 53 (because that's where RouterOS sends DNS queries to), but the src-port varies. When you get a reply to a DNS query that you've sent, you receive it on the "input" chain with src-port=53 (because that's the port you're receiving a reply from), and the dst-port varies depending on what RouterOS chose when sending the DNS query.

So... if you ONLY have rules matching the dst-port on the "input" chain, you'll still be able to accept replies from DNS queries that RouterOS sent, because the dst-port of DNS replies that come in can be anything OTHER than 53, since 53 is where DNS requests would come in.

=>

The above rules are sufficient even without connection-state=new, and don't prevent DNS replies from coming in. They only prevent DNS requests from coming in. If one wants to prevent DNS replies from coming to the router, they'd need to check the "input" chain for src-port=53.
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: Firewall filter rules for DNS

Tue Jun 03, 2014 10:56 pm

I agree with boen-robot. I am blocking all input packets to port 53 from wans without any impact on the dns service provided to inner networks.

Who is online

Users browsing this forum: duartev, menyarito, morphema and 52 guests