Sponsored Content
Special Forums IP Networking iptables - formatting icmp rules Post 303017697 by CrazyDave on Sunday 20th of May 2018 09:04:31 PM
Old 05-20-2018
iptables - formatting icmp rules

Hi, I am relatively new to firewalls and netfilter. I have a Debian Stretch router box running dnsmasq, connected to a VPN. Occasionally dnsmasq polls all of the desired DNS servers to select the fastest. When it does this it responds to replies of the non-selected DNS servers with a icmp type three or "host unreachable". My firewall is very strict (I was hacked) and I am controlling sockets. I would like to respond to the DNS servers with this icmp message. I have tried many, many ways but none work, the message keeps on getting dropped. Here is an example rule set for one of the DNS servers:

Code:
# Owner: cryptostorm DNS in Langley in CA
-A OUTPUT -o tun0 -m state --state ESTABLISHED,NEW -p tcp --dport 53 -d 162.221.207.228 -j good_out_ips_accept
-A OUTPUT -o tun0 -m state --state ESTABLISHED,NEW -p udp --dport 53 -d 162.221.207.228 -j good_out_ips_accept
-A OUTPUT -m state --state ESTABLISHED,NEW -p icmp -m icmp --icmp-type 3 -d 162.221.207.228 -j good_out_ips_accept
-A OUTPUT -o tun0 -d 162.221.207.228 -j good_out_ips_drop

Here is the rule script:

Code:
-N good_out_ips_accept
-N good_out_ips_drop

-- many ips and ranges like above ----

-A good_out_ips_accept -j ACCEPT
-A good_out_ips_drop -j LOG  --log-level info --log-prefix "GOOD O/P IPs -- DROP :"
-A good_out_ips_drop -j DROP

Here is the resulting script from the firewall log:

Code:
May 20 16:24:21 gate kernel: [73690.667828] GOOD O/P IPs -- DROP :IN= OUT=tun0 SRC=10.7.7.88 DST=162.221.207.228 LEN=152 TOS=0x00 PREC=0xC0 TTL=64 ID=54071 PROTO=ICMP TYPE=3 CODE=3 [SRC=162.221.207.228 DST=10.7.7.88 LEN=124 TOS=0x00 PREC=0x00 TTL=57 ID=58899 DF PROTO=UDP SPT=53 DPT=50934 LEN=104 ]

To me the firewall is not seeing the icmp rule for some reason. Can anyone see the problem? Thanks for you help!

---------- Post updated at 06:04 PM ---------- Previous update was at 05:36 PM ----------

Well, I'm replying to my own post 10 minutes after writing it. All I needed was a "RELATED" on the state. I was hesitant to use this state as it seems to open a can of worms on some web sites...
 

10 More Discussions You Might Find Interesting

1. Shell Programming and Scripting

SED inserting iptables rules in while loop

I'm trying to insert multiple new lines of text into an iptables script using sed in a while loop. I'm not sure if this is the most effective way. Searching the forums has helped me come up with a good beginning but it's not 100%. I'd like it to search out a unique line in my current iptables file... (2 Replies)
Discussion started by: verbalicious
2 Replies

2. IP Networking

Iptables rules at boot

Hi I have small home network and I want to block some forums on web When I use this iptables -A INPUT -s forum -j DROP rules is applied but when I restart some of PC rules are not present any more also I tried to save firewall settings iptables-save > /root/dsl.fw but how to... (2 Replies)
Discussion started by: solaris_user
2 Replies

3. Cybersecurity

Editing rules on iptables

Hello, I was playing around with iptables to setup an isolated system. On a SLES10 system, I ran the below to setup my first draft of rules. I noticed that the rules come into effect immediately and do not require any restart of iptables. iptables -A INPUT -j ACCEPT iptables -A OUTPUT -m... (4 Replies)
Discussion started by: garric
4 Replies

4. Ubuntu

iptables rules (ubuntu)

Could someone help me with writing rules for iptables? I need a dos attacks protection for a game server. port type udp ports 27015:27030 interface: eth0 Accept all packets from all IPs Chek if IP sent more than 50 packets per second Drop all packets from this IP for 5 minutes I would be... (0 Replies)
Discussion started by: Greenice
0 Replies

5. Red Hat

Iptables/Firewall rules for multicast IP.

Hi Gurus, I need to add Multicast Port = xyz Multicast Address = 123.134.143 ( example) to my firewall rules. Can you please guide me with the lines I need to update my iptables files with. (0 Replies)
Discussion started by: rama krishna
0 Replies

6. Red Hat

