Description of problem: When loading iptables parameters from /etc/sysconfig/iptables file, --log-prefix and may be other log parameters are not prolerly loaded. Version-Release number of selected component (if applicable): iptables-1.4.12.2-5.fc17.x86_64 kernel-3.3.7-1.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. systemctl stop iptables.service 2. iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags RST RST -j LOG --log-prefix "TELNET-D " --log-level 3 3. iptables-save > /etc/sysconfig/iptables 4. systemctl restart iptables.service 5. iptables -L INPUT Actual results: Chain INPUT (policy ACCEPT) target prot opt source destination LOG tcp -- anywhere anywhere tcp dpt:sshflags: RST/RST LOG level error prefix "--log-pre" Expected results: LOG tcp -- anywhere anywhere tcp dpt:sshflags: RST/RST LOG level error prefix "TELNET-D " Additional info: As you see, TELNET-D has been replace by --log-pre. This started happening in Fedora 17, no same problem in Fedora 16.
I am having the exact same issue in Fedora 17. My exact same firewall script worked just fine with F16.
*** Bug 836738 has been marked as a duplicate of this bug. ***
(!) From bug 827919 comment 3: Patch available on http://bugzilla.netfilter.org/show_bug.cgi?id=774 (!)
*** Bug 827919 has been marked as a duplicate of this bug. ***
From http://bugzilla.netfilter.org/show_bug.cgi?id=774 : | With optimization flags -O1 or higher, this bug kicks in. | It is a tricky one that the compiler does not catch. No wonder, | it is undefined behavior.
Ping. Patch looks simple and it's from upstream. Why it's problem to apply it? Can I help?
it is really NOT funny if iptables are messed up this is a CORE security component on each system
I built IPTables v1.4.14 with optimization turned off (removed -O2 from Makefiles). Everything seems to work correctly. The Firewall is operational and log-prefix is correctly working. So is this a Compiler issue or a IPTables issue?
Yes, I ran into this too. The issue is that the gcc optimizer is optimizing out the code that collects quoted strings in iptables-restore.c at line 396. If inside a quotemark and it hasn't seen another one yet, it executes param_buffer[param_len++] = *curchar; continue; At -O1 or higher, the write to param_buffer[] never happens. It just increments param_len and continues. Moving the definition of char param_buffer[1024]; outside the loop fixes it. Why, I'm not sure. Defining the param_buffer[] inside the loop should simply restrict its scope to inside the loop.
The new 1.4.14 version is working for me without the need to change optimization flags. Please have a look at the testing package.
iptables-1.4.14-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/iptables-1.4.14-1.fc17
not confirmed! iptables-1.4.14-1.fc17.x86_64 * iptables updated * iptables.sh called * all looked fine first * after reboot see below ________________________ [root@rh:~]$ /sbin/iptables --list --numeric --verbose | grep LOG 0 0 LOG udp -- br0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG tcp -- br0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG udp -- bond0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG tcp -- bond0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG udp -- eth1 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG tcp -- eth1 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG udp -- eth0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 70 name: udpflood side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG tcp -- eth0 * !10.0.0.0/24 0.0.0.0/0 state NEW recent: UPDATE seconds: 2 hit_count: 150 name: DEFAULT side: source limit: avg 1/min burst 5 LOG flags 0 level 7 prefix "--log-prefix" 0 0 LOG tcp -- !lo * !10.0.0.0/24 0.0.0.0/0 multiport dports 19,24,52,79,109,142,442,464,548,586,631,992,994,3305 limit: avg 10/hour burst 5 LOG flags 0 level 7 prefix "--log-prefix"
*** Bug 828660 has been marked as a duplicate of this bug. ***
Please have a look at https://admin.fedoraproject.org/updates/iptables-1.4.14-2.fc17 I have added the fixrestore patch.
Package iptables-1.4.14-2.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing iptables-1.4.14-2.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-10826/iptables-1.4.14-2.fc17 then log in and leave karma (feedback).
iptables-1.4.14-2.fc17.x86_64 fixes the problem here i left karma.....
I loaded the "updates-testing" version on one machine, for testing. It looks like it does fix this BUG. I will wait for the official release to update the other machines. Thanks!
iptables-1.4.14-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.