Category Archives: Networking

GNS3 Labs: BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

Posted on by Pier Carlo Chiodi
8 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

As I already wrote in my previous posts, an ISP can provide their customers some useful tools to mitigate (D)DoS attacks: Remote Triggered Black Holing and its NOC-independent version, Customer triggered black holing are tools that, once identified attacked hosts or networks, let us to stop malicious traffic at the provider’s edge.

Anyway, when we drop traffic toward attacked hosts, we can’t investigate the attack anymore; we would need a tool which allowed us to analyze traffic and, in the meantime, that would avoid wasting network resources. Our (dear) provider could provide it by implementing rate limiting and less-than-best-effort services using QoS Policy Propagation via BGP (QPPB).

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , , , , , , ,

GNS3 Labs: BGP Customer triggered black holing

Posted on by Pier Carlo Chiodi
12 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

Remote Triggered Black Holing In this post I’ll show you how to let your customers to trigger black holing for their prefixes. What I will write is based on my previous post GNS3 Lab: Remote Triggered Black Holing: same scenario, same startup config (the final one of that post).

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , ,

Cisco “clear ip nat translation” helper tool

Posted on by Pier Carlo Chiodi
8 Comments

Have you ever had to clear some specific NAT translations while avoiding to drop them all? You have to enter a long and annoying command such this a lot of times:

clear ip nat translation udp inside 1.2.3.4 7021 192.168.0.112 7021 outside 5.6.7.8 5060 5.6.7.8 5060

And you know, you have to do it many times, for every NAT entry you have to clear… and those entries are all there, within a single command output:

#show ip nat translations | inc 192.168.0.112
udp 1.2.3.4:7021     192.168.0.112:7021    5.6.7.8:5060    5.6.7.8:5060
udp 1.2.3.4:7022     192.168.0.112:7022    5.6.7.8:5060    5.6.7.8:5060

Well, I was bored once too often, so I’ve built a little tool: you have just to copy show ip nat translations entries you have to clear, paste them into this tool, and it builds the clear ip nat translation statements for you! ready to be pasted into your telnet/ssh client.

It’s an HTML page with a simple javascript; you can find it online, or here is the source code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
	"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Cisco "clear ip nat translation" helper</title>
<style type="text/css">
	body,td,th { color:black;font-family:Verdana; font-size: 8pt }
	input, textarea { color:black;font-family:Verdana; font-size: 8pt }
</style>

<script type="text/javascript">
	function Do()
	{
		var sEntries = new String();
		sEntries = document.forms['frmMain'].entries.value;

		var sVRF = new String();
		sVRF = document.forms['frmMain'].vrf.value;

		var sReplace;
		if ( sVRF == '' )
			sReplace = "clear ip nat translation $1 inside $2 $3 $4 $5 outside $6 $7 $8 $9"
		else
			sReplace = "clear ip nat translation vrf " + sVRF + " $1 inside $2 $3 $4 $5 outside $6 $7 $8 $9";

		sEntries = sEntries.replace(/^(tcp|udp)s+(d{1,3}.d{1,3}.d{1,3}.d{1,3}):(d+)s+(d{1,3}.d{1,3}.d{1,3}.d{1,3}):(d+)s+(d{1,3}.d{1,3}.d{1,3}.d{1,3}):(d+)s+(d{1,3}.d{1,3}.d{1,3}.d{1,3}):(d+)/gm, sReplace)

		document.forms['frmMain'].result.value = sEntries;
	}
</script>

</head>

<body>

<form id=frmMain name=frmMain style="MARGIN:0px" action="#">
<table>
 <tr>
  <td colspan=2><b>Entries to clear</b></td>
 </tr>
 <tr>
  <td colspan=2>

Paste here the <b>show ip nat translations</b> entries you want to clear:

  </td>
 </tr>
 <tr>
  <td colspan=2><textarea wrap=off style="white-space:pre; overflow-x: scroll; overflow-y: scroll" name=entries id=entries cols=100 rows=10></textarea></td>
 </tr>

 <tr>
  <td colspan=2><br></td>
 </tr>

 <tr>
  <td colspan=2><b>VRF aware?</b></td>
 </tr>
 <tr>
  <td colspan=2>

If these entries are part of a vrf, write here the vrf name, otherwise leave this box empty:

  </td>
 </tr>
 <tr>
  <td><b>VRF name:</b></td>
  <td><input type=text name=vrf id=vrf size=15 value=""></td>
 </tr>

 <tr>
  <td colspan=2><br></td>
 </tr>

 <tr>
  <td colspan=2><b>Results</b></td>
 </tr>
 <tr>
  <td colspan=2><textarea wrap=off style="white-space:pre; overflow-x: scroll; overflow-y: scroll; WIDTH:99%" readonly name=result id=result cols=100 rows=10></textarea></td>
 </tr>

 <tr>
  <td colspan=2><br></td>
 </tr>

 <tr>
  <td colspan=2 align=center><input type=button onclick="Do()" value="  Build clear ip nat translation statements  "></td>
 </tr>

</table>
</form>

<br>