iptables Rules for my network

Hi Champs i am new in Iptables and trying to write rules for my Samba server.I took some help from internet, created one script and run from rc.local : #Allow loopback iptables -I INPUT -i lo -j ACCEPT # Accept packets from Trusted network iptables -A INPUT -s my-network/subnet -j... (0 Replies)
Discussion started by: Vaibhav.T
0 Replies

7. UNIX for Advanced & Expert Users

Editing iptables rules with custom chain

Hello, I have iptables service running on my CentOS5 server. It has approx 50 rules right now. The problem I am facing now is as follows - I have to define a new chain in the filter table, say DOS_RULES & add all rules in this chain starting from index number 15 in the filter table. ... (1 Reply)
Discussion started by: BhushanPathak
1 Replies

8. Shell Programming and Scripting

Need to Convert the QNX rules to UNIX iptables

Need to convert the QNX rules to Linux ubuntu 12.04. kindly any one help us with any tools (4 Replies)
Discussion started by: mageshkumar
4 Replies

9. UNIX for Advanced & Expert Users

iptables help with rules

Hi, I've been struggling with this all morning and seem to have a blind spot on what the problem is. I'm trying to use iptables to block traffic on a little cluster of raspberry pi's but to allow ssh and ping traffic within it. The cluster has a firewall server with a wifi card connecting to... (4 Replies)
Discussion started by: steadyonabix
4 Replies

10. Cybersecurity

Need help for iptables rules

Hello, I did 2 scripts. The second one is, I hope, more secure. What do you think? Basic connection (no server, no router, no DHCP and the Ipv6 is disabled) #######script one #################### iptables -F iptables -X -t filter iptables -P INPUT DROP iptables -P FORWARD... (6 Replies)
Discussion started by: Thomas342
6 Replies
ZONE.CONF(5)							   File Formats 						      ZONE.CONF(5)

