Defeating Denial of Service Attacks which employ IP Source Address Spoofing
I would like to talk about defeating DDOS and scenarios how we can actually use it. Let’s get started ! I’m going to talk about two methods:
1) before you forward any packet, check if you know the return path. If you know, forward the packet, if you don’t – drop it. There are two ways of implementation: strict and loose. First one accepts packets only when the return path is through the interface which is the ingress one. The second one accept any packet if the router has the return path via any interface. As you can see you can’t use this solution for transit or multihomed networks. It should be rather singlehomed, stub network. During DDOS attackers spoof a source IP and the solution will work (packets will be dropped) only for those with invalid source IP addresses. If the source IP is a valid, the packet will be forwarded.
2) edge router checks if the source IP is the one, which is allocated for particular ISP client – this is the best, easiest for single homed companies to prevent their networks against being the source of attack.
Let’s do some tests:
There is one attacker who will perform following attacks:
a) Using a real source IP and a specific destination IP
-> SIP: 192.168.202.143 -> DIP: 20.0.0.2
b) Using a spoofed source IP (unknown) and a specific destination IP
-> SIP: 12.12.12.12 -> DIP: 20.0.0.2
c) Using a spoofed source IP (known and legitimate) and a specific destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.2
d) Using a spoofed source IP (known and legitimate) and a subnet as a destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.0/24
Below you find configuration of these devices:
R2:
!
hostname R2
!
interface FastEthernet0/0
ip address 20.0.0.2 255.255.255.0
duplex full
!
!
router ospf 1
network 20.0.0.0 0.0.0.255 area 0
!
ASA:
!
hostname asa
!
interface GigabitEthernet0
nameif outside
security-level 0
ip address 10.0.0.100 255.255.255.0
!
interface GigabitEthernet1
nameif inside
security-level 100
ip address 20.0.0.200 255.255.255.0
!
access-list OUT extended permit tcp host 192.168.202.143 host 20.0.0.2 log
access-list OUT extended permit tcp host 11.11.11.11 any log
access-list OUT extended deny ip any any log
!
access-group OUT in interface outside
!
router ospf 1
network 10.0.0.0 255.255.255.0 area 0
network 20.0.0.0 255.255.255.0 area 0
log-adj-changes
!
R1:
hostname R1
!
interface Loopback0
ip address 11.11.11.11 255.255.255.0
!
interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex full
!
interface FastEthernet1/0
ip address dhcp
speed auto
duplex auto
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 11.11.11.0 0.0.0.255 area 0
network 192.168.202.0 0.0.0.255 area 0
!
Scenario “A” (legitimate traffic):
a) Using a real source IP and a specific destination IP -> SIP: 192.168.202.143 -> DIP: 20.0.0.2
For IP spoofing I’m going to use scapy (http://www.secdev.org/projects/scapy) installed on my host.
The packet is permitted on the ASA:
%ASA-6-302013: Built inbound TCP connection 1095 for outside:192.168.202.143/20 (192.168.202.143/20) to inside:20.0.0.2/23 (20.0.0.2/23)
%ASA-6-302014: Teardown TCP connection 1095 for outside:192.168.202.143/20 to inside:20.0.0.2/23 duration 0:00:00 bytes 0 TCP Reset-O
%ASA-7-609002: Teardown local-host outside:192.168.202.143 duration 0:00:00
asa(config)#
As you see I sent SYN packet, then R2 replied with SYN+ACK and then attacker machine sent RST (as there wasn’t any legitimate half-open session).
b) Using a spoofed source IP (unknown) and a specific destination IP -> SIP: 12.12.12.12 -> DIP: 20.0.0.2
In the second case I’m going to spoof the source IP to forged one and during the first test I’m going to perform it without unicast RPF:
The packet is actually dropped by ASA:
%ASA-6-106100: access-list OUT denied tcp outside/12.12.12.12(20) -> inside/20.0.0.2(23) hit-cnt 1 first hit [0x944a9bdb, 0x0]
Let’s implement uRPF on Fa0/0 on R1:
R1(config-if)#ip verify unicast source reachable-via rx
And I try once again:
As you see the packet has been dropped by R1 and never reached the ASA:
R1#sh ip traffic | b Drop
Drop: 0 encapsulation failed, 0 unresolved, 0 no adjacency
0 no route, 1 unicast RPF, 0 forced drop, 0 unsupported-addr
0 options denied, 0 source IP address zero
To see what packets have been dropped by the uRPF you can add ACL:
!
access-list 100 permit ip any any log
!
interface FastEthernet1/0
ip verify unicast source reachable-via rx 100
!
R1#
*Jun 11 16:26:09.543: %SEC-6-IPACCESSLOGP: list 100 permitted tcp 12.12.12.12(0) -> 20.0.0.2(0), 1 packet
R1#
c) Using a spoofed source IP (known and legitimate) and a specific destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.2
We can see the connection on the ASA:
%ASA-6-106100: access-list OUT permitted tcp outside/11.11.11.11(20) -> inside/20.0.0.2(23) hit-cnt 1 first hit [0x118e5140, 0x0]
%ASA-7-609001: Built local-host outside:11.11.11.11
%ASA-6-302013: Built inbound TCP connection 1096 for outside:11.11.11.11/20 (11.11.11.11/20) to inside:20.0.0.2/23 (20.0.0.2/23)
%ASA-6-302014: Teardown TCP connection 1096 for outside:11.11.11.11/20 to inside:20.0.0.2/23 duration 0:00:00 bytes 0 TCP Reset-O
%ASA-7-609002: Teardown local-host outside:11.11.11.11 duration 0:00:00
asa(config)#
On the R1 we can see following packets:
Now I add uRPF on R1:
!
access-list 100 permit ip any any log
!
interface FastEthernet1/0
ip verify unicast source reachable-via rx 100
!
But this time the packet wasn’t dropped by uRPF because R1 has a valid return path and the packet has been passed to ASA:
Jun 11 2015 22:12:42: %ASA-6-302013: Built inbound TCP connection 1098 for outside:11.11.11.11/20 (11.11.11.11/20) to inside:20.0.0.2/23 (20.0.0.2/23)
Jun 11 2015 22:12:42: %ASA-6-302014: Teardown TCP connection 1098 for outside:11.11.11.11/20 to inside:20.0.0.2/23 duration 0:00:00 bytes 0 TCP Reset-O
Jun 11 2015 22:12:42: %ASA-7-609002: Teardown local-host outside:11.11.11.11 duration 0:00:00
asa(config)#
and then to R2:
d) Using a spoofed source IP (known and legitimate) and a subnet as a destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.0/24
In the last scenario I’m going to scan 20.0.0.0/24 subnet from spoofed (legitimate) source IP:
All packets (256) are permitted by R1 (no uRPF) and we can see them on ASA:
sh conn
245 in use, 258 most used
TCP outside 11.11.11.11:20 inside 20.0.0.90:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.8:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.237:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.234:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.40:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.89:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.194:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.61:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.59:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.45:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.181:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.163:23, idle 0:00:02, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.195:23, idle 0:00:02, bytes 0, flags SaAB
….
And then three of them on R2:
Now, let’s implement uRPF:
!
access-list 100 permit ip any any log
!
interface FastEthernet1/0
ip verify unicast source reachable-via rx 100
!
All packets are permitted by R1 because the return path is known and there is no reason to drop them by uRPF. On ASA we can see bunch of connections:
asa# Jun 11 2015 22:31:05: %ASA-3-710003: TCP access denied by ACL from 11.11.11.11/20 to outside:20.0.0.200/23
sh conn
258 in use, 258 most used
TCP outside 11.11.11.11:20 inside 20.0.0.90:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.8:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.237:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.234:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.40:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.89:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.194:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.61:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.59:23, idle 0:00:09, bytes 0, flags SaAB
TCP outside 11.11.11.11:20 inside 20.0.0.45:23, idle 0:00:09, bytes 0, flags SaAB
…
Ok, to summarize all findings let’s analyze what we have just seen: uRPF works only when the return path is unknown. For host with a default gateway the feature doesn’t work at all. As you see there is limited usage of it as you need to fill specific restriction like: no default gateway, stub network and single homed.
Let’s do one more test but now I change the perspective and I’m going to employ ISP to protect its edge routers against similar attackers who spoof their source IPs.
ISP-EDGE:
!
ip access-list extended ISP-EDGE
permit ip 192.168.202.0 0.0.0.255 any log
deny ip any any log
!
interface FastEthernet1/0
ip address dhcp
ip access-group ISP-EDGE in
speed auto
duplex auto
!
As you see now all attempts to spoof own source IP are unsuccessfully:
b) Using a spoofed source IP (unknown) and a specific destination IP -> SIP: 12.12.12.12 -> DIP: 20.0.0.2
ISP-EGDE#
*Jun 12 14:49:49.423: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 12.12.12.12(0) -> 20.0.0.2(0), 1 packet
ISP-EGDE#
c) Using a spoofed source IP (known and legitimate) and a specific destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.2
ISP-EGDE#
*Jun 12 14:50:34.843: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 11.11.11.11(0) -> 20.0.0.2(0), 1 packet
ISP-EGDE#
d) Using a spoofed source IP (known and legitimate) and a subnet as a destination IP -> SIP: 11.11.11.11 -> DIP: 20.0.0.0/24
ISP-EGDE#
*Jun 12 14:51:21.603: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 11.11.11.11(0) -> 20.0.0.0(0), 1 packet
ISP-EGDE#
*Jun 12 14:51:23.639: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 11.11.11.11(0) -> 20.0.0.1(0), 1 packet
ISP-EGDE#
*Jun 12 14:51:27.659: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 11.11.11.11(0) -> 20.0.0.3(0), 1 packet
ISP-EGDE#
*Jun 12 14:51:29.671: %SEC-6-IPACCESSLOGP: list ISP-EDGE denied tcp 11.11.11.11(0) -> 20.0.0.4(0), 1 packet
ISP-EGDE#
…
As you see the very simple ACL can prevent all attempts of spoofing source IP. I believe in most cases like for home users and sometimes for SMB it could implemented.
References:
https://tools.ietf.org/html/bcp38
https://www.ietf.org/rfc/rfc3704.txt
http://www.cisco.com/c/en/us/td/docs/ios/12_2/security/configuration/guide/fsecur_c/scfrpf.html
http://www.bcp38.info/index.php/Main_Page