It's hard to make everyone happy. I like block-by-default config better, but it's just one opinion. I think it's safer, but someone else might see it as annoying. Default config needs to find the right balance, be reasonably safe but not obtrusive. Current default config makes you safe from unwanted stuff from internet, that's the most important part. And when you add another LAN/VPN/etc, things "just work". With block-by-default config, they wouldn't. At least it would look that way to many people, some might even think that the router is broken, flood support with questions or complaints, ...

@squeeze: In case the interface list is supposed to contain all vlans, it would be possible to skip it and use the magic "all-vlan" value (in-interface=all-vlan out-interface=all-vlan).

Sob I think you are saying you like Squeezes rule but only if it includes all VLANs on his list. If this is not what you meant, what what rule would you use then?

@anav: You don't need extra WinBox blocking rule, because you open its port only to admins and connection attempts from elsewhere will be dropped by last rule. Port scanning rule should go after accepting established connections, because what it looks for will have connection-state=new (or perhaps invalid). If it's first, you're wasting (a little bit of) resources on checking packets that will be allowed by established rule anyway, just a moment later. And you don't want to limit established to tcp only.

OKAY SO, we can dispense with the WINBOX rule (overkill) and move the port scanning rule after established connections.

I keep forgetting about untracked, because it's relatively new in RouterOS and nothing becomes untracked unless you tell it to be (in raw), so if you don't do that, you don't need to allow it, because there will be none.

So to confirm you are saying we don't really need to state untracked (a very rare case only under our control - would require additional rules)

If you're not aiming for super-secure, I usually allow any input from LAN, because I trust it. If you don't, you can allow only tcp/udp 53 for dns (from LAN only, definitely not from WAN, it would make the router open resolver).

I am unsure on this one. Are you saying this for the INPUT CHAIN or for the FORWARD CHAIN?
If the former then you would want to see this rule vice the plain jane drop everything input chain rule??
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN

With regard to DNS, would you be happy with this then as the only required rules placed in the FORWARD CHAIN before the drop everything rule.
add action=drop chain=forward comment=" BLOCK DNS from wan side \
dst-port=53 in-interface=WAN protocol=udp and one for TCP as well

About icmp, I don't believe that being "invisible" by blocking icmp makes you any more secure, so I allow it. But opinions differ, some people think that it's good or even important. And in a way they are right. In theory it's possible that someone discovers a nasty bug that allows to bring the router down by sending a special icmp packet. It's highly unlikely, but not completely impossible. If that ever happens, icmp blockers will laugh at me and say "we told you!", but until then I'll enjoy the advantages, e.g. being able to quickly see if the router is alive, no matter where I'm currently connected.

So basically I only need the one rule at the end of my INPUT Chain accept rules, before the drop rules?
add action=accept chain=input comment="Allow PING" protocol=icmp

So to confirm you are saying we don't really need to state untracked (a very rare case only under our control - would require additional rules)

Okay new and improved Version.............

Code: Select all

/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept established 
	and related connections" \ connection-state=established,related 
	protocol=tcp
add action=accept chain=input comment=\  ALLOW list admin access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat**
add action=drop chain=forward comment="Drop everyting else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other 'black lists'" \
    dst-address-list=blacklists or country lists etc........

Questions??
1. What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp

2. Do I need any special rules for DNS in forwarding???
3. Do I need any output rules, never seen one but what can be done here???

1. What is the difference (which is better) between these two INPUT chain rules..?
a. add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
b. add action=accept chain=input connection-state=established port=53 protocol=tcp

2. Do I need any special rules for DNS in forwarding???

/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<routers.address>"
/ip firewall nat add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses="<routers.address>"

3. Do I need any output rules, never seen one but what can be done here???

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

If a host doesn't get a response from a UDP DNS query, it will retransmit the request over TCP.

Code: Select all

/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<routers.address>"
...

/ip firewall nat add chain=dstnat protocol=udp dst-port=53 action=redirect

Special note to anav, this thing is entirely optional and I'd say only needed for special circumstances. Feel free to ignore it. And this note is not meant as anything against MangleRule.

when you state to addresses <routers address>did you mean the LANIP of the subnet?

This will force users to use Router selection?
Is this necessary?

What affect will this NAT rule have on any ROUTE rules where the router has to attempt to resolve a domain name for example........ no affect because the rules do not affect the router itself??

redirect - replaces destination port of an IP packet to one specified by to-ports parameter and destination address to one of the router's local addresses

What affect will this NAT rule have on any ROUTE rules where the router has to attempt to resolve a domain name for example........ no affect because the rules do not affect the router itself??

So the rules I listed above will have no effect on the router's self resolution for DNS.

First part is optional, you can skip to-ports and port will stay the same. But second part is the main point of action=redirect, it always changes destination to router's own address without a need to give a specific one.

They will have to use the DNS options I have setup in the router?

If its the default for lan clients to go out their respective gateway why do I have to make this rule?

I do have some scan rules for INPUT chain add to address list, and drop them in raw.
Is there ever a case for scan or spam rules for FORWARD chain add to address list? Could RAW be used to drop them as well?

Finally: Brain fart is there a reason why there is no DROP invalid rule on the INPUT Chain??

Interesting mangle.
What do you recommend for dos type scenario.
Option 1: tarpit input chain traffic - something about changing data package size being sent - not sure how it does this and to what traffic incoming or returning? Net effect I am told is slowing down the incoming?
Option 2: Drop input chain traffic with RAW hammer.