NAME
zone.conf - fiaif zone configuration files DESCRIPTION
fiaif.conf is the file that determines how zones should be set up in the firewall. A zone describes how traffic from other zones are allowed into a zone, and what packets are allowed from the zone itself. Zones are based upon the interface and the network the interface is connected to. It is possible to have multiple zones per interface, if and only if the interface is not declared public. See the PUBLIC variable for more information. The general syntax of a configuration file is the same as for a bash(1) script, in which only variables should be present. The variables can be on three forms: VARIABLE This is a simple variable. It can only be assigned a single value. VARIABLE_FOO The denotes a variable sequence. The FOO can be replaced by any keyword, allowing multiple values to be specified. VARIABLE[N] A variable array. Any number of values can be specified by increasing N for each value. VARIABLES
NAME Syntax: <name> Specify the name of the zone. This must be the same as specified in /etc/fiaif/fiaif.conf. DEV Syntax: <interface-name> Specifies the interface name in which this zone is connected. DYNAMIC Syntax: 0|1 Specifies whether the IP of the interface is dynamic (e.g., obtained via DHCP or unknown when FIAIF is started) or not. Disabling this pro- vides better security, but this is not always an option given from ISPs. GLOBAL Syntax: 0|1 Is set to one, any packets originating from IANA reserved networks are discarded (except those specified in the NET and NET_EXTRA vari- ables). This should be set on your internet connection. If this is set to true, the interface cannot have multible zone definitions. IP Syntax: <IP address> The IP of the interface. This is only necessary to specify if DYNAMIC=0. MASK Syntax: <network mask> The network mask of the network connected to this interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command. NET Syntax: <ip address/networkmask> The network mask for the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifconfig command. BCAST Syntax: <broadcast address> The broadcast address of the interface. This is only necessary to specify if DYNAMIC=0. This information can be found be using the ifcon- fig command. IP_EXTRA Syntax: [IP]* Contains a list of additional IP addresses that the interface can receive. Extra IP's for an interface is usually created by using inter- face aliases (e.g. eth0:0). NET_EXTRA Syntax: [IP/MASK]* A list specifying any extra networks besides the NET variables that are connected to this zone (interface). The extra nets would normally be connected though other routers. DHCP_SERVER Syntax: <0|1> Set to '1' if the server should accept DHCP queries. Only one zone per interface should have this enabled, since DHCP packets do not hold any valid destination address. INPUT[N] Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask] The INPUT variable describes how packets are handled through the input chain. Packets on the INPUT chain are packets coming from the zone to the firewall itself. The first argument is how a matched packet is treated. Protocol and ports and ip/mask are used to match packets (destination port, and source=>destination ip address). If none are specified, the rule matches all packets. The port argument must only be specified if the protocol is udp, tcp or icmp When using these rules, a rule of thumb is only to accept specific packets, and to drop any not matched. The following line 1 accepts HTTP-requests over the TCP protocol: INPUT[0]="ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0" INPUT[1]="ACCEPT udp 1024:65535 0.0.0.0/0=>0.0.0.0/0" INPUT[2]="DROP ALL 0.0.0.0=>0.0.0.0" OUTPUT[N] Syntax: <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol> [port<:port>[<,port>[:port]]*] ip/[mask]=>ip/[mask] Like the INPUT[N] rule. Packets on the OUTPUT chain are packets originating from the firewall itself going out into the zone itself. ports are destination ports, and ip/mask is the source and destination ip/mask (if '=>' is not given, the ip is assumed to be the destination ip). The port argument must only be specified if the protocol is udp, tcp or icmp The following example drops all telnet packets over the tcp protocol, drops any udp packets, and allows any other send from the firewall itself. OUTPUT[0]="DROP tcp 21 0.0.0.0/0=>0.0.0.0/0" OUTPUT[1]="DROP udp ALL 0.0.0.0/0=>0.0.0.0/0" OUTPUT[2]="ACCEPT ALL 0.0.0.0/0=>0.0.0.0/0" FORWARD[N] Syntax: <zone|ALL> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]> Use to specify how packets arriving from other zones are to be treated. If protocol or ports and ip/mask is not specified, then ALL is assumed. The port specifies the destination port, and ip specifies the source and destination ip. The port argument must only be specified if the protocol is udp, tcp or icmp An example: A demilitarized zone may only accept HTTP requests from the internet (zone EXT). This would be specified by: FORWARD[0]="EXT ACCEPT tcp 80 0.0.0.0/0=>0.0.0.0/0" FORWARD[1]="ALL DROP ALL 0.0.0.0/0=>0.0.0.0/0" MARK[N] Syntax: <zone|ALL> <mark number> <protocol[port<:port>[<,port>[:port]]*]> <ip/[mask]=>ip/[mask]> Use the MARK rules to set a MARK on packets passing through the firewall. This can then be used to determine how a packet is routed. FIAIF does not do traffic-shaping based on mark values. The port argument must only be specified if the protocol is udp, tcp or icmp If the source zone is ALL then all packets going into the zone are marked. If the source zone equals the zone-name of which the rule is in then only packets originating from the firewall are marked. Otherwise, only packets routed through the firewall are marked. Example: Mark all tcp packets going into the zone with '1' and all udp packets with mark '2'. MARK[0]="ALL 1 tcp ALL 0.0.0.0/0=>0.0.0.0/0" MARK[1]="ALL 2 udp ALL 0.0.0.0/0=>0.0.0.0/0" REPLY_FOO Syntax: <zone> <type> <protocol [port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]> Make special replies to packets. The type can be one of the following: icmp-net-unreachable, icmp-host-unreachable, icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited, icmp-host-prohibited or tcp-reset (Only valid for the TCP protocol). The zone argument specifies the source of the packet. This can be used, for example, to disallow authentication requests, but instead of dropping the packets, close the connection by sending a tcp-reset. REPLY_AUTH="EXT tcp-reset tcp auth 0.0.0.0/0=>0.0.0.0/0" MAC_DROP Syntax: [MAC_ADDRESS]*|[file] Disallow any communication with specified MAC-addresses in this zone. Inserted on PREROUTING chain. If the value is a file, then each line in the file is treated as an MAC address. Anything after a '#' is regarded as a comment and is ignored. IP_DROP Syntax: [IP/MASK]*|[file] Disallow any communication with specified IP addresses in this zone. If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored. ECN_REMOVE Syntax: [IP/MASK]*|[file] Remove the ECN bit from all packets destined to the specified servers (located in the zone). If the value is a file, then each line in the file is treated as an ip address. Anything after a '#' is regarded as a comment and is ignored. REDIRECT_FOO Syntax: <protocol[port[:port]]> <ip[/mask]=>ip[/mask]> <[ipaddr[,ipaddr]*]> [port] Alter the destination of packets. The rule applies only for packets originating from this zone. Packets can be redirected to the firewall itself (127.0.0.1), to other zones or back into the zone itself (requires DYNAMIC==0 and GLOBAL==0). If packets are redirected to other zones, then remember to add a FORWARD rule in the configuration file for the destination zone, allowing the packets to pass through. Please note, that redirecting packets back into the zone may cause serious network degradation. Example: REDIRECT_PROXY="tcp 80 0.0.0.0/0=>0.0.0.0/0 127.0.0.1 3128" All packets coming from the zone itself to port 80 are redirected to the firewall itself port 3128, and this line can be used to setup a transparent proxy. WATCH_IP Syntax: [IP]*|[file] Log every packet coming from or going to the specific IP addresses. If the value is a file, then each line in the file is treated as an IP address. Anything after a '#' is regarded as a comment and is ignored. SNAT[N] Syntax: <ZONE|ip> <protocol[port[:port][<,port>[:port]]*]> <ip[/mask]=>ip[/mask]> Change the source address of a packet coming from this zone. If a ZONE is specified, then all packets are masqueraded to all ip addresses for the specified zone, specified by the IP or IP_EXTRA directive, in a round robin fashion. The last options specifies the protocol, port and original source and destination of the packets to be SNAT'ed. To use MASQUADING, where EXT is the zone for the internet use: SNAT[0]="EXT ALL 0.0.0.0/0=>0.0.0.0/0" LIMIT_FOO Syntax: <zone> <ACCEPT|REJECT|DROP|LOG|ACCEPT_LOG|REJECT_NOLOG|DROP_NOLOG> <limit> <burt> <protocol[port<:port>[<,port>[:port]]*]> <ip[/mask]=>ip[/mask]> Limit number of packets. A LIMIT rule specifies how many packets are acceptable within the specified period of time. If more packets arrive, policy specifies how to handle these. zone: Is the zone from which the packet originates. This can be this zone itself. limit: Maximum average matching rate: specified as a number, with an optional '/second', '/minute', '/hour', or '/day' suffix. burst: Maximum initial number of packets to match: this number gets incremented by one every time the limit specified above is not reached, up to this number. protocol: The protocol: TCP|UDP|ICMP|ALL. This parameter is optional. The port argument must only be specified if the protocol is udp, tcp or icmp ports: If protocol is tcp|udp: A list of ports or a port range. icmp: A list of icmp types seperated by commas. This parameter is optional pending on the specified protocol. ip[/mask]=>ip[/mask] Specifies source address and optional destination address. This can only be specified if protocol is also specified. For example to limit number of echo requests (ping) from zone EXT, use: LIMIT_PING="EXT DROP 1/second 3 ICMP echo-request 0.0.0.0/0=>0.0.0.0/0" TC_ENABLE Syntax: <0|1> Enable or disable Traffic Shaping for this zone (traffic going into the network card, or being sent from the network card.) TC is only enabled if ENABLE_TC is set in the global configuration as well. TC_UPLINK TC_DOWNLINK Syntax: <kbit> Specify maximum uplink and downlink speeds. The values are specifed in kilobits (1024 bits). TC_TYPE Syntax: <HTB|HFSC> Specify the type of traffic shaping to be used. htb is videly available, but the hfsc type shaping yields much better results. Choose hfsc if you have the nessesary modules. TC_VOIP Syntax: <0|1> Specify '1' to enable special VOIP traffic shaping classes. Currently only implemented for the HFSC type shaper. It reserves a minimum bandwidth for voip traffic, and creates a special high priority class for voip related traffic. IPSET_FOO Syntax: <ip</mask>>[ip</mask>]*| <file> Sepcify a set of ip's to be used in zone rules. Ip's specified can be either numbers, hostnames, networks or names of other ip sets (recur- sively). The name of the set will be the name occuring after IPSET_. Ip sets is bound to a zone, and cannot be used across zones. Cur- rently, ip-sets can only be used in INPUT, OUTPUT, FORWARD, SNAT, REDIRECT and MARK rules. If the ipset points to a file, then the file is read (relative to CONF_PATH ). The name of IP sets must not conflict with aliases defined in the file pointed to by the ALIASES directive in fiaif global configuration file. An example of the use of IP sets: IPSET_NAMESERVERS="1.2.3.4 1.2.3.5" INPUT[N]="ACCEPT tcp domain NAMESERVERS=>0.0.0.0/0" Which is equivalent to: INPUT[N]="ACCEPT tcp domain 1.2.3.4=>0.0.0.0/0" INPUT[N+1]="ACCEPT tcp domain 1.2.3.5=>0.0.0.0/0" AUTHOR
Anders Fugmann <anders(at)fugmann.net> SEE ALSO
fiaif(8), fiaif.conf(8), iptables(8), ifconfig(8) Linux Feb 2006 ZONE.CONF(5)
All times are GMT -4. The time now is 04:26 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy