IE Vol I - CBAC for DoS protection : Why does this work ?!?

From: Theo M (theorack@gmail.com)
Date: Mon Nov 19 2007 - 18:21:42 ART


Hello,

This is about the Port-Mapping w/ CBAC (PAM = Port-to-Application
Mapping, Cisco IOS Firewall Port to Application Mapping (PAM)
feature):
"for these particular sources, these particular ports are to be
treated by these specific Inspect protocol modules"

 Notice that the INSIDE ACL(in) on E2/0 doesn't block us from
telnetting from R5::s0/1[155.1.45.5] to R4::Lo0:1023[150.1.4.4:1023],
(in fact to 10.0.0.1:23, due to our Static PAT).

 Why is that ?!? ACLz ignore locally-generated traffic on output, but
NOT on input !!!
 How do we bypass the INSIDE ACL(in) on E2/0 ?!? See config & debugs below...

 The Order of Operations for o->i should be NAT/Inspect/Routing, and
for i->o should be Routing/NAT/Inspect, which seems to be the case.
 If dynamic entries are added to ACL(in) INSIDE, why can't we actually
see them ?
 If no dynamic entries are added, how come our telnet works ?!?

>>>
Rack1R4#sh run
Building configuration...

Current configuration : 2453 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Rack1R4
!
boot-start-marker
boot-end-marker
!
logging buffered 65535 debugging
enable password cisco
!
no aaa new-model
memory-size iomem 15
!
!
ip cef
no ip domain lookup
!
!
ip port-map telnet port tcp 1023 list 99 description TELNET
ip port-map telnet port tcp 6023 list 99 description TELNET
ip inspect name IT telnet
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback0
 ip address 150.1.4.4 255.255.255.0
 ip ospf network point-to-point
!
interface Serial0/0
 no ip address
 encapsulation frame-relay
 no ip route-cache cef
 no ip route-cache
!
interface Serial0/0.1 point-to-point
 ip address 155.1.0.4 255.255.255.0
 ip nat outside
 ip inspect IT in
 ip virtual-reassembly
 no ip route-cache
 frame-relay interface-dlci 405
!
interface Serial0/1
 ip address 155.1.45.4 255.255.255.0
 ip nat outside
 ip inspect IT in
 ip virtual-reassembly
 no ip route-cache cef
 no ip route-cache
 clock rate 64000
!
interface Serial0/2
 no ip address
 shutdown
!
interface Serial0/3
 no ip address
 shutdown
!
interface Ethernet1/0
 no ip address
 shutdown
 half-duplex
!
interface Ethernet2/0
 ip address 10.0.0.4 255.255.255.0
 ip access-group INSIDE in
 ip nat inside
 ip virtual-reassembly
 no ip route-cache cef
 no ip route-cache
 half-duplex
!
router ospf 1
 router-id 150.1.4.4
 log-adjacency-changes
 network 150.1.4.4 0.0.0.0 area 0
 network 155.1.0.4 0.0.0.0 area 0
 network 155.1.45.4 0.0.0.0 area 0
!
router bgp 1
 no synchronization
 bgp router-id 150.1.4.4
 bgp log-neighbor-changes
 neighbor 150.1.5.5 remote-as 2
 neighbor 150.1.5.5 ebgp-multihop 255
 neighbor 150.1.5.5 update-source Loopback0
 no auto-summary
!
no ip http server
no ip http secure-server
!
!
ip nat inside source static tcp 10.0.0.6 23 interface Loopback0 6023
ip nat inside source static tcp 10.0.0.1 23 interface Loopback0 1023
!
!
ip access-list extended INSIDE
 deny ip any any
access-list 99 permit 10.0.0.0 0.0.0.255
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 privilege level 15
 logging synchronous
 history size 256
line aux 0
 privilege level 15
line vty 0 4
 password cisco
 login
line vty 5 871
 login
