Searching for Address Spoofing Logs in R80

[Muditha_Thelisi]

With SmartLog in R80 how can I search for 'Address Spoofing' logs? Which field should I select? With SmartView Tracker I could add a filter on Information column but with SmartLog I can't do the same.

[Timothy_Hall · Accepted solution]

Try entering "address spoofing" without the quotes into the search field on the Logs & Monitor tab.  It is not a typical Field:Filter search so it may run a bit more slowly but it should work.

--

My book "Max Power: Check Point Firewall Performance Optimization"

now available via http://maxpowerfirewalls.com​ and Amazon.

[Muditha_Thelisi]

Thanks for the response Tim. I did try that, but it didn't show any results at all. Below is the log entry that I am trying to search using the suggested method. I will try again and see whether I can get any results.

[Timothy_Hall]

Seems to work fine for me with a vanilla R80 SMS and a R77.30 gateway, typing "address spoofing" in the search field pulls up all log entries with a Message Information field of Address Spoofing.  Please see the screenshot below.

--

My book "Max Power: Check Point Firewall Performance Optimization"

now available via http://maxpowerfirewalls.com.

[#5]

Hi Tim,

You are right.

The "message information" ( message_info in the log ) is indexed only as free text search in SmartLog R80 similar to SmartLog R77.

SmartLog is designed to allow users to search faster by indexing common fields like src,dst,service,etc... and indexing other fields for free text searching only.

[Andreas_Mang]

Which build was that screenshot from? In R80.10, apparently the field 'interface' is no longer visible in Antispoofing logs.

[Timothy_Hall]

The original screenshot was from R80 Take 76. 

Here is a screenshot from R80.10, looks like the interface is still listed in the anti-spoofing log entry to me:

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andreas_Mang]

well..there is an 'interface' column in the smart log as well. But I don't see the Interface listed for all anti spoofing entries. For some I can see it, but others don't show it.

[Timothy_Hall]

Please provide (sanitized) screenshots of your anti-spoofing log entries (one of which shows the interface correctly and one that does not) and we can try to figure out what is going on. 

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andreas_Mang]

here is a sanitized Version, with a log entry opened that does not list the Interface. As you can see on the left hand side, the Interface is not always shown. I tried finding differences in the antispoofing topology, but could not see anthing different. We use the feature to calculate antispoofing based on Routing topology (static Routing only), and with DMZ Interfaces we just define Antispoofing based on Topology-internal-Network) defined by Interface IP and Net Mask, and not specific Groups. Setting is Perform Antispoofing based on Interface topology, set to prevent and Spoof Tracking to Log.

That is set the same across all dmz interfaces.

Those interfaces that do have any additional routing entries such as internal network, I understand that the Firewall creates groups every time a routing entry is added to the topology and counts up with a dash - at the end. So there will be an Interface eth2-03.319 and there are groups in SmartConsole named <fwname>_eth2-03.319-1,<fwname>_eth2-03.319-2,<fwname>_eth2-03.319-3,  etc.

What happens if anything at all, if any older or newer such groups are deleted? Since they show up in the unused objects pane.

[Timothy_Hall]

OK here we go:

1) Do you see any outbound antispoofing drops at all anywhere in your logs?  The arrow icon next to the interface name will be pointing up instead of down.  This isn't widely known but antispoofing is enforced outbound on interfaces as well, and I'm wondering if these log entries missing an interface are outbound antispoofing drops that are not being displayed correctly.  Might be interesting to locate these antispoofing log entries lacking an interface from expert mode on the SMS with the fw log -n command, and see if the interface name is properly appearing there at the CLI level which would conclusively point to a display issue in the SmartConsole.

2) It appears that the interfaces involved here are VLAN tagged, any chance these packets being flagged by antispoofing with no interface are arriving with a 802.1q tag value set for which there is no VLAN subinterface?  In other words improperly pruned traffic arriving from the switch tagged with a VLAN ID that the firewall's interface configuration is not expecting.  There would not actually be a matching interface to log in that case.  Could also potentially be rogue traffic arriving untagged/native unexpectedly, but I'd think it would get logged against the leading/physical interface in that case. 

3) You aren't mixing untagged/native traffic with VLAN-tagged traffic on the same physical interface AND using ClusterXL are you?  That configuration is not supported.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andreas_Mang]

Hi Tim,

okay, 1) I was not aware of outbound anti-spoofing. But in combination with anti-spoofing based on routing entries, isn't that a little bit like a chicken and egg problem? If I have a routing entry pointing to a specific gateway reachable via an outbound Interface, it automatically removes anti-spoofing blocks, so I could not possibly have outbound antispoofing. If I use manual anti-spoofing and groups and I have a discrepancy between routing table and anti-spoofing Group then yes, it could happen. So in my Case, the arrow only points down for inbound antispoofing.

But your suggestion to use fw log - was good, I tried that and isolated a particular case of an IP being dropped due to antispoofing and the logs are inconsistent. Sometimes it has the interface listed, sometimes it does not.

