Community discussions

MikroTik App
 
daviddem
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 62
Joined: Sun Sep 18, 2011 12:16 pm

Q about Dmitry on firewalling

Fri Dec 30, 2011 4:33 pm

add chain=sanity-check in-interface=Public dst-address-list=!local-addr action=jump jump-target=drop \
    comment="Drop everything that goes from public interface but not to local address" disabled=yes
#check this well! The above rule is for not nat-ed hosts!
I am stuck on this one. Why would this rule be wrong if we are on a NATed host? Does Dmitry mean a host performing NAT for the local network, or a host part of an already NATed network?

I can't figure in which case this rule would cause trouble?

(I also assume he means "everything that enters from the public interface", rather than "goes from the public interface", since in-interface is set to "Public")?
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 7038
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: Q about Dmitry on firewalling

Mon Jan 02, 2012 11:39 am

As I understand it, on NATed network destination address for packets coming into wan port is always router's public address, so mentioned rule cannot be used since it will drop every packet.
 
daviddem
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 62
Joined: Sun Sep 18, 2011 12:16 pm

Re: Q about Dmitry on firewalling

Mon Jan 02, 2012 2:37 pm

As I understand it, on NATed network destination address for packets coming into wan port is always router's public address, so mentioned rule cannot be used since it will drop every packet.
OK, I think I got mixed up by this (from the Wikipedia article on NAT):
When a reply returns to the router, it uses the connection tracking data it stored during the outbound phase to determine the private address on the internal network to which to forward the reply.
and this (from the freeBSD FAQ on PF):
When the packets pass through the NAT gateway they will be modified so that they appear to be coming from the NAT gateway itself. The NAT gateway will record the changes it makes in its state table so that it can a) reverse the changes on return packets and b) ensure that return packets are passed through the firewall and are not blocked.
This gave me the impression that the dst-addr modification on the return packets occurred at the connection tracking level, which is in the prerouting table (before the forward and input chains, where Dimitry's rule lives), in which case the rule would not mistakenly drop packets.

However I may well be wrong, and the dst-addr of the return packets be modified by the same src-nat process which made the src-addr change on the outgoing packets, and this process lives in the postrouting table, downstream from the forward and input chain. Is this correct?
 
daviddem
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 62
Joined: Sun Sep 18, 2011 12:16 pm

Re: Q about Dmitry on firewalling

Mon Jan 02, 2012 3:06 pm

^^ Problem with the above is that I just setup test rules in the iptables of my dd-wrt home router (which does NAT). The rule logs packets in the forward table, which have come in through the public interface and still have the public IP for dst-addr... no match! Also have a rule there which logs packets that have a private IP as dst, and the counters are rolling!

So the dst address modification on the return packets must be happening in the prerouting table, at the connection tracking level, as I was thinking. In this case, what is the purpose of Dmitry's rule??
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6263
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: Q about Dmitry on firewalling

Tue Jan 03, 2012 9:01 am

good source where to look on how packets are processed within RouterOS:

http://wiki.mikrotik.com/wiki/Packet_Flow

in your case you are interested in layer 3. Where destination NAT takes place at the end of prerouting before input and forward chains.

Also, check where you jump to this chain (as there can be several entry points)
 
miro10hr
Member Candidate
Member Candidate
Posts: 101
Joined: Fri Nov 11, 2011 3:03 pm

Re: Q about Dmitry on firewalling

Tue Jan 03, 2012 7:39 pm

Can someon explain me this rule from Dmitry:

1.
/ip firewall mangle
add chain=prerouting in-interface=Public dst-address-list=nat-addr action=mark-packet new-packet-mark=nat-traversal \
    passthrough=no comment="Detect NAT Traversal"
Firs what does this passthrough=no do? It says in the wiki "passthrough - ignore this rule and go to next one (useful for statistics)." So this means that it shouldn't ignore this rule, but why this passthrough in the first place then?


The above rule is in relation with following rules in Dmitry's setup:
2.
/ ip firewall address-list
add list=nat-addr address=172.31.255.0/29 comment="my src-nated local network hosts"
nat-addr - should contain all the IP addresses you are source-natting on your router.
3.
/ ip firewall filter
add chain=sanity-check packet-mark=nat-traversal action=jump jump-target=drop comment="Deny illegal NAT traversal"
So if I understood packet processing well, this first rule is in chain Prerouting:
Prerouting = HotSpot-In - Connection Tracking - Mangle Prerouting - Destination NAT - Global-In;Global-Total

Mangle is after Connection Tracking, but before DST-NAT, so the destination IP of "good", correct packet should still be public IP?

So these rules say - drop packets that come to public interface and have destination IP from Local network - Local source natted hosts, because in this stage they should still have Public IP as Dest IP so they are illegal packets?
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6263
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 8:47 am

1. you should read the manual carefully and note the details.

paththrough=yes mean do what this rule has to do with the packet and then move processed and unprocessed packets to next rule in chain. paththrough=no in turn will make sure that processed packets does not reach the next rule in chain.

3. yes that is the case. Incoming packets that are with dst set to your local networks will be dropped, on the other hand set up rule that drops packets with connecetion-state=invalid and then see if someone still can manage to smuggle ip packets into your network.
 
miro10hr
Member Candidate
Member Candidate
Posts: 101
Joined: Fri Nov 11, 2011 3:03 pm

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 2:04 pm

Thanks a lot for the answer, it's clear now. :-)

I have one more question about Dmitry on firewalling. I am studying his configuration and I know I am wrong, but it doesn't make sense to me.

In his configuration there is "sanity-check" chain where packets are tested and dropped if needed.
ip firewall filter
add chain=forward action=jump jump-target=sanity-check comment="Sanity Check Forward"
add chain=sanity-check packet-mark=nat-traversal action=jump jump-target=drop comment="Deny illegal NAT traversal"
add chain=sanity-check protocol=tcp psd=20,3s,3,1 action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1d \
comment="Block port scans" disabled=yes
#check to see if this is too agressive and blocks legit hosts
add chain=sanity-check protocol=tcp tcp-flags=fin,psh,urg,!syn,!rst,!ack action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1d comment="Block TCP Null scan"
add chain=sanity-check protocol=tcp tcp-flags=!fin,!syn,!rst,!psh,!ack,!urg action=add-src-to-address-list address-list=blocked-addr address-list-timeout=1d comment="Block TCP Xmas scan"
add chain=sanity-check protocol=tcp src-address-list=blocked-addr action=jump jump-target=drop
add chain=sanity-check protocol=tcp tcp-flags=rst action=jump jump-target=drop comment="Drop TCP RST"
add chain=sanity-check protocol=tcp tcp-flags=fin,syn action=jump jump-target=drop comment="Drop TCP SYN+FIN"
add chain=sanity-check connection-state=invalid action=jump jump-target=drop comment="Dropping invalid connections at once"
add chain=sanity-check connection-state=established action=accept comment="Accepting already established connections"
add chain=sanity-check connection-state=related action=accept comment="Also accepting related connections"
add chain=sanity-check dst-address-type=broadcast,multicast action=jump jump-target=drop comment="Drop all traffic that goes to multicast or broadcast addresses"
add chain=sanity-check in-interface=Local dst-address-list=illegal-addr dst-address-type=!local action=jump jump-target=drop comment="Drop illegal destination addresses"
add chain=sanity-check in-interface=Local src-address-list=!local-addr action=jump jump-target=drop comment="Drop everything that goes from local interface but not from local address"
add chain=sanity-check in-interface=Public src-address-list=illegal-addr action=jump jump-target=drop comment="Drop illegal source addresses"
add chain=sanity-check in-interface=Public dst-address-list=!local-addr action=jump jump-target=drop \
comment="Drop everything that goes from public interface but not to local address" disabled=yes
#check this well! The above rule is for not nat-ed hosts!
add chain=sanity-check src-address-type=broadcast,multicast action=jump jump-target=drop comment="Drop all traffic that comes from multicast or broadcast addresses"


This is more or less clear to me. What is not clear to me is in part - Protecting your router where jump to sanity-check is made.
ip firewall filter
add chain=input src-address-type=local dst-address-type=local action=accept comment="Allow local traffic (between router applications)"
add chain=input in-interface=Local protocol=udp src-port=68 dst-port=67 action=jump jump-target=dhcp comment="DHCP protocol would not pass sanity checking, so enabling it explicitly before other checks"
add chain=input action=jump jump-target=sanity-check comment="Sanity Check"
add chain=input dst-address-type=!local action=jump jump-target=drop comment="Dropping packets not destined to the router itself, including all broadcast traffic"
add chain=input connection-mark=ping limit=5,5 action=accept comment="Allow pings, but at a very limited rate (5 packets per sec)"
add chain=input in-interface=Local action=jump jump-target=local-services comment="Allowing some services to be accessible from the local network"
add chain=input in-interface=Public action=jump jump-target=public-services comment="Allowing some services to be accessible from the Internet"
add chain=input action=jump jump-target=drop
add chain=dhcp src-address=0.0.0.0 dst-address=255.255.255.255 action=accept
add chain=dhcp src-address=0.0.0.0 dst-address-type=local action=accept
add chain=dhcp src-address-list=local-addr dst-address-type=local action=accept
add chain=local-services connection-mark=ssh action=accept comment="SSH (22/TCP)"
add chain=local-services connection-mark=dns action=accept comment="DNS"
add chain=local-services connection-mark=proxy action=accept comment="HTTP Proxy (3128/TCP)"
add chain=local-services connection-mark=winbox action=accept comment="Winbox (8291/TCP)" disabled=no
add chain=local-services action=log comment="Log & Drop Other Local Services"
add chain=local-services action=drop disabled=yes
#check the log twice before enabling this
add chain=public-services connection-mark=ssh action=accept comment="SSH (22/TCP)"
add chain=public-services connection-mark=pptp action=accept comment="PPTP (1723/TCP)"
add chain=public-services connection-mark=winbox action=accept comment="Winbox (8291/TCP)" disabled=no
add chain=public-services connection-mark=gre action=accept comment="GRE for PPTP"
add chain=public-services action=log comment="Log & Drop Other Public Services"
add chain=public-services action=drop disabled=yes
#check the log twice before enabling this
The wiki page about firewall says:
When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the chain, then it is accepted.
So my question is when the rules in this "input" chain would be processed (after jump to sanity-check) if there is a jump to "sanity-check" chain (bolded) and if The Wiki says that if the packet does not match any rule within the chain (sanity-check) it is accepted automatically? There is no "return" action in "sanity-check" chain so the packet would never come back from "sanity-check" chain it would be accepted (if not matched by any rule in sanity-check) and rules after "jump to sanity-check" would never be processed?
I know I am wrong, but I don't know why. I am trying to understand this.
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6263
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 2:20 pm

default action at the end of chain is to accept it for further processing. For user chains that mean that packet is not dropped and it is accepted back into originating chain. When end of system chain is reached it is accepted and further processing of packet occur according to packet flow.

For example packets after mangle input chain when reaches the end are acpeted (same action if rule with accept is added) and moved to filter input chain for further processing.
 
miro10hr
Member Candidate
Member Candidate
Posts: 101
Joined: Fri Nov 11, 2011 3:03 pm

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 3:25 pm

Thank you again.
I thought that "accept" means packet is accepted by firewall as a valid packet and not processed further (like accept or pass all). Misunderstanding in terminology.
I knew that there has to be some logic. Thanks!
 
daviddem
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 62
Joined: Sun Sep 18, 2011 12:16 pm

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 3:49 pm

OK, while we're at it, I don't understand how the anti-spam rules do their job:
add chain=forward action=jump jump-target=restrict-ip
...
add chain=restrict-tcp connection-mark=smtp action=jump jump-target=smtp-first-drop comment="anti-spam policy"
add chain=smtp-first-drop src-address-list=first-smtp action=add-src-to-address-list address-list=approved-smtp
add chain=smtp-first-drop src-address-list=approved-smtp action=return
add chain=smtp-first-drop action=add-src-to-address-list address-list=first-smtp
add chain=smtp-first-drop action=reject reject-with=icmp-network-unreachable
If I understand correctly, this rejects the first connection attempt to port 25 (no matter whether the connection attempt is coming from the public or local interface), then it accepts the subsequent ones. How does this help prevent spam?
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6263
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: Q about Dmitry on firewalling

Wed Jan 04, 2012 4:06 pm

it is very similar to greylisting (actually not so but principle is the same), when server connects first time, its connection is dropped, when retry timeout is reached it will attempt another valid attempt at delivering the e-mail. SNMP defaults to 5 minute wait till next delivery attempt. Usually spammers will leave your server alone after first unsuccessful attempt that it even cannot establish connection.

Who is online

Users browsing this forum: ameliask, Google [Bot], mikronoob89, normis, Vojta and 98 guests