anti-spoofing pushes me to the edges

[jacobsen]

hello dear friends,

Our Antispoofing is not working like expected.
There are always some packets dropped due to anti-spoofing - even if
antispoofing and the topolgy settings are configured like they should.
(well, as far as i understand it)
I really dont know why on earth this happens.
hopefully, one of you can point me to the right way...

here it comes:

Nokia VRRP cluster (R60 HFA4, IPSO 4.1-22) managed by P1.
-eth-s3p3c0 is LAN (10.0.0.0/8)
-eth-s1/s1p1c4 is DMZ (172.18.254.1/24)
there are some subnets reachable via 172.18.254.x

S     172.18.18/24        via 172.18.254.11, eth-s1/s1p1c4, cost 0, age 1144033
S     172.18.64/19        via 172.18.254.13, eth-s1/s1p1c4, cost 0, age 1144033
S     172.18.96/19        via 172.18.254.15, eth-s1/s1p1c4, cost 0, age 1144033
S     172.18/19           via 172.18.254.11, eth-s1/s1p1c4, cost 0, age 1144033

Topology for eth-s1/s1p1c4 is set on the cluster interface (module interfaces are clean=not defined)
>Internal > specific > group "dmz"

group "dmz" consists of:

Networkobject_172.18.254.0-24
Networkobject_172.18.18.0-24
Networkobject_172.18.64.0-19
Networkobject_172.18.96.0-19
Networkobject_172.18.0.0-19

Option "Performe Anti-spoofing" is not checked



Topology for eth-s3p3c0 is "not defined"

Thats what fw monitor gets:

eth-s3p3c0:i[63]: 10.80.73.106 -> 172.18.95.254 (UDP) len=63 id=44237
UDP: 2967 -> 2967
eth-s3p3c0:I[63]: 10.80.73.106 -> 172.18.95.254 (UDP) len=63 id=44237
UDP: 2967 -> 2967
eth-s1/s1p1c4:o[63]: 10.80.73.106 -> 172.18.95.254 (UDP) len=63 id=44237
UDP: 2967 -> 2967

and thats the entry in the logfile:

Number:      	1664401
Date:            	3Mar2007
Time:           	17:16:40
Product:       	VPN-1 Pro/Express
Interface:     	eth-s1/s1p1c4
Origin:         	firewall (10.0.0.1)
Type:           	Alert
Action:         	Drop
Protocol:      	udp
Service:       	UDP_2967 (2967)
Source:        	client (10.80.73.106)
Destination: 	target (172.18.95.254)
Source Port:	UDP_2967 (2967)
Information: 	message_info: Local interface address spoofing

I grep'ed through $FWDIR/conf/objects_5_0.C for "perform_anti_spoofing" and got only "false" back.
But one entry on objects_5_0.C caught my attention: fw_local_interface_anti_spoof (true)
what exactly does that mean? Well, the drop information is "Local interface address spoofing" - does "fw_local_interface_anti_spoof (true)" has to do something with it?

any replay is very much welcome
cheers
J

UPDATE
I found the article sk25911. It explains, what fw_local_interface_anti_spoof (true) is used for.
But the question now is, why does the module think, the ip 10.80.73.106 or 172.18.95.254 belongs to a local interface?

[dantro]

Hi fella,

ich finde die gesamte Konstellation nicht gerade glücklich gewählt. Das 10er Netz für das LAN hätte man sicher mit einer 16er oder noch besser 24er Maske definieren können (Stichpunkt VPN zu anderen Netzen, wo sich ebenfalls oftmals 10er Netze befinden, bzw. 'Group with Exclusions' wenn sich in Außenstellen auch 10er Netze befinden) oder die 172er mit 24er Maske. Ferner kann "Networkobject_172.18.18.24-24" nicht ganz stimmen. Wäre es eine 24er Maske hieße das Netz: 172.18.18.0. Es wurde auch nicht angegeben, ob die Netze einschließlich der Broadcastadresse definiert wurden. Die UDP Anfrage geht nämlich genau auf die letzte Adresse vor dem Broadcast.

Eine Firewall ist dazu da Sicherheit zu schaffen. Anti-Spoofing abzuschalten ist die letzte Alternative, welche man ergreifen sollte. Ich empfehle einfach mal ein CPINFO zu erstellen und an den CSP zu senden. Erfahrungsgemäß wird dieser bei solchen Sachen innerhalb kurzer Zeit den Grund für das auftretende Address Spoofing mitteilen.

Sicherheit muß gelebt werden. Das fängt schon bei der Definition von Netzwerken an. Das sieht mir alles noch nicht ganz durchdacht aus. Um dennoch schnell das Problem ausfindig zu machen würde ich im Clusterobjekt ein Update der Topologie machen und die Gruppen nach vorheriger Überprüfung den Interfaces neu zuweisen.

Best regards,
Danny Trommer
CCSA/CCSE/CCSE+

[jacobsen]

Hi Danny,

thanks for the reply.
actually, the LAN if is configured with an /24 address. My intention is to clarify that the LAN side consist of different subnets out of 10/8.
The object name for "Networkobject_172.18.18.0-24" - was only a typo. forget about that.
Well, yes...if broadcast address is enabled in the network objects - does it really matter to answer the question?. Anyway, .254 isn't the broadcast address - it's just the last possible hostaddress.

"Perfome Antispoofing" normaly is activated. No matter if activated or not, the error remains.

Most of the above information is stripped to the basics. So it's not a question of topology design or security policies. It's just, why the packets are dropped. not more.



please try to reply in english. - it just gives everyone the chance to follow the discussion.

regards
Peter

(Im Übrigen ist hier ziemlich alles "durchdacht". Aufgrund der wenigen Information das Gegenteil zu behaupten, wirkt etwas anmaßend)

[dantro]

Hi fella,

eben. Viel zu wenig Informationen um Dir hier wirklich helfen zu können. Schick doch einfach Deinem CSP ein CPINFO, damit es sich dieser im INFOView anschauen kann. Dafür hat man ja Supportverträge. Mittels der wenigen Informationen kann man hier leider nicht so sehr viel sagen.

Best regards,
Danny Trommer
CCSA/CCSE/CCSE+