Preface: The image in the blog is a capture from the Cisco Firewall Syslog Message guide explaining an Event regarding a Reverse Protocol Attack. Cisco tells you that the packet is dropped and that the firewall defended you from a Spoofing attack. Such events are dicey in nature because you don’t know what to do, how to react and how to respond to these events in Security Operations.As with every Investigation, everything begins with a “Tip”The Tip:
- The Event itself – In this case Cisco PIX/ASA Firewall message
- The IP source from which the packet originated
- The timestamp at which the event occurred
- The Firewall from which the alert originated
Investigation Methodology:
We need to identify “who” is the person performing this attack. Since this is a firewall, all we can get is a IP address from where this originated. But from an investigation perspective, we need to identify the “real machine”doing this. If it is an internal segment or VLAN in the enterprise network we can do a few things like below:
- Tracing the MAC address from which the IP originated. For this we would typically need Switch Logs and/or DHCP logs.
- Identify the IP and MAC pairings logs during the said time period. Watch out for MAC address Spoofing scenarios as well.
- Based on these two data sources we will be able to identify the physical machines which are possible candidates for this attack
- In MAC Spoofing scenarios, looking at the physical machine will help. There is a Microsoft API that helps you gather this real MAC information. I have seen some tools that provide this information as well.
In case of Internet facing Firewall, this spoofing detection is going to be a tough ask. We may not have a capability to identify the source performing the spoof. So if the Internet Firewall throws this alert, its safe to ignore as Cisco recommends, whereas if the Internal Firewall throws this alert, it needs to be investigated to identify insider attack scenarios involving spoofing.
Detection:
Detection of this event is the simplest in SIEM terms. The event ID is unique for Cisco devices and hence they can be triggered directly. These alerts can be filtered for internal firewalls only unless and until the Internet firewall is overwhelmed with these alerts. In case of enormous amount of alerts from Internet firewall, we may have to look at potential DoS scenarios. Several threshold based rules can be created in SIEM to look for such attack patterns
Prevention:
In case of Internet facing Firewall, uRPF filtering definitely helps. There are several different modes for enabling uRPF. Before enabling we need to understand whether our network is routed symmetrically or not. In case of symmetric routing, the uRPF filtering is straight forward and we can go for Strict Mode, but in case of asymmetric routing, the filtering is not easy and hence we may configure uRPF in Loose Mode or Feasible Mode. There are several articles from Cisco on uRPF that can serve as good references.
Conclusion:
In essence, every event means different things in different scenarios. Placement of the device in the network and its relevance gives a new meaning to the event triggered. Investigation of every “event type” is mandatory in Security Operations. Results of such analysis should be fed back into a Knowledge Base that will help the enterprise react to several different alerts in the right way.
Update based on the comments received:
For scenarios where both IP and MAC spoofing is involved, there is no easy way of identifying the real machine. The closest in case of Internal Network would be to look at the Switch Network to identify the source segment of the MAC thereby narrowing done on the investigation. But even after narrowing down, you will have to go down to the Asset Enumeration level to exactly identify the spoofing host. This enumeration should be done in tandem with packet captures in the switched network. One of the other things to look at in packet captures would be to look for the presence of a Locally administered address bit. This will be set in case of a spoof. Smart hackers know this and can circumvent it by a custom driver code, but this is just another pointer of what we can look for.
Hi Vinod,
This is good article.I really want to appreciate your effort on this series.
Just curious to know about MAC address Spoofing scenario , how can we identify Physical Machine ?
Rattling nice pattern and excellent articles, practically nothing else we require :D.
Thanks you. Do follow my blog for regular posts and updates!!!