Practically speaking both options have to do the same initial step of identifying incoming traffic by some mechanism? Probably a combination of period of Time and number of connections?
I'm assuming the EXTRA page comes into play but what makes sense for setup? After detection then the offending IP is added to an address list for xx hours or days etc........
The first option upon detecting an IP on the list applies TARPIT action on it.
The second option upon detecting an IP on the list RAW drops it.

Thus, it boils down to how to effectively identify and capture such traffic and secondly what is more effective, tarpit or raw drop?

So are you saying dont bother with such rules??
Regardless I am interested in how one would identify such trafffic using the mikrotik,,,,,,,, what combination of time and connections in the extra page would do the trick...........

So are you saying dont bother with such rules??
Regardless I am interested in how one would identify such trafffic using the mikrotik,,,,,,,, what combination of time and connections in the extra page would do the trick...........

Okay last time I will list the list on this thread...........
One question though remains, when looking at the TO address for the NAT DSTNAT rule for DNS,
How would I best handle the fact that I would have multiple router LANIP gateway addresses.
Consider each LAN or VLAN will have its own gateway?
One cannot use a LIST for to addresses ?

Okay last time I will list the list on this thread...........
One question though remains, when looking at the TO address for the NAT DSTNAT rule for DNS,
How would I best handle the fact that I would have multiple router LANIP gateway addresses.
Consider each LAN or VLAN will have its own gateway?
One cannot use a LIST for to addresses ?

Code: Select all

/ip firewall filter
{INPUT}
add action=accept chain=input comment="Accept Good Traffic 
	\ connection-state=established,related
add action=drop chain=input connection-state=invalid  comment="No one noticed this was missing you cads!! ;-)"
add action=accept chain=input comment="ALLOW list access to Router (all ports)
    \ src-address-list=allow
add action=add-src-to-address-list address-list=Port_Scans \
    address-list-timeout=days chain=input comment="Your typical port scanning input rule"\
    protocol=tcp (and one for udp)
add action=accept chain=input in-interface=LAN protocol=tcp dst-port=53
add action=accept chain=input in-interface=LAN protocol=udp dst-port=53
add action=accept chain=input comment="Allow PING" protocol=icmp
add action=drop chain=input comment="Drop everything else for INPUT CHAIN"

{FORWARD}	
add action=accept chain=forward connection-state=established,related
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward in-interface=mainLAN out-interface=WAN
add action=accept chain=forward in-interface=guestLAN out-interface=WAN
add action=accept chain=forward connection-nat-state=dstnat
add action=add-src-to-address-list  addresslist=scan-spam  chain=forward \
	comment="ports and protocol as necessary" 
add action=drop chain=forward comment="Drop everything else for FORWARD CHAIN
	
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
    ipsec-policy=out,none out-interface-list (assuming two WANs)
add action=dstnat - port forwarding rules as required here**
add chain=dstnat protocol=udp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router> (like 192.168.0.1)
add chain=dstnat protocol=tcp dst-port=53 action=dst-nat to-addresses="<gatewayLANIP of router>

/ip firewall raw
add action=drop chain=prerouting comment=Drop your typical input port scan list created" \
    src-address-list=Port_Scans
add action=drop chain=pretouting comment="Drop any other input 'black lists'" \
    src-address-list=blacklists or country lists etc..........
add action=drop chain=pretouting comment="Drop any forward scan-spam traffic"\
    scr-address-list=scan-spam

if each vlan has its own gateway which is the router why not use the router as your DNS server and allow incoming traffic on each vlan to destination port 53/udp (the router) otherwise just allow incoming on each vlan with destination any udp/53 and in nat create from source desired vlan for all traffic going to destination 53/udp masquerade or src-nat so they can query 4.2.2.2, 8.8.8.8 or whatever they wish . it's up to you, i preffer having dns on the router less queries going out and faster response from cache.

if each vlan has its own gateway which is the router why not use the router as your DNS server and allow incoming traffic on each vlan to destination port 53/udp (the router) otherwise just allow incoming on each vlan with destination any udp/53 and in nat create from source desired vlan for all traffic going to destination 53/udp masquerade or src-nat so they can query 4.2.2.2, 8.8.8.8 or whatever they wish . it's up to you, i preffer having dns on the router less queries going out and faster response from cache.

The whole purpose of the dst-nat rules he is talking about IS to force the use of the MikroTik as the DNS server for the network. Masquerade has nothing to do with this because Masquerade is using src-nat. We need to use dst-nat to change the DNS server destination to the MikroTik, using redirect with do that nicely as listed above.

And i do know how snat and dnat work, thank for the explanation though.

Mikrotik firewall is very basic when used to working with iptables.

DNS queries work over 53/udp, tcp is only used for zone transfers, first rule is correct second is wrong if you only accept established connections all new will be dropped, you can do output same as input just make sure to create an outgoing accept rule in output chain for connections related, established or you wont be able to respond to incoming traffic. DNS forwarding is just allow outbound NAT or forward to remote 53/udp.

If a host doesn't get a response from a UDP DNS query, it will retransmit the request over TCP.

Great news SOB, i implemented a variation of your rules with some others and despite having my IP Routes reachable on both internet and email, I dont have internet or email connectivity LOL.
I am trying to figure out why but dont see anything obvious. If I get desperate I will ask for help............

Great news SOB, ...

Great news SOB, ...

Hey, my nice name isn't turning into significantly less nice acronym, is it? It would break my heart!
Yes it was a play on Words x3
But ok, I probably should have mentioned that it's good idea to first add a logging rule at the end, and only when it doesn't catch something that's not supposed to be there, change it to drop/reject rule.