What is SFW2-IN-ILL-TARGET and why does it happen even when SuSEfirewall2 is off?

statguy · 08-10-2005, 07:32 AM

I get tons of messages in my log files that seem to be from SuSEfirewall2. They all have a form similar to:

Code:

Aug 10 08:14:41 rho kernel: SFW2-IN-ILL-TARGET IN=eth0 OUT= MAC= SRC=x.x.x.x DST=y.y.y.y LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=11 DF PROTO=UDP SPT=137 DPT=137 LEN=58

(Note: I sanitized the SRC and DST IP numbers).

The funny thing is these messages also appear when the firewall is disabled!

What does this message mean and why would it appear with the firewall off?

I want to review the firewall messages for "real" issues but they are swamped with these SFW2-IN-ILL-TARGET messages. I have googled that term but many of the hits are in German.

yapp · 08-10-2005, 08:42 AM

I'm not sure about the issue either, but are you sure your firewall is off? maybe you stopped the init script instead of the real thing..?

Try the following:

Code:

iptables -L   # lists all active rules
rcSuSEfirewall2 stop  # easy stop command, an alias for /etc/init.d/SuSEfirewall2_setup

To filter the messages in the firewall, try grep -v e.g:

Code:

grep -v ILL-TARGET /var/log/messages
   or
cat /var/log/messages | grep -v ILL-TARGET

statguy · 08-10-2005, 08:59 AM

Oops.

I used to have the firewall disabled at home. I forgot I re-enabled it.

I would still like to know what the SFW2-IN-ILL-TARGET means however.

