ACL deny ip host x.x.x.x any no work

[burtsbees]

Fellas

I posted this in the Cisco routers forum, but I am repeating it here because of my cranial rectumitis. Also, Billy, being interested in security, may help. Here 'tis...

This acl entry

access-list 114 deny ip host x.x.x.x any
access-list 114 permit ip any any
int fa0/1
ip access-group 114 in

did not work. This user was trying to brute force my ftp server, and after hitting enter after entering this acl, the user session was still active (IIS "active sessions", refreshed a few times). However, this..
ip access-list extended 114
11 deny tcp host x.x.x.x host 192.168.69.108 eq ftp
worked. Why did the "deny ip" not work, but "deny tcp" work? The session disappeared immediately. The other surprising thing is that the built-in signatures usually detect such attacks as a UDP bomb...is there a tcp dictionary attack mechanism? Also, does the fact that "deny ip" did not work indicate that the attacker was using an IP spoofer or proxy? I'm green, sort of, when it comes to security. Thanks.

Tim

 

[burtsbees]

By the way, the user seems to be in France, and ARIN showed an abuse@ email address, which I emailed explaining the situation. Sometimes, I may call the NOC if they speak English (or Spanish, for that matter) and tell them about it, and may throw in something about something like illegal searches for prescription drugs online, and some other damning things...muahahahaha...

Tim

 

[maczen]

Burt,
I have never had any luck with the ARIN abuse but the majority of my emails have been directed toward Korea.. who knows! Anyway, I may be a tad rusty but perhaps it is due to the location...

With the standard ACL you will want it closer to the destination so probably not that fast ethernet interface.. That may be why the extended ACL worked because you want to place it closest to the source (you) and that fast ethernet interface sounds about right! I may be wrong but that would be the first thing I would try before looking into it!

Regarding the deny IP question... most likely the IP addy that you blackholed is in fact a proxy but regardless that would have still been effective until he changed it!



B Haines
CCNA R&S, ETA FOI

 

[maczen]

established is the keyword that we were discussing..

Also here is a link to the reflexive ACL... This should eliminate that particular threat in the future.. You will also find TCP intercept info here!

http://www.cisco.com/en/US/docs/ios...TSD_Products_Configuration_Guide_Chapter.html

This is for 12.4 IOS! Syntax is slightly different if you look at some older IOS releases.. (I first located 11.3 LoL)

B Haines
CCNA R&S, ETA FOI

 

[maczen]

Sorry Burt.. Rushed over that too quickly and was thinking you truied a standard then extended list... I would still use the reflexive or at least extended established ACL to eliminate this in the future! Will keep looking regarding why the first didn't work! Curious now!

B Haines
CCNA R&S, ETA FOI

 

[burtsbees]

I think I need to clear NAT translations...that would explain why yours worked, Billy, and script-kiddie's did not. Mine also did not work, but I had ftp'd before that. Then again, so did you before I blocked you, so your NAT entry should still be there, which would then NOT make sense. I will let you guys know...

Burt

 

[maczen]

That just made me think of the movie the Waterboy! Remember when he is looking for a waterboy job and the coach starts describing the 'next big play'???

Now reread that the last post...

"Then again, so did you before I blocked you, so your NAT entry should still be there, which would then NOT make sense. I will let you guys know... The room is starting to spin.. Having trouble breathing.. LoL

OK I will stop.. LoL Let us know Tim! Very curious now!

B Haines
CCNA R&S, ETA FOI

 

[burtsbees]

Interesting...NAT translations cleared, still no workie. However, I should explain my topology...

Internet--Adtran--2620--1751--switches--LAN

The acl was put in the 2620---did not work.

int fa0/0 facing the Adtran L3 PoE switch, which is connected to a T1 to the internet. Int fa0/0 in the 2620 has a public IP address on it, and therefore is where NAT takes place.

access-list 114 permit tcp host x.x.x.x host 192.168.69.108 eq ftp
access-list 114 deny ip any host 192.168.69.108
access-list 114 permit ip any any
int fa0/0
ip access-group 114 in

Applied the acl after
clear ip nat trans *

Did not work. Now the 1751 is connected to the 2620 via WIC-1DSU-T1, T1 crossover cable, subnet 192.168.2.0/30, and fa0 is 192.168.69.0/24, ftp server is 192.168.69.108. I got rid of the acl 114 completely in the 2620 and rebuilt and applied it outbound on fa0 in the 1751. Voila, it works. Now if THAT didn't work, I was going to freak out. I still can't quite get why it would not work in the 2620---I did verify that the only entry in sh ip nat trans was the static entry
ip nat inside source static tcp 192.168.69.108 21 int fa0/0 21
Any thoughts? I suspect something to do with NAT, or the fact that the ftp server is 2 subnets away...but there are static routes in both routers so they know how to get to all three subnets (outside public, T1 crossover between the routers, and the LAN hung off the 1751). I'm just stumped...

Burt

 

[lerdalt]

too bad I had to go to work today..would be very tempted to set this up on my gear and try it out. I think I've seen something similar, but just can't remember for certain.

 

[burtsbees]

I wanna see EVERYONE lab this, and I wanna see debugs, show commands, etc.lol

Burt

 

[maczen]

Burt, I am going to call tomorrow.. Want to map out this topology precisely so that I am not plugging anything up wrong.. LoL

B Haines
CCNA R&S, ETA FOI

 

[burtsbees]

Well, CBAC may be messing with regular acl's and allowing them since I have inspect ftp. Maybe I'll turn it off to see. You would also need the Advanced Security IOS.

Burt