RPF check

RPF check is another way to prevent spoofing. If you are familiar with Multicast routing then this shouldn't be too hard to understand. Basically the router looks up the source IP address of the packet in the route-table and (depending on the configuration) can drop it if the source interface doesn't match the interface in the route table.

For example, if R4 receives a packet on serial 1/0 but the source address isn't in it's table it drops the packet. Let's try it out.

Here's our topology:

[R1]----[R4] s1/0 ----[R5]

R1-R4: 10.0.0.0/24
R4-R5: 155.1.45.0/24

OSPF area 0 is on all interfaces

R5 has 2 loopbacks:
155.1.55.55/32
155.1.155.155/32

We are not going to advertise the loopbacks into OSPF so that the RPF check will fail on R4. We are also going to use an ACL so that only one loopback is actually checked via RPF.

On R4:

R4(config)#access-list 100 permit ip 150.1.55.0 0.0.0.255 any
R4(config)#access-list 100 deny ip any any log

R4(config-if)#int s1/0
R4(config-if)#ip verify unicast reverse-path 100

That's it for the config! Let's look at R4's routing table.

R4#show ip route | begin Gateway
Gateway of last resort is not set

155.1.0.0/24 is subnetted, 3 subnets
C 155.1.0.0 is directly connected, Serial1/1
C 155.1.4.0 is directly connected, Loopback0
C 155.1.45.0 is directly connected, Serial1/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, FastEthernet0/0

Notice that R4 has no route to either of R5's loopbacks, but it will only perform an RPF check on packets coming from 155.1.155.155. On R5 (both pings get no reply because R4 has no route back but only the first set get blocked by R4 as we'll see below):

R5#ping 10.0.0.1 source 155.1.155.155

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.155.155
.....
Success rate is 0 percent (0/5)
R5#ping 10.0.0.1 source 155.1.55.55

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
Packet sent with a source address of 155.1.55.55
.....
Success rate is 0 percent (0/5)
R5#

On R4:

R4#
*Mar 1 08:21:29.285: %SEC-6-IPACCESSLOGDP: list 100 denied icmp 155.1.155.155 -> 10.0.0.1 (0/0), 1 packet
R4#

For more go here:
Configuring Unicast Reverse Path Forwarding

TCP Intercept: Watch vs Intercept

TCP Intercept is used to prevent DoS attacks where the attacker tries to use up all the TCP resources by sending SYN packets and then never replying to the SYN-ACK (the source is spoofed which is why the attacker doesn't respond). Here we configure R4 to detect this attack and prevent it by dropping these "half-open" connections. I am not sure how to spoof an address from a Cisco router, so we'll just configure TCP intercept and do some monitoring.

[R5]---[R4]---[R1]

10.0.0.0 is the LAN address range between R1 and R4. We'll create an ACL that matches telnet traffic from R5 to R1. R1 in this case is the server we want to protect from the SYN Attack.

R4(config)#access-list 100 permit tcp any 10.0.0.0 0.0.0.255 eq 23

R4(config)#ip tcp intercept ?
connection-timeout Specify timeout for connection info
drop-mode Specify incomplete connection drop mode
finrst-timeout Specify timeout for FIN/RST
list Specify access-list to use
max-incomplete Specify maximum number of incomplete connections before clamping
mode Specify intercepting mode
one-minute Specify one-minute-sample watermarks for clamping
watch-timeout Specify timeout for incomplete connections in watch mode

R4(config)#ip tcp intercept list 100
R4(config)#ip tcp intercept max-incomplete high 200
R4(config)#ip tcp intercept max-incomplete low 150
R4(config)#ip tcp intercept connection-timeout 60
R4(config)#ip tcp intercept drop-mode random

Debugging and Verification:

R4#debug ip tcp intercept
TCP intercept debugging is on

*Mar 1 06:28:33.866: INTERCEPT: new connection (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:33.874: INTERCEPT(*): (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:33.954: INTERCEPT: 1st half of connection is established (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:33.958: INTERCEPT(*): (155.1.45.5:31039 SYN -> 10.0.0.1:23)
*Mar 1 06:28:34.034: INTERCEPT: 2nd half of connection established (155.1.45.5:31039 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:28:34.038: INTERCEPT(*): (155.1.45.5:31039 ACK -> 10.0.0.1:23)
*Mar 1 06:28:34.042: INTERCEPT(*): (155.1.45.5:31039 <- WINDOW 10.0.0.1:23)

I don't like the output above. I expected to see R4's address somewhere in the output since it is "intercepting" the connections. Perhaps I am misunderstanding this...both "halves" look the same to me.

Anyways, here's a show command:

R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
155.1.45.5:31039 10.0.0.1:23 ESTAB 00:00:49 00:59:14 I
R4#

Now let's see what it looks like in watch mode:

R4(config)#ip tcp intercept mode watch

R4#
*Mar 1 06:30:58.082: INTERCEPT: new connection (155.1.45.5:12568 SYN -> 10.0.0.1:23)
*Mar 1 06:30:58.182: INTERCEPT: (155.1.45.5:12568 <- ACK+SYN 10.0.0.1:23)
*Mar 1 06:30:58.310: INTERCEPT: (155.1.45.5:12568 ACK -> 10.0.0.1:23)
R4#show tcp intercept connections
Incomplete:
Client Server State Create Timeout Mode

Established:
Client Server State Create Timeout Mode
R4#

Notice that "show tcp intercept connections" only gives output when the router is in intercept mode.

CBAC Example

Context-Based access control is another way to dynamically modify access-lists on the fly to allow return traffic. Here we configure a simple example that allows FTP traffic as well as PING from inside to outside. First let's apply an ACL inbound on R4 serial 1/0 and see what happens we ping from R1 to R5:

R1 --INSIDE--> R4 s1/0 --OUTSIDE--> R5

On R4:

ip access-list extended INBOUND
permit ospf any any
deny ip any any log
interface Serial1/0
ip access-group INBOUND in

Now from R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

Now on R4 we add the following CBAC configuration:

ip inspect name CBAC ftp
ip inspect name CBAC tcp router-traffic
ip inspect name CBAC icmp router-traffic

interface Serial1/0
ip inspect CBAC out

Now back to R1:

R1#ping 155.1.5.5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 155.1.5.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/115/268 ms
R1#

Verify on R4 (Do this quick or the session will be gone)

R4#show ip inspect sessions
Established Sessions
Session 659A79DC (10.0.0.1:8)=>(155.1.5.5:0) icmp SIS_OPEN
R4#

I tried testing ftp but for some reason the "ftp-server enable" doesn't seem to exist in my IOS with is 12.4 ADVENT. Anyways, that should give you a quick idead of how CBAC is used to punch holes in ACLs for return traffic.

Also remember that we DENY traffic INBOUND on the OUTSIDE interface if we want to inspect it in the OUTBOUND direction.