!
!
end
Rack1R4#
=== NAT o->i
*Nov 19 22:52:54.747: NAT*: o: tcp (155.1.45.5, 57839) -> (150.1.4.4,
1023) [25313]
*Nov 19 22:52:54.747: NAT*: o: tcp (155.1.45.5, 57839) -> (150.1.4.4,
1023) [25313]
*Nov 19 22:52:54.747: NAT*: TCP s=57839, d=1023->23
*Nov 19 22:52:54.747: NAT*: s=155.1.45.5, d=150.1.4.4->10.0.0.1 [25313]
=== Routing, 1st part, o->i
*Nov 19 22:52:54.747: IP: tableid=0, s=155.1.45.5 (Serial0/0.1),
d=10.0.0.1 (Ethernet2/0), routed via FIB
=== CBAC on input, R5::s0/1
*Nov 19 22:52:54.751: CBAC sis 6486F7FC pak 642FF914 SIS_CLOSED/LISTEN
TCP SYN SEQ 470345209 LEN 0 (155.1.45.5:57839) => (10.0.0.1:23)
=== Routing, 2nd part, o->i ( why is the CBAC debug in the middle of
the Routing debug ?!?)
*Nov 19 22:52:54.751: IP: s=155.1.45.5 (Serial0/0.1), d=10.0.0.1
(Ethernet2/0), g=10.0.0.1, len 44, forward
*Nov 19 22:52:54.751: TCP src=57839, dst=23, seq=470345209, ack=0,
win=4128 SYN
=== Routing, 1st part, i->o
*Nov 19 22:52:54.755: IP: tableid=0, s=10.0.0.1 (Ethernet2/0),
d=155.1.45.5 (Serial0/1), routed via FIB
=== NAT i->o
*Nov 19 22:52:54.755: NAT: i: tcp (10.0.0.1, 23) -> (155.1.45.5,
57839) [63730]
*Nov 19 22:52:54.755: NAT: TCP s=23->1023, d=57839
*Nov 19 22:52:54.755: NAT: s=10.0.0.1->150.1.4.4, d=155.1.45.5 [63730]
=== CBAC on output, R5::s0/1
*Nov 19 22:52:54.755: CBAC sis 6486F7FC pak 647D2F7C
SIS_OPENING/SYNSENT TCP SYN ACK 470345210 SEQ 562784150 LEN 0
(150.1.4.4:1023) <= (155.1.45.5:57839)
=== Routing, 2st part, i->o ( why is the CBAC debug in the middle of
the Routing debug ?!?)
*Nov 19 22:52:54.759: IP: s=150.1.4.4 (Ethernet2/0), d=155.1.45.5
(Serial0/1), g=155.1.45.5, len 44, forward
*Nov 19 22:52:54.759: TCP src=1023, dst=57839, seq=562784150,
ack=470345210, win=4128 ACK SYN
Rack1R4#
Rack1R4#sh deb
Generic IP:
  IP packet debugging is on (detailed)
  IP NAT detailed debugging is on
Inspection:
  INSPECT special events debugging is on
  INSPECT TCP Inspection debugging is on

Rack1R4#
<<<

Update:

However, if we use a standard ACL, access-list 22, like below, instead
of INSIDE, the telnet connection gets dropped on input, on E2/0:\

>>>
Rack1R4#sh run int e2/0
Building configuration...

Current configuration : 184 bytes
!
interface Ethernet2/0
 ip address 10.0.0.4 255.255.255.0
 ip access-group INSIDE in
 ip nat inside
 ip virtual-reassembly
 no ip route-cache cef
 no ip route-cache
 half-duplex
end

Rack1R4#sh access-lists
Standard IP access list 22
    10 deny any (8 matches)
Standard IP access list 99
    10 permit 10.0.0.0, wildcard bits 0.0.0.255
Extended IP access list INSIDE
    10 deny ip any any
Rack1R4#
<<<

Any ideas ?!?

--


This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART