Showing posts with label Attack. Show all posts
Showing posts with label Attack. Show all posts
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>
Using uRPF at the access layer against DDoS attacks
How do you protect your devices from unauthorized Vitrual
Terminal Connection?
Ø
Common way, simple inbound ACL applied to the
VTY line or control-plane, like:
!
# ip access-list 10 permit 10.11.11.0
0.0.0.255
!
#line vty 0 4
#access-class 10
TCP SYN Attack:
Ø
A TCP SYN flood attacks is accomplished by
transmitting an TCP SYN packets to a host to exhaust its incoming TCP
connection Queue.
Ø
The Size of this queue on TCP/IP stack
implementation is small and easily exhausted.
Ø
Unicast RPF provides a source validation step to
packet handling; it does this by verifying the source information of a packet
to inform contained within the cisco express forwarding (CEF) forwarding
information base (FIB).
Ø
The CEF FIB is a table that contains
packet-switching information that mirrors that of the routing table; this is
used by the device to increase the speed of pkts being forwarding through the
device.
Ø
CEF must be configured on the device before uRPF
is configured.
Ø
Unicast RPF operates in one of two modes:
·
Strict (normal): When in strict mode, Unicast verifies that
the source address in the FIB and that source address was received on the best
return route interface as determined by CEF.
-
Can also be troublesome if routing is
multihomed.
-
This is because the best return path might not
be the same as the receiving interface ; because of this, strict uRPF is
limited to single-homed connection.
-
uRPF will also work in situations where there
are multiple equal-metric best paths available.
·
Loose: Loose mode verifies only that the source
address exists within the FIB and not the interface.
-
Loose mode allows additional flexivility to
implement uRPF in locations where multihoming is common .
Ø Another
important things to understand about uRPF is that it only works on incoming
interface.
Ø If a
single-homed connection existed between the network and an ISP, RPF would be
configured to monitor traffic coming from the ISP only.
Unicast RPF Configuration:
Ø
The first thing that must be configured before
starting Unicast RPF conf is to enable the use of CEF.
Ø
The ip cef {distributed} command enables
the use of CEF
# ip cef { distributed }
Ø The
next part requires enabling uRPF on the incoming interface.
Ip verify unicast source reachable-via
[rx | any ] {access-list}
Ø Rx
is used for Strict mode and any is used for loose mode.
Ø An
access-list can specified, its purpose is to determine whether the traffic will
be dropped (default behavior-deny) or forwarded (permit).
Ø It
is important to understand that this access-list is not consider unless the pkt
fails the unicast RPF check.
Verification:::::::
# show cef interface
<interface>
To verify global uRPF pkt count,
# show ip traffic
To verify the number of interface
uRPF pkt drops :
# show ip interface
<interface>