Skip to main content

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:

dos-spoofing1.jpg 

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.

dos-spoofing2.jpg 

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).

dos-spoofing3.jpg

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:

dos-spoofing4.jpg 

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:

dos-spoofing5.jpg

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

dos-spoofing6.jpg

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:

dos-spoofing7.jpg

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
!
 
dos-spoofing8.jpg

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:

dos-spoofing9.jpg 

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:

dos-spoofing10.jpg 

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:

dos-spoofing11.jpg 

Now, let’s implement uRPF:

!
access-list 100 permit ip any any log
!
interface FastEthernet1/0
ip verify unicast source reachable-via rx 100
!
 
dos-spoofing12.jpg 

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
…
 
dos-spoofing13.jpg 

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.

dos-spoofing14.jpg


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
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more