(Apologies .partially sanitized entries)

  5:30:11 5 N/A  1  drop 192.168.95.57 < N/A  LogId: <max_null>; ContextNum: <max_null>; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; HighLevelLogKey: 18446744073709551615; src: 172.26.17.203; dst: x.x.x.x; proto: tcp; message_info: Address spoofing; ProductName: VPN-1 & FireWall-1; svc: tls1.0; sport_svc: 57888; ProductFamily: Network;
  5:30:14 5 N/A  1  drop 192.168.95.57 < N/A  LogId: <max_null>; ContextNum: <max_null>; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; HighLevelLogKey: 18446744073709551615; src: 172.26.17.203; dst: x.x.x.x; proto: tcp; message_info: Address spoofing; ProductName: VPN-1 & FireWall-1; svc: tls1.0; sport_svc: 57888; ProductFamily: Network;
  5:30:19 5 N/A  59  drop 192.168.95.57 > eth2-03  LogId: <max_null>; ContextNum: <max_null>; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; HighLevelLogKey: 18446744073709551615; src: 172.26.17.203; dst: x.x.x.x; proto: tcp; message_info: Address spoofing; ProductName: VPN-1 & FireWall-1; svc: tls1.0; sport_svc: 57889; ProductFamily: Network;
  5:30:22 5 N/A  36  drop 192.168.95.57 > eth2-03  LogId: <max_null>; ContextNum: <max_null>; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; OriginSicName: CN=cp-rz2_fw1,O=rugell3.fp7ndk; HighLevelLogKey: 18446744073709551615; drop reason: Address spoofing; packet amount: 5; packets:  <172.26.29.250,52392,x.x.x.x,443,6;eth2-03> <172.26.17.203,57889,x.x.x.x,443,6;eth2-03> <172.26.18.197,54354,x.x.x.x,443,6;eth2-03> <172.26.6.38,51828,x.x.x.x,443,6;eth2-03> <172.26.4.166,58941,x.x.x.x,443,6;eth2-03>; ProductName: VPN-1 & FireWall-1; ProductFamily: Network;

2. no we are only using tagged Interface. No PVID/Native Vlan being used anywhere. And per example 1) it must be coming from eth2-03 in the log entries because they are within a few seconds of each other. And yes, I agree, then it should list them with the physical Interface, instead of the subinterface/None.

3. no  we are not using that

[Timothy_Hall]

So that rules out a display issue in the SmartConsole, as obviously it is not going to display an interface name if there isn't one present in the underlying log.  Next steps:

1) Might be a coincidence, but are all the problematic spoofing entries happening for web traffic only?  Do you have HTTPS Inspection enabled and is this traffic subject to it?  Wondering if somehow the antispoofing is getting triggered where the interface name is not available like in the wstlsd process.

2) Might be interesting to try to catch one of these anti-spoofing hits while fw ctl zdebug drop is running as that will give more information about exactly what kernel module and where (SecureXL or Firewall Worker) it is occurring yet not logging the interface name.

3) Perhaps spoofing drops handled specifically by SecureXL are not logging the interface for some reason.  If SecureXL is enabled on your system (fwaccel stat), try this which will force all antispoofing enforcement out of SecureXL and onto a Firewall Worker and see if the interface logging improves:  sim feature anti_spoofing off ; fwaccel off ; fwaccel on.  I suppose you could try disabling SecureXL completely as well, but that may have grave performance ramifications depending on your environment.

Beyond these steps it is starting to smell like a possible bug, and it is probably time to involve Check Point TAC.  What version and jumbo is the gateway using?

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Andreas_Mang]

1) we aren't using https interception

2-3) SecureXL is bascially completely broken on this virtual System since the R80.10 upgrade of that VSX Cluster. With drop templates enabled we had a hit rate of 99% in R77.30 and are now at Zero. Ticket is still in Progress.

It is still working for the other virtual System, so I suspect something in the policy that it cannot handle..but this actually gave me an idea.

fwaccel on the other virtual System is at 94%. Interesting, I can't find any antispoofing logs without an Interface on that System. Most of that is accelerated. But it is currently also hosted on a freshly installed VSX Gateway as opposed to an upgraded one.

We are running R80.10 Jumbo HF Take 42, with a small hotfix on top. Installing fw1_wrapper_HOTFIX_R80_10_JHF_T40_248_GA_FULL.tgz shortly to fix the DNS Resolution bug in sk120558

Let me do some Tests moving it around and I will respond soon.

so it turns out..the other VSX Gateway does not seem to have this Problem. It was intalled basically from scratch by accident (installer install R80.10 etc..) while the clustermate showing this Problem was properly upgraded (installer upgrade R80.10xyz). I guess time to open up another case

[Timothy_Hall]

OK thanks for the update, good luck.

--
My book "Max Power: Check Point Firewall Performance Optimization"
now available via http://maxpowerfirewalls.com.

[Paul_Wetton]

If it is of any help I too am having issue - I've noticed that the Address Spoofing is reported as Address spoofing in the logs. if I search address spoofing I get zero - if I search Address spoofing I get the first 50...