I put this rules after switch on the Allow Remote Request function.
Now my doubt:
I put in drop the external request to port 53 and it’s clear the function of this rules, but what is the function of the rules in accept without any interface set ?
When You don’t set the port, the rule match all (any) ports.
So, if you want to drop UDP/53, you need to set protocol UDP and port 53. If you want to drop any UDP, you set protocol UDP and do not set port.
It is a good “catch all” UDP rule, to make sure nothing passes unless allowed first. The same goes to TCP.
Thanks for reply, but with my bad English I’ve post the wrong question. Please note that now I’ve edited the first post.
The right question is:
I put in drop the external request to port 53 and it’s clear the function of this rules, but what is the function of the rules in accept without any interface set ?
It works just the same: If you set an interface (let’s say eth1), then the rule only applies to it. If You do not set the interface, then the rule applies to all interfaces.
I would say that the accept rules you specified would be a bad idea to have on a real router connected to the Internet with a public IP address because sooner or later (usually sooner) it will be discovered as an open DNS relay and then utilized as a DNS amplifier in some DDoS attacks.
I didn’t read the Wiki article, but I assume that the context was a simple example of how to allow something using a firewall rule, and they just chose DNS because it’s a protocol that people are familiar with. It doesn’t necessarily mean that it’s a recommended setting.
OR - the rules in question appear later in the INPUT chain than other rules which would block DNS if it arrives on the WAN interface. In this case, a rule which allows DNS wouldn’t allow it from the WAN because some other rule already dropped the traffic.
EDIT 2:
I read the article, and it appears that the rules in this example would indeed allow all DNS. Personally, I don’t care for most firewall recipes that I see posted here and on the Wiki - I think people end up making rules that have 1001 ways to discard packets and it ends up just wasting CPU resources (which ultimately may limit the throughput capability of the router) when you could just as easily allow what you want and discard everything else, without all of these triggering rules to blacklist hosts.
Thanks for your reply.
I can understand your opinion but I remember that in the past I’ve tried for a friends to drop all on a Ubuntu desktop and put many accept but this was a very very very hard job.
And u are right about cpu usage, especially cause I’m setting up a mAP lite for a future trip job in China.
About this I’ve found another strange entry about basic rules. As I wrote before, my standard filter rules start with:
Yes, this is clear. Input, output, forward are different chain different sources and so on.
I can understand the drop of invalid, I also think that’s possible put a drop also in output…
But I put in accept something that can be dropped in another filter but I can’t found a filter that can block the established and the related in forward chain…
I think: any filter use CPU, so I put a specific accept filter only if another generic drop filter can block it.
It’s wrong my idea?
The default behavior of the firewall is ACCEPT. If it makes it to the bottom of a chain the packet is accepted or allowed to pass.
Your assumption is correct, if you have a broad (generic) drop rule that needs exceptions to allow your traffic to flow correctly then you need to create a rule and place it above the broad (generic) drop rule.
Additionally, each rule does impact the performance of the router, particularly visible by the CPU. Some things to consider:
Accept the largest portion of your traffic as early as you can in your rules. This prevents the router from checking 15 rules only to get to the one to allow it.
Leverage the RAW firewall filter if possible. This can increase performance by blocking or accepting some traffic before it hits the connection tracking engine. This does have drawbacks, particular around fragmentation as the Wiki warns.