Difference between revisions of "Iptables"

From ArchWiki
Jump to: navigation, search
(Resetting rules: expands for raw and security tables)
(Configuration and usage: shorten network-pre note, implemented in package. Keeping reference to longstanding bugs for info, re Talk)
 
(105 intermediate revisions by 25 users not shown)
Line 1: Line 1:
{{DISPLAYTITLE:iptables}}
+
{{Lowercase title}}
 
[[Category:Firewalls]]
 
[[Category:Firewalls]]
 +
[[de:Iptables]]
 +
[[el:Iptables]]
 
[[es:Iptables]]
 
[[es:Iptables]]
 +
[[fr:Iptables]]
 
[[it:Iptables]]
 
[[it:Iptables]]
 +
[[ja:Iptables]]
 
[[ru:Iptables]]
 
[[ru:Iptables]]
 
[[sr:Iptables]]
 
[[sr:Iptables]]
 
[[zh-CN:Iptables]]
 
[[zh-CN:Iptables]]
{{Article summary start}}
+
{{Related articles start}}
{{Article summary text|Information regarding the setup and configuration of iptables.}}
+
{{Related|Firewalls}}
{{Article summary heading|Related}}
+
{{Related|Simple stateful firewall}}
{{Article summary wiki|Firewalls}}
+
{{Related|Sysctl#TCP/IP stack hardening}}
{{Article summary wiki|Simple Stateful Firewall}}
+
{{Related|Sshguard}}
{{Article summary wiki|Sysctl#TCP/IP stack hardening}}
+
{{Related|Fail2ban}}
{{Article summary wiki|Sshguard}}
+
{{Related|Nftables}}
{{Article summary wiki|Fail2ban}}
+
{{Related articles end}}
{{Article summary end}}
+
  
Iptables is a powerful [[firewall]] built into the Linux kernel and is part of the [[Wikipedia:Netfilter|netfilter]] project. It can be configured directly, or by using one of the many [[Firewalls#iptables_front-ends|frontends]] and [[Firewall#iptables_GUIs|GUIs]]. iptables is used for [[Wikipedia:IPv4|IPv4]] and ip6tables is used for [[IPv6]].
+
''iptables'' is a command line utility for configuring Linux kernel [[firewall]] implemented within the [[Wikipedia:Netfilter|Netfilter]] project. The term ''iptables'' is also commonly used to refer to this kernel-level firewall. It can be configured directly with iptables, or by using one of the many [[Firewalls#Console frontends|frontends]] and [[Firewalls#Graphic frontends|GUIs]]. iptables is used for [[Wikipedia:IPv4|IPv4]] and ''ip6tables'' is used for [[IPv6]].
 +
 
 +
[[nftables]] was released in [http://www.phoronix.com/scan.php?page=news_item&px=MTQ5MDU release with Linux kernel 3.13], and will one day replace iptables as the main Linux firewall utility.
  
 
== Installation ==
 
== Installation ==
  
The stock Arch Linux kernel is compiled with iptables support. You will only need to [[pacman|install]] the userland utilities, which are provided by the package {{Pkg|iptables}} in the [[Official Repositories|official repositories]].
+
The stock Arch Linux kernel is compiled with iptables support. You will only need to [[install]] the userland utilities, which are provided by the package {{Pkg|iptables}}. (The {{Pkg|iproute2}} package from the {{Grp|base}} group depends on iptables, so the iptables package should be installed on your system by default.)
  
 
== Basic concepts ==
 
== Basic concepts ==
 +
 +
iptables is used to inspect, modify, forward, redirect, and/or drop IPv4 packets.  The code for filtering IPv4 packets is already built into the kernel and is organized into a collection of ''tables'', each with a specific purpose.  The tables are made up of a set of predefined ''chains'', and the chains contain rules which are traversed in order. Each rule consists of a predicate of potential matches and a corresponding action (called a ''target'') which is executed if the predicate is true; i.e. the conditions are matched.  iptables is the user utility which allows you to work with these chains/rules.  Most new users find the complexities of linux IP routing quite daunting, but, in practice, the most common use cases (NAT and/or basic Internet firewall) are considerably less complex.
 +
 +
The key to understanding how iptables works is [http://www.frozentux.net/iptables-tutorial/images/tables_traverse.jpg this chart].  The lowercase word on top is the table and the upper case word below is the chain.  Every IP packet that comes in ''on any network interface'' passes through this flow chart from top to bottom.  A common source of confusion is that packets entering from, say, an internal interface are handled differently than packets from an Internet-facing interface.  All interfaces are handled the same way; it's up to you to define rules that treat them differently.  Of course some packets are intended for local processes, hence come in from the top of the chart and stop at <Local Process>, while other packets are generated by local processes; hence start at <Local Process> and proceed downward through the flowchart.  A detailed explanation of how this flow chart works can be found [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#TRAVERSINGOFTABLES here].
 +
 +
In the vast majority of use cases you won't need to use the '''raw''', '''mangle''', or '''security''' tables at all.  Consequently, the following chart depicts a simplified network packet flow through ''iptables'':
 +
 +
{{bc|<nowiki>
 +
                              XXXXXXXXXXXXXXXXXX
 +
                            XXX    Network    XXX
 +
                              XXXXXXXXXXXXXXXXXX
 +
                                      +
 +
                                      |
 +
                                      v
 +
+-------------+              +------------------+
 +
|table: filter| <---+        | table: nat      |
 +
|chain: INPUT |    |        | chain: PREROUTING|
 +
+-----+-------+    |        +--------+---------+
 +
      |            |                |
 +
      v            |                v
 +
[local process]    |          ****************          +--------------+
 +
      |            +---------+ Routing decision +------> |table: filter |
 +
      v                        ****************          |chain: FORWARD|
 +
****************                                          +------+-------+
 +
Routing decision                                                  |
 +
****************                                                  |
 +
      |                                                          |
 +
      v                        ****************                  |
 +
+-------------+      +------>  Routing decision  <---------------+
 +
|table: nat  |      |        ****************
 +
|chain: OUTPUT|      |              +
 +
+-----+-------+      |              |
 +
      |              |              v
 +
      v              |      +-------------------+
 +
+--------------+      |      | table: nat        |
 +
|table: filter | +----+      | chain: POSTROUTING|
 +
|chain: OUTPUT |            +--------+----------+
 +
+--------------+                      |
 +
                                      v
 +
                              XXXXXXXXXXXXXXXXXX
 +
                            XXX    Network    XXX
 +
                              XXXXXXXXXXXXXXXXXX
 +
</nowiki>}}
  
 
=== Tables ===
 
=== Tables ===
  
iptables contains five ''tables'', which are areas where a chain of rules can apply:
+
iptables contains five tables:
  
# {{ic|raw}} filters packets before any of the other table. It is used mainly for configuring exemptions from connection tracking in combination with the {{ic|NOTRACK}} target.
+
# {{ic|raw}} is used only for configuring packets so that they are exempt from connection tracking.
# {{ic|filter}} is the default table (if no {{ic|-t}} option is passed).
+
# {{ic|filter}} is the default table, and is where all the actions typically associated with a firewall take place.
# {{ic|nat}} is used for [[Wikipedia:Network address translation|network address translation]] (e.g. port forwarding). Because of limitations in iptables, filtering should not be done here.
+
# {{ic|nat}} is used for [[Wikipedia:Network address translation|network address translation]] (e.g. port forwarding).
# {{ic|mangle}} is used for specialized packet alteration (see [[Wikipedia:Mangled packet|Mangled packet]]).
+
# {{ic|mangle}} is used for specialized packet alterations.
# {{ic|security}} is used for [[Security#Mandatory access control|Mandatory Access Control]] networking rules.
+
# {{ic|security}} is used for [[Security#Mandatory access control|Mandatory Access Control]] networking rules (e.g. SELinux -- see [http://lwn.net/Articles/267140/ this article] for more details).
  
=== Chains ===
+
In most common use cases you will only use two of these: '''filter''' and '''nat'''.  The other tables are aimed at complex configurations involving multiple routers and routing decisions and are in any case beyond the scope of these introductory remarks.
  
Tables contain ''chains'', which are lists of rules for packets that are followed in order. The default table {{ic|filter}} contains three built-in chains: {{ic|INPUT}}, {{ic|OUTPUT}} and {{ic|FORWARD}}.
+
=== Chains ===
  
# Inbound traffic addressed to the machine itself hits the {{ic|INPUT}} chain.
+
Tables consist of ''chains'', which are lists of rules which are followed in order. The default table, {{ic|filter}}, contains three built-in chains: {{ic|INPUT}}, {{ic|OUTPUT}} and {{ic|FORWARD}} which are activated at different points of the packet filtering process, as illustrated in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg flow chart].  The nat table includes {{ic|PREROUTING}}, {{ic|POSTROUTING}}, and {{ic|OUTPUT}} chains.
# Outbound, locally-generated traffic hits the {{ic|OUTPUT}} chain.
+
# Routed traffic which should not be delivered locally hits the {{ic|FORWARD}} chain.
+
  
 
See {{ic|man 8 iptables}} for a description of built-in chains in other tables.
 
See {{ic|man 8 iptables}} for a description of built-in chains in other tables.
  
User-defined chains can be added to make rulesets more efficient.
+
By default, none of the chains contain any rules.  It is up to you to append rules to the chains that you want to use.  Chains ''do'' have a default policy, which is generally set to {{ic|ACCEPT}}, but can be reset to {{ic|DROP}}, if you want to be sure that nothing slips through your ruleset. The default policy always applies at the end of a chain only. Hence, the packet has to pass through all existing rules in the chain before the default policy is applied.
  
Built-in chains have a default target, which is used if no rules are hit. Neither built-in nor user-defined chains can be a default target.
+
User-defined chains can be added to make rulesets more efficient or more easily modifiable. See [[Simple stateful firewall]] for an example of how user-defined chains are used.
  
 
=== Rules ===
 
=== Rules ===
  
The packet filtering is based on ''rules'', which are specified by multiple ''matches'' (conditions the packet must satisfy so that the rule can be applied), and one ''target'' (action taken when the packet matches all condition). While individual conditions are usually very simple, the full rule specification can be very complex.
+
Packet filtering is based on ''rules'', which are specified by multiple ''matches'' (conditions the packet must satisfy so that the rule can be applied), and one ''target'' (action taken when the packet matches all conditions). The typical things a rule might match on are what interface the packet came in on (e.g eth0 or eth1), what type of packet it is (ICMP, TCP, or UDP), or the destination port of the packet.
  
Targets are specified using the {{ic|-j}} or {{ic|--jump}} option. Targets can be either user-defined chains, one of the special built-in targets, or a target extension. Built-in targets are {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}} and {{ic|RETURN}}, target extensions are for example {{ic|REJECT}} and {{ic|LOG}}. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the packet passes successfully through this second chain, it will move to the next rule in the original chain. Target extensions can be either ''terminating'' (as built-in targets) or ''non-terminating'' (as user-defined chains), see {{ic|man 8 iptables-extensions}} for details.
+
Targets are specified using the {{ic|-j}} or {{ic|--jump}} option. Targets can be either user-defined chains (i.e. if these conditions are matched, jump to the following user-defined chain and continue processing there), one of the special built-in targets, or a target extension. Built-in targets are {{ic|ACCEPT}}, {{ic|DROP}}, {{ic|QUEUE}} and {{ic|RETURN}}, target extensions are, for example, {{ic|REJECT}} and {{ic|LOG}}. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the fate of the packet is not decided by this second chain, it will be filtered against the remaining rules of the original chain. Target extensions can be either ''terminating'' (as built-in targets) or ''non-terminating'' (as user-defined chains), see {{ic|man 8 iptables-extensions}} for details.
 +
 
 +
=== Traversing Chains ===
 +
 
 +
A network packet received on any interface traverses the traffic control chains of tables in the order shown in the [http://www.frozentux.net/iptables-tutorial/chunkyhtml/images/tables_traverse.jpg flow chart].  The first routing decision involves deciding if the final destination of the packet is the local machine (in which case the packet traverses through the {{ic|INPUT}} chains) or elsewhere (in which case the packet traverses through the {{ic|FORWARD}} chains).  Subsequent routing decisions involve deciding what interface to assign to an outgoing packet.  At each chain in the path, every rule in that chain is evaluated in order and whenever a rule matches, the corresponding target/jump action is executed.  The 3 most commonly used targets are {{ic|ACCEPT}}, {{ic|DROP}}, and jump to a user-defined chain.  While built-in chains can have default policies, user-defined chains can not.  If every rule in a chain that you jumped fails to provide a complete match, the packet is dropped back into the calling chain as illustrated [http://www.frozentux.net/iptables-tutorial/images/table_subtraverse.jpg here].  If at any time a complete match is achieved for a rule with a {{ic|DROP}} target, the packet is dropped and no further processing is done.  If a packet is {{ic|ACCEPT}}ed within a chain, it will be {{ic|ACCEPT}}ed in all superset chains also and it will not traverse any of the superset chains any further.  However, be aware that the packet will continue to traverse all other chains in other tables in the normal fashion.
  
 
=== Modules ===
 
=== Modules ===
Line 58: Line 108:
 
There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.
 
There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.
  
== Configuration ==
+
== Configuration and usage ==
 +
 
 +
iptables is a [[systemd]] service and is [[start]]ed accordingly. However, the service won't start unless it finds an {{ic|/etc/iptables/iptables.rules}} file, which is not provided by the Arch {{Pkg|iptables}} package. So to start the service for the first time:
 +
 
 +
# touch /etc/iptables/iptables.rules
 +
 
 +
or
 +
 
 +
# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules
 +
 
 +
Then [[start]] the {{ic|iptables.service}} unit. As with other services, if you want iptables to be loaded automatically on boot, you must [[enable]] it.
 +
 
 +
iptables rules for IPv6 are, by default, stored in {{ic|/etc/iptables/ip6tables.rules}}, which is read by {{ic|ip6tables.service}}. You can start it the same way as above.
 +
 
 +
{{Note|1=Since {{Pkg|iptables}}-1.6.0-1 the {{ic|iptables.service}} and {{ic|ip6tables.service}} refer to the {{ic|network-pre.target}} so that the firewall is started before any network is configured. Respective manual configuration changes to achieve this for prior versions ({{Bug|33478}}) can be dropped.[https://bugs.freedesktop.org/show_bug.cgi?id=79600]}}
 +
 
 +
After adding rules via command-line as shown in the following sections, the configuration file is not changed automatically &mdash; you have to save it manually:
 +
 
 +
# iptables-save > /etc/iptables/iptables.rules
 +
 
 +
If you edit the configuration file manually, you have to [[reload]] iptables.
 +
 
 +
Or you can load it directly through iptables:
 +
 
 +
# iptables-restore < /etc/iptables/iptables.rules
  
 
=== From the command line ===
 
=== From the command line ===
Line 64: Line 138:
 
==== Showing the current rules ====
 
==== Showing the current rules ====
  
You can check the current ruleset and the number of hits per rule by using the command:
+
The basic command to list current rules is {{ic|--list-rules}} ({{ic|-S}}), which is similar in output format to the ''iptables-save'' utility. The main difference of the two is that the latter outputs the rules of all tables per default, while all ''iptables'' commands default to the {{ic|filter}} table only.
 +
 
 +
When working with iptables on the command line, the {{ic|--list}} ({{ic|-L}}) command accepts more modifiers and shows more information. For example, you can check the current ruleset and the number of hits per rule by using the command:
  
 
{{hc|# iptables -nvL|Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 
{{hc|# iptables -nvL|Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target    prot opt in    out    source              destination  
+
  pkts bytes target    prot opt in    out    source              destination
   
+
 
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target    prot opt in    out    source              destination  
+
  pkts bytes target    prot opt in    out    source              destination
   
+
 
Chain OUTPUT (policy ACCEPT 0K packets, 0 bytes)
+
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 
  pkts bytes target    prot opt in    out    source              destination}}
 
  pkts bytes target    prot opt in    out    source              destination}}
  
If the output looks like the above, then there are no rules. Nothing is blocked.
+
If the output looks like the above, then there are no rules (i.e. nothing is blocked) in the default {{ic|filter}} table. An other table can be specified with the {{ic|-t}} option.
  
To show the line numbers when listing rules, append {{ic|--line-numbers}} to that input. This is useful when deleting and adding individual rules.
+
To show the line numbers when listing rules, append {{ic|--line-numbers}} to that input. The line numbers are a useful shorthand when [[#Editing rules]] on the command line.
 +
 
 +
==== Resetting rules ====
 +
 
 +
You can flush and reset iptables to default using these commands:
 +
 
 +
# iptables -F
 +
# iptables -X
 +
# iptables -t nat -F
 +
# iptables -t nat -X
 +
# iptables -t mangle -F
 +
# iptables -t mangle -X
 +
# iptables -t raw -F
 +
# iptables -t raw -X
 +
# iptables -t security -F
 +
# iptables -t security -X
 +
# iptables -P INPUT ACCEPT
 +
# iptables -P FORWARD ACCEPT
 +
# iptables -P OUTPUT ACCEPT
 +
 
 +
The {{ic|-F}} command with no arguments flushes all the chains in its current table. Similarly, {{ic|-X}} deletes all empty non-default chains in a table.
 +
 
 +
Individual chains may be flushed or deleted by following {{ic|-F}} and {{ic|-X}} with a {{ic|[chain]}} argument.
  
 
==== Editing rules ====
 
==== Editing rules ====
  
Rules can be added either by appending a rule to a chain or inserting them at a specific position on the chain. We will explore both methods here.
+
Rules can be edited by appending {{ic|-A}} a rule to a chain, inserting {{ic|-I}} it at a specific position on the chain, replacing {{ic|-R}} an existing rule, or deleting {{ic|-D}} it. The first three commands are exemplified in the following.
  
 
First of all, our computer is not a router (unless, of course, it [[Router|is a router]]). We want to change the default policy on the {{ic|FORWARD}} chain from {{ic|ACCEPT}} to {{ic|DROP}}.
 
First of all, our computer is not a router (unless, of course, it [[Router|is a router]]). We want to change the default policy on the {{ic|FORWARD}} chain from {{ic|ACCEPT}} to {{ic|DROP}}.
Line 89: Line 187:
 
}}
 
}}
  
{{warning|The rest of this section is meant to teach the syntax and concepts behind iptables rules. It is not intended as a means for securing servers. For improving the security of your system, see [[Simple Stateful Firewall]] for a minimally secure iptables configuration and [[Security]] for hardening Arch Linux in general.}}
+
{{warning|The rest of this section is meant to teach the syntax and concepts behind iptables rules. It is not intended as a means for securing servers. For improving the security of your system, see [[Simple stateful firewall]] for a minimally secure iptables configuration and [[Security]] for hardening Arch Linux in general.}}
  
The [[Wikipedia:Dropbox (service)|Dropbox]] LAN sync feature [https://isc.sans.edu/port.html?port=17500 broadcasts packets every 30 seconds] to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets.  
+
The [[Wikipedia:Dropbox (service)|Dropbox]] LAN sync feature [https://isc.sans.edu/port.html?port=17500 broadcasts packets every 30 seconds] to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets.
  
 
{{bc|
 
{{bc|
Line 101: Line 199:
 
|
 
|
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
1        0    0 REJECT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
 
1        0    0 REJECT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
  
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
  
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
  
 
}}
 
}}
{{note|We use {{ic|REJECT}} rather than {{ic|DROP}} here, because [https://tools.ietf.org/html/rfc1122#page-69 RFC 1122 3.3.8] requires hosts return ICMP errors whenever possible, instead of dropping packets. In reality, it is best to {{ic|REJECT}} packets from hosts who should know about your server's existence, and {{ic|DROP}} packets from hosts who should not even know your server exists, or those who appear "up to something".}}
+
{{note|We use {{ic|REJECT}} rather than {{ic|DROP}} here, because [https://tools.ietf.org/html/rfc1122#page-69 RFC 1122 3.3.8] requires hosts return ICMP errors whenever possible, instead of dropping packets. [http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject This page] explains why it is almost always better to REJECT rather than DROP packets.}}
  
 
Now, say we change our mind about Dropbox and decide to install it on our computer. We also want to LAN sync, but only with one particular IP on our network. So we should use {{ic|-R}} to replace our old rule. Where {{ic|10.0.0.85}} is our other IP:
 
Now, say we change our mind about Dropbox and decide to install it on our computer. We also want to LAN sync, but only with one particular IP on our network. So we should use {{ic|-R}} to replace our old rule. Where {{ic|10.0.0.85}} is our other IP:
Line 123: Line 221:
 
|
 
|
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
1        0    0 REJECT    tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
 
1        0    0 REJECT    tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
  
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
  
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
}}
 
}}
  
Line 138: Line 236:
  
 
{{bc|
 
{{bc|
# iptables -I INPUT 1 -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
+
# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
 
}}
 
}}
  
Line 145: Line 243:
 
|
 
|
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
1        0    0 ACCEPT    tcp  --  *      *      10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
 
1        0    0 ACCEPT    tcp  --  *      *      10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
 
2        0    0 REJECT    tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
 
2        0    0 REJECT    tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
  
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
  
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination  
+
num  pkts bytes target    prot opt in    out    source              destination
 
}}
 
}}
  
 
And replace our second rule with one that rejects everything on port {{ic|17500}}:
 
And replace our second rule with one that rejects everything on port {{ic|17500}}:
  
  # iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable  
+
  # iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
  
 
Our final rule list now looks like this:
 
Our final rule list now looks like this:
Line 166: Line 264:
 
|
 
|
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
1        0    0 ACCEPT    tcp  --  *      *      10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
 
1        0    0 ACCEPT    tcp  --  *      *      10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
 
2        0    0 REJECT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
 
2        0    0 REJECT    tcp  --  *      *      0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable
  
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
  
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num  pkts bytes target    prot opt in    out    source              destination        
+
num  pkts bytes target    prot opt in    out    source              destination
 
}}
 
}}
 
==== Resetting rules ====
 
 
You can flush and reset iptables to default using these commands:
 
 
# iptables -F
 
# iptables -X
 
# iptables -t nat -F
 
# iptables -t nat -X
 
# iptables -t mangle -F
 
# iptables -t mangle -X
 
# iptables -t raw -F
 
# iptables -t raw -X
 
# iptables -t security -F
 
# iptables -t security -X
 
# iptables -P INPUT ACCEPT
 
# iptables -P FORWARD ACCEPT
 
# iptables -P OUTPUT ACCEPT
 
 
The {{ic|-F}} command with no arguments flushes all the chains in its current table. Similarly, {{ic|-X}} deletes all empty non-default chains in a table.
 
 
Individual chains may be flushed or deleted by following {{ic|-F}} and {{ic|-X}} with a {{ic|[chain]}} argument.
 
 
=== Configuration file ===
 
 
Iptables rules are by default stored in {{ic|/etc/iptables/iptables.rules}}. This file is read by {{ic|iptables.service}}:
 
 
# systemctl enable iptables.service
 
# systemctl start iptables.service
 
 
Iptables rules for ipv6 are by default stored in {{ic|/etc/iptables/ip6tables.rules}}, this file is read by {{ic|ip6tables.service}}. You can start it the same way as above.
 
 
After adding rules via command-line, the configuration file is not changed automatically - you have to save it manually:
 
 
# iptables-save > /etc/iptables/iptables.rules
 
 
If you edit the configuration file manually, you have to reload it:
 
 
# systemctl reload iptables
 
  
 
=== Guides ===
 
=== Guides ===
Line 229: Line 288:
 
  # iptables -N logdrop
 
  # iptables -N logdrop
  
Then define it:
+
And add the following rules to the newly created chain:
  
  ## /etc/iptables/iptables.rules
+
  # iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
+
  # iptables -A logdrop -j DROP
*filter
+
 
:INPUT DROP [0:0]
+
Explanation for {{ic|limit}} and {{ic|limit-burst}} options is given [[#Limiting log rate|below]].
:FORWARD DROP [0:0]
+
 
:OUTPUT ACCEPT [0:0]
+
Now whenever we want to drop a packet and log this event, we just jump to the {{ic|logdrop}} chain, for example:
+
 
... other user defined chains ..
+
  # iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop
+
## logdrop chain
+
:logdrop - [0:0]
+
+
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
+
  -A logdrop -j DROP
+
+
... rules ...
+
+
## log AND drop packets that hit this rule:
+
  -A INPUT -m state --state INVALID -j logdrop
+
+
... more rules ...
+
  
 
=== Limiting log rate ===
 
=== Limiting log rate ===
  
The limit module should be used to prevent your iptables log from growing too large or causing needless hard drive writes. Without limiting, an attacker could fill your drive (or at least your {{ic|/var}} partition) by causing writes to the iptables log.
+
The above {{ic|logdrop}} chain uses the limit module to prevent the ''iptables'' log from growing too large or causing needless hard drive writes. Without limiting an erroneously configured service trying to connect, or an attacker, could fill the drive (or at least the {{ic|/var}} partition) by causing writes to the iptables log.
 +
 
 +
The limit module is called with {{ic|-m limit}}. You can then use {{ic|--limit}} to set an average rate and {{ic|--limit-burst}} to set an initial burst rate. In the {{ic|logdrop}} example above:
 +
 
 +
iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
 +
 
 +
appends a rule which will log all packets that pass through it. The first 10 consecutive packets will be logged, and from then on only 5 packets per minute will be logged. The "limit burst" count is reset every time the "limit rate" is not broken, i.e. logging activity returns to normal automatically.
  
{{ic|-m limit}} is used to call on the limit module. You can then use {{ic|--limit}} to set an average rate and {{ic|--limit-burst}} to set an initial burst rate. Example:
+
=== Viewing logged packets ===
  
-A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
+
Logged packets are visible as kernel messages in the [[systemd journal]].
  
This appends a rule to the {{ic|logdrop}} chain which will log all packets that pass through it. The first 10 packets will the be logged, and from then on only 5 packets per minute will be logged. The "limit burst" is restored by one every time the "limit rate" is not broken.
+
To view all packets that were logged since the machine was last booted:
 +
# journalctl -k | grep "IN=.*OUT=.*" | less
  
 
=== syslog-ng ===
 
=== syslog-ng ===
{{out of date|[[Syslog-ng]] is no longer the default logger. This section should likely be updated to reflect [[Systemd#Journal|the systemd journal]].}}
 
  
 
Assuming you are using [[syslog-ng]], you can control where iptables' log output goes this way:
 
Assuming you are using [[syslog-ng]], you can control where iptables' log output goes this way:
Line 281: Line 333:
  
 
== See also ==
 
== See also ==
{{Wikipedia|iptables}}
+
* [[Wikipedia:iptables|Wikipedia article]]
* [[Port Knocking]]
+
* [[Port knocking]]
 
* [http://www.netfilter.org/projects/iptables/index.html Official iptables web site]
 
* [http://www.netfilter.org/projects/iptables/index.html Official iptables web site]
 
* [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html iptables Tutorial 1.2.2] by Oskar Andreasson
 
* [http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html iptables Tutorial 1.2.2] by Oskar Andreasson
 
* [http://wiki.debian.org/iptables iptables Debian] Debian wiki
 
* [http://wiki.debian.org/iptables iptables Debian] Debian wiki

Latest revision as of 18:43, 21 April 2016

iptables is a command line utility for configuring Linux kernel firewall implemented within the Netfilter project. The term iptables is also commonly used to refer to this kernel-level firewall. It can be configured directly with iptables, or by using one of the many frontends and GUIs. iptables is used for IPv4 and ip6tables is used for IPv6.

nftables was released in release with Linux kernel 3.13, and will one day replace iptables as the main Linux firewall utility.

Installation

The stock Arch Linux kernel is compiled with iptables support. You will only need to install the userland utilities, which are provided by the package iptables. (The iproute2 package from the base group depends on iptables, so the iptables package should be installed on your system by default.)

Basic concepts

iptables is used to inspect, modify, forward, redirect, and/or drop IPv4 packets. The code for filtering IPv4 packets is already built into the kernel and is organized into a collection of tables, each with a specific purpose. The tables are made up of a set of predefined chains, and the chains contain rules which are traversed in order. Each rule consists of a predicate of potential matches and a corresponding action (called a target) which is executed if the predicate is true; i.e. the conditions are matched. iptables is the user utility which allows you to work with these chains/rules. Most new users find the complexities of linux IP routing quite daunting, but, in practice, the most common use cases (NAT and/or basic Internet firewall) are considerably less complex.

The key to understanding how iptables works is this chart. The lowercase word on top is the table and the upper case word below is the chain. Every IP packet that comes in on any network interface passes through this flow chart from top to bottom. A common source of confusion is that packets entering from, say, an internal interface are handled differently than packets from an Internet-facing interface. All interfaces are handled the same way; it's up to you to define rules that treat them differently. Of course some packets are intended for local processes, hence come in from the top of the chart and stop at <Local Process>, while other packets are generated by local processes; hence start at <Local Process> and proceed downward through the flowchart. A detailed explanation of how this flow chart works can be found here.

In the vast majority of use cases you won't need to use the raw, mangle, or security tables at all. Consequently, the following chart depicts a simplified network packet flow through iptables:

                               XXXXXXXXXXXXXXXXXX
                             XXX     Network    XXX
                               XXXXXXXXXXXXXXXXXX
                                       +
                                       |
                                       v
 +-------------+              +------------------+
 |table: filter| <---+        | table: nat       |
 |chain: INPUT |     |        | chain: PREROUTING|
 +-----+-------+     |        +--------+---------+
       |             |                 |
       v             |                 v
 [local process]     |           ****************          +--------------+
       |             +---------+ Routing decision +------> |table: filter |
       v                         ****************          |chain: FORWARD|
****************                                           +------+-------+
Routing decision                                                  |
****************                                                  |
       |                                                          |
       v                        ****************                  |
+-------------+       +------>  Routing decision  <---------------+
|table: nat   |       |         ****************
|chain: OUTPUT|       |               +
+-----+-------+       |               |
      |               |               v
      v               |      +-------------------+
+--------------+      |      | table: nat        |
|table: filter | +----+      | chain: POSTROUTING|
|chain: OUTPUT |             +--------+----------+
+--------------+                      |
                                      v
                               XXXXXXXXXXXXXXXXXX
                             XXX    Network     XXX
                               XXXXXXXXXXXXXXXXXX

Tables

iptables contains five tables:

  1. raw is used only for configuring packets so that they are exempt from connection tracking.
  2. filter is the default table, and is where all the actions typically associated with a firewall take place.
  3. nat is used for network address translation (e.g. port forwarding).
  4. mangle is used for specialized packet alterations.
  5. security is used for Mandatory Access Control networking rules (e.g. SELinux -- see this article for more details).

In most common use cases you will only use two of these: filter and nat. The other tables are aimed at complex configurations involving multiple routers and routing decisions and are in any case beyond the scope of these introductory remarks.

Chains

Tables consist of chains, which are lists of rules which are followed in order. The default table, filter, contains three built-in chains: INPUT, OUTPUT and FORWARD which are activated at different points of the packet filtering process, as illustrated in the flow chart. The nat table includes PREROUTING, POSTROUTING, and OUTPUT chains.

See man 8 iptables for a description of built-in chains in other tables.

By default, none of the chains contain any rules. It is up to you to append rules to the chains that you want to use. Chains do have a default policy, which is generally set to ACCEPT, but can be reset to DROP, if you want to be sure that nothing slips through your ruleset. The default policy always applies at the end of a chain only. Hence, the packet has to pass through all existing rules in the chain before the default policy is applied.

User-defined chains can be added to make rulesets more efficient or more easily modifiable. See Simple stateful firewall for an example of how user-defined chains are used.

Rules

Packet filtering is based on rules, which are specified by multiple matches (conditions the packet must satisfy so that the rule can be applied), and one target (action taken when the packet matches all conditions). The typical things a rule might match on are what interface the packet came in on (e.g eth0 or eth1), what type of packet it is (ICMP, TCP, or UDP), or the destination port of the packet.

Targets are specified using the -j or --jump option. Targets can be either user-defined chains (i.e. if these conditions are matched, jump to the following user-defined chain and continue processing there), one of the special built-in targets, or a target extension. Built-in targets are ACCEPT, DROP, QUEUE and RETURN, target extensions are, for example, REJECT and LOG. If the target is a built-in target, the fate of the packet is decided immediately and processing of the packet in current table is stopped. If the target is a user-defined chain and the fate of the packet is not decided by this second chain, it will be filtered against the remaining rules of the original chain. Target extensions can be either terminating (as built-in targets) or non-terminating (as user-defined chains), see man 8 iptables-extensions for details.

Traversing Chains

A network packet received on any interface traverses the traffic control chains of tables in the order shown in the flow chart. The first routing decision involves deciding if the final destination of the packet is the local machine (in which case the packet traverses through the INPUT chains) or elsewhere (in which case the packet traverses through the FORWARD chains). Subsequent routing decisions involve deciding what interface to assign to an outgoing packet. At each chain in the path, every rule in that chain is evaluated in order and whenever a rule matches, the corresponding target/jump action is executed. The 3 most commonly used targets are ACCEPT, DROP, and jump to a user-defined chain. While built-in chains can have default policies, user-defined chains can not. If every rule in a chain that you jumped fails to provide a complete match, the packet is dropped back into the calling chain as illustrated here. If at any time a complete match is achieved for a rule with a DROP target, the packet is dropped and no further processing is done. If a packet is ACCEPTed within a chain, it will be ACCEPTed in all superset chains also and it will not traverse any of the superset chains any further. However, be aware that the packet will continue to traverse all other chains in other tables in the normal fashion.

Modules

There are many modules which can be used to extend iptables such as connlimit, conntrack, limit and recent. These modules add extra functionality to allow complex filtering rules.

Configuration and usage

iptables is a systemd service and is started accordingly. However, the service won't start unless it finds an /etc/iptables/iptables.rules file, which is not provided by the Arch iptables package. So to start the service for the first time:

# touch /etc/iptables/iptables.rules

or

# cp /etc/iptables/empty.rules /etc/iptables/iptables.rules

Then start the iptables.service unit. As with other services, if you want iptables to be loaded automatically on boot, you must enable it.

iptables rules for IPv6 are, by default, stored in /etc/iptables/ip6tables.rules, which is read by ip6tables.service. You can start it the same way as above.

Note: Since iptables-1.6.0-1 the iptables.service and ip6tables.service refer to the network-pre.target so that the firewall is started before any network is configured. Respective manual configuration changes to achieve this for prior versions (FS#33478) can be dropped.[1]

After adding rules via command-line as shown in the following sections, the configuration file is not changed automatically — you have to save it manually:

# iptables-save > /etc/iptables/iptables.rules

If you edit the configuration file manually, you have to reload iptables.

Or you can load it directly through iptables:

# iptables-restore < /etc/iptables/iptables.rules

From the command line

Showing the current rules

The basic command to list current rules is --list-rules (-S), which is similar in output format to the iptables-save utility. The main difference of the two is that the latter outputs the rules of all tables per default, while all iptables commands default to the filter table only.

When working with iptables on the command line, the --list (-L) command accepts more modifiers and shows more information. For example, you can check the current ruleset and the number of hits per rule by using the command:

# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

If the output looks like the above, then there are no rules (i.e. nothing is blocked) in the default filter table. An other table can be specified with the -t option.

To show the line numbers when listing rules, append --line-numbers to that input. The line numbers are a useful shorthand when #Editing rules on the command line.

Resetting rules

You can flush and reset iptables to default using these commands:

# iptables -F
# iptables -X
# iptables -t nat -F
# iptables -t nat -X
# iptables -t mangle -F
# iptables -t mangle -X
# iptables -t raw -F
# iptables -t raw -X
# iptables -t security -F
# iptables -t security -X
# iptables -P INPUT ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P OUTPUT ACCEPT

The -F command with no arguments flushes all the chains in its current table. Similarly, -X deletes all empty non-default chains in a table.

Individual chains may be flushed or deleted by following -F and -X with a [chain] argument.

Editing rules

Rules can be edited by appending -A a rule to a chain, inserting -I it at a specific position on the chain, replacing -R an existing rule, or deleting -D it. The first three commands are exemplified in the following.

First of all, our computer is not a router (unless, of course, it is a router). We want to change the default policy on the FORWARD chain from ACCEPT to DROP.

# iptables -P FORWARD DROP
Warning: The rest of this section is meant to teach the syntax and concepts behind iptables rules. It is not intended as a means for securing servers. For improving the security of your system, see Simple stateful firewall for a minimally secure iptables configuration and Security for hardening Arch Linux in general.

The Dropbox LAN sync feature broadcasts packets every 30 seconds to all computers it can see. If we happen to be on a LAN with Dropbox clients and do not use this feature, then we might wish to reject those packets.

# iptables -A INPUT -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Note: We use REJECT rather than DROP here, because RFC 1122 3.3.8 requires hosts return ICMP errors whenever possible, instead of dropping packets. This page explains why it is almost always better to REJECT rather than DROP packets.

Now, say we change our mind about Dropbox and decide to install it on our computer. We also want to LAN sync, but only with one particular IP on our network. So we should use -R to replace our old rule. Where 10.0.0.85 is our other IP:

# iptables -R INPUT 1 -p tcp --dport 17500 ! -s 10.0.0.85 -j REJECT --reject-with icmp-port-unreachable
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

We have now replaced our original rule with one that allows 10.0.0.85 to access port 17500 on our computer. But now we realize that this is not scalable. If our friendly Dropbox user is attempting to access port 17500 on our device, we should allow him immediately, not test him against any firewall rules that might come afterwards!

So we write a new rule to allow our trusted user immediately. Using -I to insert the new rule before our old one:

# iptables -I INPUT -p tcp --dport 17500 -s 10.0.0.85 -j ACCEPT -m comment --comment "Friendly Dropbox"
# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  *      *       10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
2        0     0 REJECT     tcp  --  *      *      !10.0.0.85            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

And replace our second rule with one that rejects everything on port 17500:

# iptables -R INPUT 2 -p tcp --dport 17500 -j REJECT --reject-with icmp-port-unreachable

Our final rule list now looks like this:

# iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 ACCEPT     tcp  --  *      *       10.0.0.85            0.0.0.0/0            tcp dpt:17500 /* Friendly Dropbox */
2        0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:17500 reject-with icmp-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Guides

Logging

The LOG target can be used to log packets that hit a rule. Unlike other targets like ACCEPT or DROP, the packet will continue moving through the chain after hitting a LOG target. This means that in order to enable logging for all dropped packets, you would have to add a duplicate LOG rule before each DROP rule. Since this reduces efficiency and makes things less simple, a logdrop chain can be created instead.

Create the chain with:

# iptables -N logdrop

And add the following rules to the newly created chain:

# iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG
# iptables -A logdrop -j DROP

Explanation for limit and limit-burst options is given below.

Now whenever we want to drop a packet and log this event, we just jump to the logdrop chain, for example:

# iptables -A INPUT -m conntrack --ctstate INVALID -j logdrop

Limiting log rate

The above logdrop chain uses the limit module to prevent the iptables log from growing too large or causing needless hard drive writes. Without limiting an erroneously configured service trying to connect, or an attacker, could fill the drive (or at least the /var partition) by causing writes to the iptables log.

The limit module is called with -m limit. You can then use --limit to set an average rate and --limit-burst to set an initial burst rate. In the logdrop example above:

iptables -A logdrop -m limit --limit 5/m --limit-burst 10 -j LOG

appends a rule which will log all packets that pass through it. The first 10 consecutive packets will be logged, and from then on only 5 packets per minute will be logged. The "limit burst" count is reset every time the "limit rate" is not broken, i.e. logging activity returns to normal automatically.

Viewing logged packets

Logged packets are visible as kernel messages in the systemd journal.

To view all packets that were logged since the machine was last booted:

# journalctl -k | grep "IN=.*OUT=.*" | less

syslog-ng

Assuming you are using syslog-ng, you can control where iptables' log output goes this way:

filter f_everything { level(debug..emerg) and not facility(auth, authpriv); };

to

filter f_everything { level(debug..emerg) and not facility(auth, authpriv) and not filter(f_iptables); };

This will stop logging iptables output to /var/log/everything.log.

If you also want iptables to log to a different file than /var/log/iptables.log, you can simply change the file value of destination d_iptables here (still in syslog-ng.conf)

destination d_iptables { file("/var/log/iptables.log"); };

ulogd

ulogd is a specialized userspace packet logging daemon for netfilter that can replace the default LOG target. The package ulogd is available in the [community] repository.

See also