I should have mentioned (in case it's relevant) my SuSE version is 9.2.

yapp · 08-10-2005, 09:16 AM

Looking at the iptable rules (iptables -L), it appears that the ILL-TARGET is activated after all input chains are skipped.

ILL-TARGET stands for ILLEGAL-TARGET off course.

In other words, the packet didn't match the input ext, int or dmz zones. Maybe you need to adjust the IP settings of those zones?

statguy · 08-10-2005, 09:48 AM

Thanks. I only have an external interface configured. I confess that the output from iptables -L is almost meaningless to me, but am interested in learning. It would seem there is more configuration present than is obviously accessable from YaST (the firewall module or the sysconfig module).

Is the man page for iptables the best place to start to learn what is going on or can you recommend a better starting place?

yapp · 08-10-2005, 11:51 AM

Well, you don't have the be an iptables expert to configure the firewall in SuSE. That's the whole point of the SuSEfirewall script.
I have to agree, if you haven't written any iptable rules yourself, the "iptables -L" output is confusing to say the least.

You can configure the firewall in YaST, or edit /etc/sysconfig/SuSEfirewall2 with a text editor.
I've written my own iptable scripts in the past, but I'm glad SuSEfirewall2 does the job too. It never misses anything

My system sits behind a NAT router, so I only have one interface configured.

Some background on iptables:

How to read the "iptables -L" output:
1. each incoming and outgoing network packet passes through a number of "chains", or "tables".
( there are different types: nat, filter and mangle. the "filter" type does the firewall work)
2. incoming packets start at the "INPUT" chain, outgoing at the "OUTPUT" chain.
3. the packet passes all rules, until one matches.
4. finally, the packet either ends in a "ACCEPT", "DROP" or "REJECT" target.

instead of "iptables -L -v", try "iptables-save", that output is more compact and detailed.

The formatting of the iptables-save output is identical to the parameters passed at the commandline "iptables" program.

The arguments have the following meaning:
-A : append, adds a new rule
-i : defines the incoming network interface the rule applies to
-o : defines the outgoing network interface the rule applies to
-m : passes the packet through a module, often with it's own parameters
-j : jumps to another target or chain (e.g. the input_ext chain, or the ACCEPT target)
the packet returns to the previous chain if none of the rules matched.
-p : defines the network protocol the rule applies to
--dport : defines the network port the rule applies to

As example, the following line adds a new rule to the "input_ext" chain,
all incoming packets received at tcp port 80 (that's http) are accepted.

Code:

iptables -A input_ext -p tcp -m tcp --dport 80 -j ACCEPT

hopefully you'll be able to understand some of the "iptables-save" output now.
If you have any questions, I'd like to know them.

statguy · 08-10-2005, 01:15 PM

Yapp,

First, thanks for taking the time to write such a helpful reply. If you don't mind, I'd like to see if I am "getting" this. To simplify, I'm just looking at the INPUT chain which is where the ILL_TARGET is coming from. Running the command

iptables-save | grep INPUT

gives the following:

Code:

:INPUT ACCEPT [22557:18120831]
:INPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m limit --limit 3/min -j LOG --log-prefix "SFW2-IN-ILL-TARGET " --log-tcp-options --log-ip-options
-A INPUT -j DROP

I don't know what the first two lines mean so will skip them for the moment.

The first rule: "-A INPUT -i lo -j ACCEPT" I read as accepting everything on the loopback interface.

I read the second rule as accpeting packets related to an established connection that I (presumably) have initiated.

Anything else is then logged (third rule) and dropped (fourth rule).

Can I now ask about a couple of the log entries. In what follows, my IP will appear as x.x.x.109 and x.x.x.255 is the Bcast address. Anything else in my subnet will be x.x.x.??? and external will be shown completely.

First:

Code:

Aug 10 13:49:28 rho kernel: SFW2-IN-ILL-TARGET IN=eth0 OUT=
MAC= SRC=x.x.x.109 DST=x.x.x.255 LEN=232
TOS=0x00 PREC=0x00 TTL=64 ID=54 DF PROTO=UDP SP
T=138 DPT=138 LEN=212

So here we have packets being dropped that originate from my machine destined for my Bcast IP (I don't really know what the is).

Second:

Code:

Aug 10 13:59:58 rho kernel: SFW2-IN-ILL-TARGET IN=eth0 OUT=
MAC=ff:ff:ff:ff:ff:ff:00:c0:85:2e:cf:69:08:00 SRC=x.x.x.114
DST=x.x.x.255 LEN=229 TOS=0x00 PREC=0x00 TTL=30 ID=60454
PROTO=UDP SPT=138 DPT=138 LEN=209

Here a packet from a machine in my subnet destined for the Bcast address has been dropped.

Third:

Code:

Aug 10 13:45:22 rho kernel: SFW2-IN-ILL-TARGET IN=eth0 OUT=
MAC=00:0f:b0:69:83:c7:00:e0:52:d8:0c:00:08:00
SRC=205.160.42.65 DST=x.x.x.109 LEN=52 TOS=0x00
PREC=0x00 TTL=11 ID=53411 PROTO=ICMP TYPE=8 CODE=0
ID=40046 SEQ=0

Here, a packet from outside my domain which was destined for my actual IP address has been dropped.

So, if my interpretation is right, the packets destined for the Bcast address as well as my own address are subject to filtering. Is this correct and if so why? Then, can packets destined for x.x.x.255 be safely ignored while packets directed directly at my IP possibly need attention?

Thanks again. I'm learning a lot today!

yapp · 08-10-2005, 04:54 PM

Your observations are correct

Cool you've picked them up so quickly.
The first two lines can be ignored btw, only the -A lines are important. I assume the others initiate the chains. (which you usually do with iptables -N on the command line) After all, you're looking at an "export" file which iptables-read should be able to "import" somehow.

A broadcast address (ending with 255) is a special address. If a router receives such packet, it forwards it to all other nodes. This allows windows file/printer sharing systems to announce themselves for example.

What you're seeing here is samba (or windows file/printer sharing) trying to communicatie. Ports 137-139 (SPT=source port, DPT=destination port) for both TCP and UDP traffic are used for this. How you can what the port numbers mean..? First there is google, second some technical knowledge, and third there is /etc/services where these are all listed.

The last message (PROTO=ICMP TYPE=8) is an "ICMP type 8" message. With "iptables -L" you'd see the term "echo-request". In other words, you've blocked a standard ping. Sometimes it's unfortunate you need to have this kind of network-knowledge to debug the firewall logs.

I'm surprised you don't have an "input_ext" or "input_int" chain. Have you configured the firewall with YaST once? You can also change /etc/sysconfig/SuSEfirewall2 manually, and set FW_DEV_INT="eth0" (I'm assuming you're behind a ADSL/NAT router here) and restart SuSEfirewall2. Then you can open the ports 137-139 and 445 for TCP and UDP traffic. This allows other systems to connect to your samba servers. (in other words, the shares available on your system).

Cheers!

statguy · 08-10-2005, 06:57 PM

I do have the input_ext, input_int and input_dmz chains. I just focussed on the INPUT chain for simplicity and because that's where the message I was asking about came from.

I actually am familar with ports 137-9 and 445 because I have explicitly blocked them from LAN to WAN (135-9 actually) on my router. The joys of having an XP box on your network.

Thanks for all the information you've provided. Very helpful and I have learned tons.

Cheers.