This message is printed by the NAT code, because multicast packets are hitting the NAT table, and connection tracking doesn't handle multicast packets right now. In case you have no idea what multicast is, or don't need it at all, use:
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
My syslog or my console shows the message:
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
This message is printed by the NAT code. It drops packets, because in order to do NAT it has to have valid connection tracking information. This message is printed for all packets for which connection tracking was unable to determine conntrack information.
Possible reasons are:
If you want to have a more detailed logging of these packets (i.e. if you suspect it are remote probe / scanning packets), use the following rule:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
And yes, you have to put the rule in the mangle table, because the packets get dropped by the NAT code before they reach the filter table.
My sylog or console regularly shows messages like:
ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
This is normally nothing to worry about, especially if N and
M are 1, and the message is followed by , reusing.
In particular versions of the linux kernel (2.4.19<=x<=2.4.21-pre3), this
message was printed for FTP - And in fact this can happen during normal FTP
operation.
With upcoming kernel versions (>=2.4.21-pre4) this message is no longer printed to not confuse the user. If you still receive messages like this, contact the http://lists.netfilter.org/mailman/listinfo/netfilter-devel mailinglist.
So you want to build a completely transparent firewall? Great idea! As of kernel 2.4.16, you still need to patch your kernel with an extra patch to get this running. You can find it at http://bridge.sourceforge.net/.
Well, that's half the truth. Only the NAT module is unable to handle them. If you just use firewalling without NAT it should work fine. Patches welcome.
Netfilter tries to mangle as little as possible. So if we have a freshly- rebooted machine, and somebody behind the SNAT box opens a connection with local port 1234, the netfilter box only mangles the IP address and the port stays the same.
As soon as somebody else opens another connection with the same source port, netfilter would have to mangle IP and port if it only has a single IP for SNAT.
But if there are more than one available, it again only has to mangle the IP part.
If you notice the following message in syslog, it looks like the conntrack database doesn't have enough entries for your environment. Connection tracking by default handles up to a certain number of simultaneous connections. This number is dependent on you system's maximum memory size (at 64MB: 4096, 128MB: 8192, ...).
You can easily increase the number of maximal tracked connections, but be aware that each tracked connection eats about 350 bytes of non-swappable kernel memory!
To increase this limit to e.g. 8192, type:
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
To optimize performance, please also raise the number of hash buckets by using
the hashsize module loadtime parameter of the ip_conntrack.o
module. Please note that due to the nature of the current hashing algorithm, an
even hash bucket count (and esp. values of the power of two) are a bad choice.
Example (with 1023 buckets):
modprobe ip_conntrack hashsize=1023
There is a file in the proc-filesystem, which is called /proc/net/ip_conntrack. You can print the output of this file using
cat /proc/net/ip_conntrack
All available IP tables are listed with
cat /proc/net/ip_tables_names
Known Bug. Please update to latest CVS or use iptables >= 1.2.1 as soon as it is available.
This is because iptables does a DNS lookup for each IP address. As each rule consists out of two addresses, the worst case is two DNS lookups per rule.
The problem is, if you use private IP addresses (like 10.x.x.x or 192.168.x.x), DNS is unable to resolve a hostname and times out. The sum of all these timeouts may be _very_ long, depending on your ruleset.
Please use the -n (numeric) option for iptables in order to prevent it from making reverse DNS lookups.
You have to configure your syslogd and/or klogd appropriately: The LOG target logs to facility kern at priority warning (4). See the syslogd.conf manpage to learn more about facilities and priorities.
By default, all kernel messages at priority more severe than debug (7) are sent to the console. If you raise that to 4, instead of 7, you will make the LOG messages no longer appear on the console.
Be aware that this might also suppress other important messages from appearing on the console (does not affect syslog).
First, of course, you need a suitable DNAT or REDIRECT rule. Use REDIRECT only if squid is running on the NAT box itself. Example:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
After that, you have to configure squid appropriately. We can only give short notes here, please refer to the squid documentation for further details.
The squid.conf for Squid 2.3 needs to be something like the following:
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
httpd_accel_single_host off
The LOG target is what we call a "non-terminating target", i.e. it doesn't terminate the packets rule traversal. If you use the LOG target, the packet will be logged, and rule traversal continues at the next rule.
So how do I log and drop at the same time? Nothing easier than that, you create a custom chain which contains the two rules:
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
Now everytime you want to log and drop a packet, you can easily use a "-j logdrop".
The short answer is you cannot do that properly with netfilter. Most of the worms are using a legitimate high level protocol (i.e. HTTP, SMTP(i.e VB script attached in email), or any exploit of a vulnerability found in the daemon handling the protocol). By high level protocol, we mean above TCP/IP. As iptables does not understand these high level protocols, it's almost impossible to filter part of them out properly. For that you need application filtering proxies.
Please do not use the string match from patch-o-matic instead of application proxy filtering. It would be defeated anytime by fragmented packets (i.e. an HTTP request split on two TCP packets), by IDS evasion techniques, etc... you have been warned! The string match is useful but for different purposes.
You use the tcp-window-tracking patch from patch-o-matic, which code keeps track the acceptable packets for the allowed TCP streams according to the sequence/acknowledgement numbers, segment sizes, etc of the packets. When it detects that one of the packets is not acceptable (out of the window), it marks it as INVALID and prints the message above.
Newer versions logs the packet and exactly what condition failed for it:
Also, in newer versions the logging can completely be suppressed via sysctl
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
First, check if you are running a 2.4.20 kernel. If yes, please apply immediately the patch from https://bugzilla.netfilter.org/cgi-bin/bugzilla/showattachment.cgi?attach_id=8! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=56).
So you have read /proc/net/ip_conntrack and found UNREPLIED entries with a very high timer (can be up to five days) and are wondering why we want to waste conntrack entries with UNREPLIED entries (which are obviously not connections)?
The answer is easy: UNREPLIED entries are temporary entries, i.e. as soon as we run out of connection tracking entries (we reach /proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries. In other words: instead of having empty conntrack entries, we'd rather keep some maybe useful information in them until we really need them.
Well, first of all, we're lazy ;). To be honest, implementing a check option is almost impossible as soon as you start to do stateful firewalling. Traditional stateless firewalling bases it's decision just on information present in the packets header. But with connection tracking (and '-m state' based rules), the outcome of the filtering decision depends on header+payload, as well as header+payload of previous packets within this connection.
The REJECT target is for filtering. The filter table has got the INPUT/OUPUT/FORWARD chains, therfore the REJECT target can only be used in those chains (and sub-chains, naturally).
Netfilter users do not filter packets in the nat or mangle tables.
You have just upgraded your kernel and suddenly some of the commands (especially in the 'nat' table), and you experience something like:
# iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
iptables: Invalid argument
This happens when the structure size between kernel and userspace changes. You will need to recompile the iptables userspace program using the include files of your new kernel. This only happens if you (or the vendor of your kernel) has applied some patches either only to the old or only to the new kernel. It is not supposed to happen between vanilla kernel.org kernels. If it does, please inform the netfilter-devel mailinglist.