[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] Firewall-Problem with SynCE



Hello Andreas,

> yesterday I synced a PocketPC over synce to my SuSE 8.2 box. The
> interface is USB-Port ttyUSB1. The sync functined fine without the
> SuSEfirewall2 (stoped). If I started the Firewall again, there are
> the following messages in /var/log/messages:
>
> Jan 11 20:22:56 linux kernel: SuSE-FW-DROP-ANTI-SPOOF IN=ppp0 OUT=
> MAC= SRC=192.168.131.201 DST=192.168.131.102 LEN=64 TOS=0x00
> PREC=0x00 TTL=128 ID=60971 DF PROTO=TCP SPT=1201 DPT=5679
> WINDOW=32768 RES=0x00 SYN URGP=0 OPT
> (020405B4010303000101080A000000000000000001010402)

I am not 100% sure - but almost... This probably comes from the fact
that the "external" port of your firewall has private address and the
firewall scripts expect it to have public address. Therefore firewall
considers the source address to be spoofed since the private addresses
such as 192.168.x.y range can not appear in the (public) Internet.

If you check the script for the firewall (probably /sbin/SuSEfirewall2 as
in SuSE 8.1) you will find lines where this issues is discussed, use
"find" to search lines containing string "192.168".

There is a customary rule subroutine that is called before setting up
these anti-spoofing and I think you might set your special rules in that
subroutine and allow the connection from your PocketPC BEFORE the
firewall drops/denies it. I gues you should define the subroutine
"fw_custom_before_antispoofing()" in the /etc/sysconfig/SuSEfirewall2
settings file for this purpose. You can probably find a lot more information
about this in /usr/share/doc/packages/SuSEfirewall2/README,
as pointed out by the firewall script.

>
> The sync failed.
>
> The command route -n bring me the following output:
>
>  Ziel            Router          Genmask         Flags Metric Ref    
> Use Iface
> 192.168.131.201 0.0.0.0         255.255.255.255 UH    0      0        
> 0 ppp0
> 192.168.22.0    0.0.0.0         255.255.255.0   U     0      0        
> 0 eth0
> 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        
> 0 eth1
>
> My configuration of SuSEFW2:
>
> FW_DEV_EXT="ppp0"
> FW_DEV_INT="eth1"
> FW_ROUTE="yes"
> FW_MASQUERADE="yes"
> FW_MASQ_DEV="$FW_DEV_EXT"
> FW_MASQ_NETS="192.168.0.0/16"
> FW_PROTECT_FROM_INTERNAL="no"
> FW_AUTOPROTECT_SERVICES="yes"
> FW_SERVICES_EXT_TCP="13 10001"
> FW_SERVICES_EXT_UDP="13"
> FW_SERVICES_INT_TCP="22 80 119 8080 10001 139 5678 5679 990"
> FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes"
> FW_ALLOW_INCOMING_HIGHPORTS_UDP="DNS"
>
> The other points of the FW-script are default.
>
> My questions:
> 1.) In FW_SERVICES_INT_TCP I added Port 5678, 5679 and 990 because
> the SynCE-Documation tells me, that the PocketPC need Access to the
> PC on Port 5678, 5679 and the PC on the PocketPC on Port 990. Is
> this the right way to configure this?
> 2.) I don't know the meaning of the message above. Is there a
> documentation to learn about?

Spoofing here would mean that the firewall thinks that the source
address of the incoming packet is false/crafted. Judged as such since
the address is (as said) from private range and coming into a firewall
port which is assumed to be public (by default). It is a good feature
but causes problems when you are making a firewall between two
private networks. I had the same problem once when I was teaching
the firewall setup to a small group of others interested in Linux. Did not
have the time to fix it back then but guessed what the problem might
be.

If you want to learn more... In my opinion (note opinion here) the
"TCP/IP Illustrated" group of books by Richard W Stevens are
excellent for learning more about this and TCP/UDP/IP. Then
there is a couple of good books about network intrusion detection
which handle these issues merely from the attack side (meaning
that they leave a lot of general IP issues out). I can check what I
have in my book shelf.

best regards,

timo räty



--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here