by Pier Carlo Chiodi - AKA Pierky<br>
<br>
Blog: <a href="http://blog.pierky.com" target="_blank">http://blog.pierky.com</a><br>
Contact me: <a href="http://piercarlochiodi.tel" target="_blank">http://piercarlochiodi.tel</a><br>

</body>
</html>
Categories: Networking | Tags: , ,

GNS3 Lab: Remote Triggered Black Holing

Posted on by Pier Carlo Chiodi
6 Comments

This post is part of a series about “ISP Security Tools and Techniques“; in this series I talk about some (I think) useful practices:

1. Remote Triggered Black Holing

2. BGP Customer triggered black holing

3. BGP triggered rate limiting and less-than-best-effort (LBE) with QPPB

4. Source-based RTBH with Unicast Reverse Path Forwarding (uRPF)

Stay tuned! 😉

Remote Triggered Black HolingIn this post I would like to talk about Remote Triggered Black Holing, a mechanism to protect a network by filtering malicious traffic at the edge. It’s a powerful tool ISPs can (and should) adopt to stop DDOS attacks on their networks.

UPDATE 2009-06-21: You can find a related solution to use customer triggered blackholing in this new post!

Read more …

Categories: Networking, Networking Labs, Security | Tags: , , , , , , , ,

GNS3 Lab: BGP – network backdoor, a way to prefer IGP over eBGP

Posted on by Pier Carlo Chiodi
2 Comments

BGP network backdoorThe network … backdoor command let you to prefer IGP over eBGP routing updates without changing the overall BGP administrative distance.

Initially, R1 and R2 run an IGP (EIGRP) on the direct link (172.16.0.0/30).

R1#show ip route | beg Gateway
Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.13.0 is directly connected, FastEthernet1/0
C       172.16.0.0 is directly connected, FastEthernet2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/30720] via 172.16.0.2, 00:00:20, FastEthernet2/0

Look at D 192.168.2.0/24 [90/30720] via 172.16.0.2, 00:00:20, FastEthernet2/0.

Then, they start an eBGP peering session with R3…

R3#sh ip bgp
BGP table version is 10, local router ID is 192.168.3.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0      172.16.13.1              0             0 65100 i
*> 192.168.2.0      172.16.23.1              0             0 65200 i
*> 192.168.3.0      0.0.0.0                  0         32768 i

At this time, both R1 and R2 have an eBGP session with R3 and advertise their local networks: 192.168.1.0/24 and 192.168.2.0/24.
Now, looking at R1 (or R2) routing table, we can see they reach each other via R3:

R1#show ip route | beg Gateway
Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.13.0 is directly connected, FastEthernet1/0
C       172.16.0.0 is directly connected, FastEthernet2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
B    192.168.2.0/24 [20/0] via 172.16.13.2, 00:02:16
B    192.168.3.0/24 [20/0] via 172.16.13.2, 00:02:16

Look at B 192.168.2.0/24 [20/0] via 172.16.13.2, 00:02:16

Why? What appened? This is not an optimal routing plan!

With BGP peering on, R3 receives R1 (and R2) networks, then it advertise them back to the other peer: the eBGP administrative distance is lower than IGP (EIGRP and others), so R2 (and R1) prefer the route through R3.

To avoid this behaviour you can change BGP administrative distance with distance bgp command, but this is not recommended… or you can use the network backdoor command.

You can apply this command on one peer to tell it to prefer IGP for a given network:

R1(config)#router bgp 65100
R1(config-router)#network 192.168.2.0 mask 255.255.255.0 backdoor

R2(config)#router bgp 65200
R2(config-router)#network 192.168.1.0 mask 255.255.255.0 backdoor

Now back to the routing tables:

R1#show ip route | beg Gateway
Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.13.0 is directly connected, FastEthernet1/0
C       172.16.0.0 is directly connected, FastEthernet2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/30720] via 172.16.0.2, 00:00:30, FastEthernet2/0
B    192.168.3.0/24 [20/0] via 172.16.13.2, 00:10:29

The route is again reached via the local link!

If the R1-R2 link goes down…

R2#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R2(config)#int fa2/0
R2(config-if)#shu
R2(config-if)#shutdown
R2(config-if)#
*Mar  1 00:21:13.195: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 65100: Neighbor 172.16.0.1 (FastEthernet2/0) is down: interface down
*Mar  1 00:21:15.059: %LINK-5-CHANGED: Interface FastEthernet2/0, changed state to administratively down
*Mar  1 00:21:16.059: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet2/0, changed state to down

… the R2’s network is still reachable via R3:

R1#show ip route | beg Gateway
Gateway of last resort is not set

     172.16.0.0/30 is subnetted, 2 subnets
C       172.16.13.0 is directly connected, FastEthernet1/0
C       172.16.0.0 is directly connected, FastEthernet2/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
B    192.168.2.0/24 [200/0] via 172.16.13.2, 00:00:17
B    192.168.3.0/24 [20/0] via 172.16.13.2, 00:11:43

You can find on the .zip file 3 config versions (config subdir): “1. Interfaces and IP”, “2. EIGRP + BGP” and the final configuration with the network … backdoor command.

Download the lab here!

Categories: Networking, Networking Labs | Tags: , , , ,