From the output you've given it looks like the python script is not sending all the pieces of the syslog message that rsyslog is expecting. It appears as if the "{FILTER}" part is where the host and app name should be. You can pretty easily prove this by running rsyslogd with the -d flag then sending the message from python and then from logger. You'll see the raw message as it comes from the socket that way and I bet you'll see that logger is sending more fields in front of the "{FILTER}" part.
The line you are worried about:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere
is actually because of this in your rules:
-A INPUT -i lo -j ACCEPT
Notice the interface is explicit in the rule, but not in the -L output. Move that rule to the middle of the list, use iptables-restore and notice the "ACCEPT all -- anywhere" has moved down too. Now try changing the rule a bit:
-A INPUT -i lo -s 127.0.0.1 -j ACCEPT
and the -L output will become:
target prot opt source destination
ACCEPT all -- localhost.localdomain anywhere
"localhost.localdomain" will be your 127.0.0.1 hostname from /etc/hosts. This at least makes it clearer where that rule came from.
You can also see more detailed information including the interfaces with iptables -vL.
BTW, you may want to start your rules:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
Drop everything by default as a fall through for safety. This is considered bad manners, however (see the link in Gilles comment below), so you may want to create a final catch all for each table which uses -j REJECT --reject-with icmp-net-prohibited.
Best Answer
Because it can easily fill up your logs, the default is to not log. Add a jump to the LOG target, which will log to the kernel log (which you can see with
dmesgor at wherever syslog is configured to write that for your distro). In your LOG-target rule, you can set--log-leveland--log-prefixto help organize the messages and keep them separate from other kernel messages.LOG is a "non-terminating target", so rule traversal will continue on to the next rule — you can basically add logging right above your existing rules without affecting them.