iptables rule
in [Linux Networking]
|
Prev: Timer for every frame ?
Next: find and autofs
From: Bonno Bloksma on 5 Mar 2010 03:34 Hi, I want a service on a server in my DMZ to be available via the standard port for internal machines but on a non-standard port to the outside. I have on my firewall machine $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $EXTPORT -j DNAT --to $SERVERIP:$INTPORT and this seems to work to make the service available. Now all I need to do is block access from the outside to the standard port on the server. However if I add $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $INTPORT -j DROP I get a warning: The "nat" table is not intended for filtering, hence the use of DROP is deprecated and will permanently be disabled in the next iptables release. Please adjust your scripts. But I cannot add it to the FORWARD chain as this $IPTABLES -A FORWARD -d $SERVERIP -p tcp --dport $INTPORT -j DROP will block access to the service via the EXTPORT as well. After all the packet passes the FORWARD chain after it has been changed by the PREROUTING chain. Whast is the recomended solution? And no, this is not security by obscurity, just another layer to protect my logfiles. ;-) Bonno Bloksma
From: Mart Frauenlob on 5 Mar 2010 05:06 On 05.03.2010 09:34, Bonno Bloksma wrote: > Hi, > > I want a service on a server in my DMZ to be available via the standard port for internal machines > but on a non-standard port to the outside. > > I have on my firewall machine > $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $EXTPORT -j DNAT --to $SERVERIP:$INTPORT > and this seems to work to make the service available. > > Now all I need to do is block access from the outside to the standard port on the server. > However if I add > $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $INTPORT -j DROP > I get a warning: > The "nat" table is not intended for filtering, hence the use of DROP is deprecated and will > permanently be disabled in the next iptables release. Please adjust your scripts. > > But I cannot add it to the FORWARD chain as this > $IPTABLES -A FORWARD -d $SERVERIP -p tcp --dport $INTPORT -j DROP > will block access to the service via the EXTPORT as well. After all the packet passes the FORWARD > chain after it has been changed by the PREROUTING chain. > > Whast is the recomended solution? > > And no, this is not security by obscurity, just another layer to protect my logfiles. ;-) > > Bonno Bloksma > > Use the external interface in you nat rule, for the internet mapping. -t nat -A PREROUTING -i $EXT_IFACE -d $PUBLIC_IP -p tcp --dport $EXT_PUBLIC_PORT -j DNAT --to-destination $SERVER_INT_IP:$INT_PORT in FORWARD chain of filter table, allow this: -A FORWARD -i $EXT_IFACE -d $SERVER_INT_IP -p tcp --dport $INT_PORT -j ACCEPT all left to do is allow the internal hosts talk to the dmz. in filter table: -A FORWARD -s $INTERNAL_LAN -d $SERVER_INT_IP -p tcp --dport $INT_PORT -j ACCEPT actually you could reduce the two above rules to just: -A FORWARD -d $SERVER_INT_IP -p tcp --dport $INT_PORT -j ACCEPT because requests to the $INT_PORT on the external interface will never be DNATted. It's a matter of choice and the circumstances whether one uses more specific matches. I hope it helps. Best regards Mart
From: Bonno Bloksma on 6 Mar 2010 06:48 Hi, >> I want a service on a server in my DMZ to be available via the standard port for internal >> machines >> but on a non-standard port to the outside. >> >> I have on my firewall machine >> $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $EXTPORT -j DNAT --to >> $SERVERIP:$INTPORT >> and this seems to work to make the service available. >> >> Now all I need to do is block access from the outside to the standard port on the server. >> However if I add >> $IPTABLES -t nat -A PREROUTING -d $SERVERIP -p tcp --dport $INTPORT -j DROP >> I get a warning: >> The "nat" table is not intended for filtering, hence the use of DROP is deprecated and will >> permanently be disabled in the next iptables release. Please adjust your scripts. >> >> But I cannot add it to the FORWARD chain as this >> $IPTABLES -A FORWARD -d $SERVERIP -p tcp --dport $INTPORT -j DROP >> will block access to the service via the EXTPORT as well. After all the packet passes the FORWARD >> chain after it has been changed by the PREROUTING chain. > Use the external interface in you nat rule, for the internet mapping. > > -t nat -A PREROUTING -i $EXT_IFACE -d $PUBLIC_IP -p tcp --dport > $EXT_PUBLIC_PORT -j DNAT --to-destination $SERVER_INT_IP:$INT_PORT > > in FORWARD chain of filter table, allow this: > > -A FORWARD -i $EXT_IFACE -d $SERVER_INT_IP -p tcp --dport $INT_PORT -j > ACCEPT All external traffic is coming via the external interface, internal traffic to the DMZ server will never reach this firewall. Either I'm not understanding what you try to write or maybe my situation is not clear enough. My situation is: INTERNET -- ExtFirewall -- DMZ -- IntFirewall -- Internal network All servers in the DMZ have public ip numbers. There is no difference in external and internal ip number. Traffic from the outside to a DMZ server will pass the external firewall and never reach the internal firewall Traffic from the inside to a DMZ server will pass the internal firewall and never reach the exterenal firewall Besides tranforming outside traffic to the ip:extport combination I only need to block outside traffic to the ip:intport combination. As fas as I kown after the handling by the nat table there is no difference in traffic that was originaly to the extport and then translated and traffic that was to the internal port all the time. :-( But, maybe I'm wrong. Bonno Bloksma
From: Pascal Hambourg on 6 Mar 2010 07:31 Hello, Bonno Bloksma a �crit : > > All external traffic is coming via the external interface, internal traffic to the DMZ server will > never reach this firewall. > Either I'm not understanding what you try to write or maybe my situation is not clear enough. My > situation is: > INTERNET -- ExtFirewall -- DMZ -- IntFirewall -- Internal network > > All servers in the DMZ have public ip numbers. There is no difference in external and internal ip > number. [...] > Besides tranforming outside traffic to the ip:extport combination I only need to block outside > traffic to the ip:intport combination. Can't you just have your services listen on both ports and just filter the forbidden port on the external firewall ? My motto is that NAT should be avoided as much as possible. > As fas as I kown after the handling by the nat table there is no difference in traffic that was > originaly to the extport and then translated and traffic that was to the internal port all the time. There are a number of solutions. 1) Quick and dirty : DROP in mangle/PREROUTING. But filtering in mangle is as evil as in nat, and may be deprecated too. 2) MARK packets in mangle/PREROUTING based on the original address:port and use the mark in nat and filter. 3) DNAT ip:intport to a different unused port and/or address that you can drop. But that's just more NAT...
From: Bonno Bloksma on 6 Mar 2010 08:02
Hi, >> >> All external traffic is coming via the external interface, internal traffic to the DMZ server >> will >> never reach this firewall. >> Either I'm not understanding what you try to write or maybe my situation is not clear enough. My >> situation is: >> INTERNET -- ExtFirewall -- DMZ -- IntFirewall -- Internal network >> >> All servers in the DMZ have public ip numbers. There is no difference in external and internal ip >> number. > [...] >> Besides tranforming outside traffic to the ip:extport combination I only need to block outside >> traffic to the ip:intport combination. > > Can't you just have your services listen on both ports and just filter > the forbidden port on the external firewall ? My motto is that NAT > should be avoided as much as possible. I did not think that was possible but... after looking once more at the docs it turnes out it is indeed possible to have this service listen on more than one port. So now the service is indeed listening on both ports, I block the default port from the outside and I have A LOT less failed connections in my logfiles due to automated hacking attempts. :-) Bonno Bloksma |