- CheckMates
- :
- Products
- :
- Quantum
- :
- Security Gateways
- :
- Meaning of Address Spoofing
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Meaning of Address Spoofing
Hello, everybody.
I have a curiosity about "Address Spoofing".
It is clear to me that when the log shows you a "DETECT" action, the traffic is "allowed", but is it important to "check" the reason for this traffic?
Having this type of logs, can give us "indications" of "Networking" problems in the network of a company?
I want to communicate to IP:172.23.12.5 with IP:172.23.3.21, but there is no traffic registered in the CP.
I have policies, I have routes, I have tried with "TCPDUMP" "CPPCAP" "FW MONITOR", but none of these tools show me traffic, when traffic is generated (a simple PING, or a Telnet to any port).
When I "search" in the logs for the origin with IP:172.23.12.5, I only get irrelevant traffic to "other IPs" that have nothing to do with my target.
Could this be a routing problem?
Cheers :).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It could be, but check out what I attached.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Absolutely that looks like a routing problem. It appears to be the reply traffic that is triggering anti-spoofing because the source port and destination port are inverted in the logs. So a device out on bond2.303 is sending traffic with a destination of 10.10.100.1 back to the firewall. I am guessing the firewall just routed that packet with a destination of 172.23.12.5:80 out that bond2.303 interface. Could be something else going on though. Potential ICMP redirects flying around but you would see that in pcap. Could be post NAT if that packet was previously NATted.
log filters of
xlatesrc:10.10.100.1 or s_port:58432 or xlatesport:58432
or some combination of that may help you find the initial request that the packet triggering anti-spoofing is replying to, that is assuming the request went through the firewall, may be some async routing going on where the firewall is only catching that reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I have a dilemma with "certain" types of traffic and Antispoofing messages.
Source: 172.23.12.5
Destination: 172.23.3.21, 172.23.3.20
Service (Test): ICMP
I have made attempts to capture traffic, with "tcpdump" "cppcap" "fw monitor" "fw ctl zdebug" and the active "Firewall" of my ClusterXL is not able to "capture" anything, when traffic is generated with a simple PING.
When I just filter in the logs, the source IP, I do get "data" but to my perception, it is "junk data", because it is nothing of what I am trying to capture.
The only thing I see "relevant" when I filter only the ORIGIN, is that all the logs I see, most of them, "emphasize" an Address spoofing issue and I am not sure, if it is an important point to take into account, for my analysis.
Greetings.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think filter might be slightly off bro...usually people would do src:x.x.x.x AND dst:x.x.x.x
example -> src:1.1.1.1 AND dst:2.2.2.2
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See example below. One of my lab fws is 172.16.10.249 and I was pinging google dns from it.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What does the anti-spoofing configuration for bond2.303 look like? I would guess that bond2.303 is missing that source address 172.23.12.5 from its topology. Or that address is configured behind a different interface's topology, so the firewall does not like seeing that source address 172.23.12.5 coming inbound on bond2.303.