ARP ATTACKS, ARP DOS AND INSPECTION
ARP ATTACKS AND INSPECTION
Ø
Inside host of Firewall will exchanges ARP
packets with unprotected hosts on the outside.
Ø
A malicious host, however, can abuse ARP to
leverage a man-in-the-middle attack.
Ø
Example : Host 192.168.100.222 on the inside of
the ASA is configured to use 192.168.100.1 as its default gateway.
Ø
When the inside host needs to communicate with a
destination that is outside of subnet 192.168.100.0/24
Ø
It must send those packets to the gateway, which
will relay the packets on toward their destination.
Ø
The inside host does this by sending the packets
to the gateway router’s MAC address.
Ø
Now suppose that a malicious host exists on the
unprotected outside part, and would like to insert itself in the middle of the
inside host’s conversation so it intercept and examine the traffic.
Ø
When the ARP request packet is forwarded outside
then attacker catch it and reply his own MAC address with IP address.
Ø
Now by this host came under Man-In-The-Middle
attack.
ARP-Inspection
Ø
To detect and prevent ARP spoofing, you can
configure the ASA to support ARP inspection.
Ø
ARP inspection uses static ARP entries as the
basis for its inspection process.
Ø
The ASA will examines each ARP reply packet it
overhears and compare the source IP and MAC address, as well as the source
interface, to known static entries in its own ARP table.
Ø
If the ARP reply matches an existing entry, the
ASA forwards it out the other interface else drop it.
Define
the ARP configuration
Ø For
ARP inspection, we define static ARP entries for all of the known hosts:
Ciscoasa(config)# arp <interface> <ip-address> <mac-address>
Ø Static
ARP entries never age out. To clear a static ARP entry, repeat the command by
beginning with the “no” keyword.
Ø Enable
ARP-inspection by command:
Ciscoasa(config)# arp-inspection <interface> enable [ flood | no-flood ]
Ø As
ARP reply packets are received, the ASA will take one of the following actions:
·
If the MAC address and the IP address are both
found in a single ARP table entry, the ARP reply must be valid and therefore is
allowed to pass through the ASA.
·
If either the MAC address or the IP address is
found in ARP table, bit not both in a
single entry, the ARP reply contains invalid or spoofed information. Therefore,
it is dropped and not forwarded through the ASA.
·
If neither MAC address nor IP address is found
in the ARP table, we can select the action as either flood (forward ot
flood the ARP packet out the other firewall interface so it can reach its
destination) or no-flood (drop the ARP packet without forwarding) . By
default flood action is assumed.
Disabling
MAC-Address Learning:
Ø
In transparent Firewall mode, an ASA will learn
MAC addresses as they are received on either of its interfaces.
Ø
Suppose a malicious host is located on the
outside of the ASA, as below figure.
Ø
Before the malicious host begins it work, the
inside host has sent a packet and the ASA has learned that its source MAC
address (0000.2222.2222) is located on the inside interface.
Ø
Now malicious host begin sending its own
packets, but with spoofed MAC addresses in the source MAC address field.
Ø
By sending a packet with source address
0000.2222.2222, the host can force the ASA to learn what is actually the inside
host’s address on the outside interface.
Ø
At this point, any packets arriving from the
outside and destined for the inside host will simply be drooped because the
host’s MAC address has been learned on the outside.
Ø
So far so good, but the malicious host might not
stop with just one spoofed MAC address. It might also send so many packets with
spoofed addresses that ASA’s MAC table is overrun.
Ø
That meant it’s a DOS attack on the ASA,
rendering it unable to forward any packets correctly.
Ø
To prevent by it , disable MAC address learning
dynamically. And firewall must use statically configured MAC address entries.
Ø
The command to disable learning:
Ciscoasa(config)# mac-learn <interface>
disable
Ø
Now configure a static MAC address entry by also
specify the interface and MAC:
Ciscoasa(config)# mac-address-table
static <interface mac-address>
DHCP in ASA Firewall
::DHCP in ASA Firewall::
Ø
When a network architecture includes an ASA,
either the clients have no local DHCP server or the clients can become
separated or isolated from a working DHCP server.
Ø
So we can configure an ASA to assist the
clients.
Configure
a DHCP Relay::
Ø
When a client needs an IP address then sends a
DHCP request.
Ø
DHCP request are normally sent as broadcasts.
Therefore, a DHCP server must be located within the same broadcast domain as a
client.
Ø
When a group of clients might be connected to
one ASA interface, and the DHCP server might be connected to a different
interface. Both interface have different security level.
Ø
So by default, an ASA will not forward DHCP
requests from one of its interface to another.
Ø
So we configure an ASA to use as DHCP relay
agent to relay DHCP requests (broadcast) received on one interface to a DHCP
server found on another interface.
Ø
The ASA does this by converting the requests
to “UDP port 67 unicast” packets.
Ø
And also intercept the DHCP replies that are
returned by the DHCP server.
Ø
So the default router address can be changed to
become the IP address of the ASA itself.
Ø
To enable DHCP relay agent command:
Ciscoasa(config)# dhcprelay server
<ip-address> <nameif>
Ø
If we have more than one DHCP server, you can
repeat this command to define up to 4 different servers.
Ø
In this case DHCP requests are relayed to
each of the servers simultaneously.
Ø
Next, use the command to enable the DHCP relay
agent on the ASA interface that faces the clients:
Ciscoasa(config)# dhcprelay enable <interface>
Ø The
DHCP replies or offer that are returned by a server contain a default router
address that clients can use as their default gateway.
Ø By
default, an ASA will pass the default router information back to the client
unchanged.
Ø This
might work fine if the default router address is the same as the ASA interface
closest to the client.
Ø Or
not, then we can use the below wrote command to override the default router
address and replace it with the IP address of the ASA interface that faces the
clients :
Ciscoasa(config)#
dhcprelay setroute <interface>
ASA as a
DHCP server::
Ø
An ASA can manage only dynamic address
assignment from a pool of contiguous IP addresses.
Ø
No provisions are available for config static
address assignments.
Ø
Enable the DHCP server on an ASA interface that
faces the clients:
Ciscoasa(config)# dhcpd enable <nameif>
Ø
Create an address pool for clients on an
interface:
Ciscoasa(config)# dhcpd address ip1
[ -ip2 ] <nameif>
Ø
Configure DHCP options for clients:
You can use the dhcp option command
to define any specific DHCP options that clients need to receive. We can also
configure an option code number with an ASCII string, an IP address, or a hex
string:
Ciscoasa(config)# dhcpd option <code>
{ ascii string | ip ip_address | hex hex_string }
Example: we want to hand out DHCP option 66
(TFTP server) or DHCP option 150 (multiple TFTP servers ) to cisco IP Phone
clients.
By default, an ASA hands out its own
interface address as the client’s default gateway, but we can override that
value by configure an IP address with DHCP option 3 (default router).
Ø
Configure any global DHCP parameters:
Some parameters are global in nature and
can be handed out in all DHCP replies. We can define the DNS and WINS server
and default domain name with commands:
Ciscoasa(config)# dhcpd dns dns1 [ dns2]
Ciscoasa(config)# dhscpd wins wins1 [ wins2 ]
Ciscoasa(config)# dhspd domain
domain-name
Ø
By default, each DHCP lease is sent with a lease
time of 3600 seconds, but we can override:
Ciscoasa(config)# dhcpd lease <lease_length>
Ø
When an ASA receives a DHCP request from a
potential client, it looks up the next available IP address in the pool.
Ø
Before a DHCP reply is returned, the ASA sends
an ICMP echo as a test to make sure that the IP address is not already in use
by some other host.
Ø
By default, the ASA waits 750 ms for an ICMP
reply; if no reply is received, it assumes that the IP address is indeed
available and assign it to the client .
Ø
If an reply is received then firewall knows that
the address is already in use, so next address from the pool is tried.
Ø
We can override the ping test timer by issuing
the following command with a timeout (100 to 10000 ) in milliseconds.
Ciscoasa(config)# dhcpd ping_timeout <timeout>