dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1156
share rss forum feed

Zippy833

join:2013-01-16

[HELP] ACL Please help

Hello All,

I am filling in this week for a Network Engineer that is out on vacation. As of late I have been receiving notifications from one of our offices that someone is trying to connect to a router on site via SSH.

here is the code

-----------------------------------------------------------------

Jan 16 13:11:00.589: %SSH-5-SSH2_USERAUTH: User 'www' authentication for SSH2 Session from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Failed
Jan 16 13:11:00.589: %SSH-5-SSH2_CLOSE: SSH2 Session from 14.160.87.130 (tty = 0) for user 'www' using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' closed
Jan 16 13:11:02.585: %SSH-5-SSH2_SESSION: SSH2 Session request from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Succeeded
Jan 16 13:11:06.890: %SSH-5-SSH2_USERAUTH: User 'www' authentication for SSH2 Session from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Failed
Jan 16 13:11:06.890: %SSH-5-SSH2_CLOSE: SSH2 Session from 14.160.87.130 (tty = 0) for user 'www' using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' closed
Jan 16 13:11:08.966: %SSH-5-SSH2_SESSION: SSH2 Session request from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Succeeded
Jan 16 13:11:13.294: %SSH-5-SSH2_USERAUTH: User 'www' authentication for SSH2 Session from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Failed
Jan 16 13:11:13.294: %SSH-5-SSH2_CLOSE: SSH2 Session from 14.160.87.130 (tty = 0) for user 'www' using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' closed
Jan 16 13:11:15.379: %SSH-5-SSH2_SESSION: SSH2 Session request from 14.160.87.130 (tty = 0) using crypto cipher 'aes128-cbc', hmac 'hmac-sha1' Succeeded

-----------------------------------------------------------------

Obviously they are not getting in but the logs are filling up and the interface is being overloaded. How can I create an ACL that will block them from even establishing an connection?

Im a systems guy not a network so any hints would be much appreciated.

Thank you


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
The quick and dirty way would be the following:

ip access-list extended WAN-INPUT-FILTER
 deny tcp host <x.x.x.x> any eq 22
 permit ip any any
!
interface <wan>
 ip access-group WAN-INPUT-FILTER in
!
 

Just replace <x.x.x.x> with the IP you need to block, and <wan> with the name of your WAN interface.

You can block multiple hosts by duplicating the deny line above, but keep in mind that if they appear after the permit line they wont have any effect (ACLs are processed in order, not simply by the rules that exist in them!)

After a couple of days, from the CLI of the router (not in configuration mode) you can do a "show ip access-list WAN-INPUT-FILTER" and see if the hit count for the deny rule(s) are incrementing, and if not, "no" the ACL from the WAN interface configuration.

You can find quite a bit more info at this URL:

»www.cisco.com/en/US/products/sw/···9a.shtml

However, the better and long term solution would be to configure an access-class on the VTY line configuration. This will lock down SSH/Telnet access to the router to trusted hosts and subnets, eliminating the need to constantly update a black list of hosts that are annoying you.

See this URL for an example of that:

»blog.ioshints.info/2006/12/vty-a···and.html

Hope that helps.

Zippy833

join:2013-01-16
reply to Zippy833
I like the long term solution better, but there are multiple ranges that the router gets accessd from

from any 172.16.0.0/12 internal address

how would I go about doing that with this

ip access-list extended TerminalAccess 
permit tcp host 10.0.0.2 any eq telnet log 
permit tcp any any eq 22 log 
deny tcp any any log
line vty 0 4 access-class TerminalAccess in 
 

from what I read this is for single ips

Zippy833

join:2013-01-16
reply to Zippy833
I tried this but this seems to be allowing access from any host

ip access-list extended vtyaccess
 permit tcp 209.117.253.128 0.0.0.63 any eq telnet log
 permit tcp 172.16.0.0 0.15.255.255 any eq telnet log
 permit tcp any any eq 22 log
 deny   tcp any any log
 
line vty 0 4
 access-class vtyaccess in
 exec-timeout 11 0
 

I took it off for the time being

aryoba
Premium,MVM
join:2002-08-22
kudos:4
Try the following instead

ip access-list extended vtyaccess
 permit tcp 209.117.253.128 0.0.0.63 any range ssh telnet log
 permit tcp 172.16.0.0 0.15.255.255 any range ssh telnet log
 deny   tcp any any log
 
line vty 0 4
 access-class vtyaccess in
 exec-timeout 11 0
 

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to TomS_
said by TomS_:

However, the better and long term solution would be to configure an access-class on the VTY line configuration. This will lock down SSH/Telnet access to the router to trusted hosts and subnets, eliminating the need to constantly update a black list of hosts that are annoying you.

See this URL for an example of that:

»blog.ioshints.info/2006/12/vty-a···and.html

Hope that helps.

If there is no AAA server currently, setting up one will be providing further security and is actually a standard practice in lots of organizations. You can use either Cisco ACS, Windows RADIUS, Linux TACACS or RADIUS (which are free), or any AAA server type that suits your situation.


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
reply to Zippy833
The rule

 permit tcp any any eq 22 log 
 

will permit SSH sessions from anywhere. Telnet should be restricted to the subnets specified. Is this what you are seeing, or are you able to Telnet from anywhere as well?

Otherwise, my own experience tells me that when applying an ACL to the VTY config, you can only really block or accept by subnet, that is to say you could do the following:

ip access-list extended vtyaccess
 permit ip 209.117.253.128 0.0.0.63 any
 permit ip 172.16.0.0 0.15.255.255 any
 deny   ip any any log
 

I dont think it is "smart" enough to take in to consideration protocols and ports, unless that has changed in recent more IOS versions - I havent tried since usually blocking by subnet is sufficient.

aryoba
Premium,MVM
join:2002-08-22
kudos:4
said by TomS_:

I dont think it is "smart" enough to take in to consideration protocols and ports, unless that has changed in recent more IOS versions - I havent tried since usually blocking by subnet is sufficient.

What I usually do is to implement standard ACL for VTY access and restrict to only certain remote access protocols using transport command with input parameter. As a note that transport command is specified under line vty along with access-class command.


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
Very true, I forgot about that!

And yes, in the past I have tended to use standard ACLs, usually 23 as I tended to only use Telnet for access and 23 is the TCP port for Telnet.

Im tending towards SSH these days though, so most likely I'd use ACL 22, or probably something similar to "vtyaccess" if named.

Where possible I use named ACLs, since you are able to more easily convey what they do or what they are used for when you browse through your config. Though as I understand it, support for named ACLs was not (still isnt?) ubiquitous through IOS, so sometimes you have to use a numbered ACL...

Zippy833

join:2013-01-16
reply to Zippy833
soo I did this now

ip access-list extended vtyaccess  
permit tcp 209.117.253.128 0.0.0.63 any range ssh telnet log  permit tcp 172.16.0.0 0.15.255.255 any range ssh telnet log  deny   tcp any any log    
 
line vty 0 4  
access-class vtyaccess in  
exec-timeout 11 0 
 

and now I am getting this

Jan 16 19:30:39.720: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(48994) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:40.876: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(49073) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:42.020: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(49346) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:43.172: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(49633) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:44.313: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(49876) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:45.445: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(50058) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:46.585: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(50327) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:47.725: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(50699) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:48.869: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(50888) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:50.005: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(51142) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:51.141: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(51419) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:52.277: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(51658) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:53.413: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(51760) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:54.549: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(52123) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:55.690: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(52337) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:56.834: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(52574) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:57.970: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(52779) -> 0.0.0.0(22), 1 packet  
Jan 16 19:30:59.114: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(53181) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:00.250: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(53353) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:01.390: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(53557) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:02.526: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(54028) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:03.658: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(54095) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:04.794: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(54265) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:05.938: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(54564) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:07.082: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(54906) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:08.219: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(55009) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:09.355: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(55374) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:10.491: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(55723) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:11.623: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(55867) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:12.759: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(56132) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:13.895: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(56421) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:15.031: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(56673) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:16.167: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(56772) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:17.303: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(57033) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:18.504: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(57418) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:19.584: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(57538) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:20.712: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(57735) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:21.904: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(58101) -> 0.0.0.0(22), 1 packet  
Jan 16 19:31:22.980: %SEC-6-IPACCESSLOGP: list vtyaccess denied tcp 121.12.121.217(58343) -> 0.0.0.0(22), 1 packet 
 

Yes there is AAA server configured for Tacacs+

and NO i cannot connect via ssh and telnet if im not specified in that range

aryoba
Premium,MVM
join:2002-08-22
kudos:4
If the 121.12.121.217 is illegitimate source IP address to remote access, then the log shows a good thing. If the IP address is legitimate source however, then simply add the IP address into permitted list.

When you do add legitimate source IP address, make sure you insert instead of regular add so that the new legitimate IP address traffic permission will be executed before the deny command.


phantasm11b
Premium
join:2007-11-02
reply to Zippy833
So based on your ACL, the 121.x.x.x IP space is not permitted. THe reason your log is filling up with all the entries is because you have the 'log' flag enabled on the deny line. If you don't want to see those entries in the device log, then remove the 'log' flag. If you want to see what is being denied, leave it in.

ladino

join:2001-02-24
USA
kudos:1
Below is a configuration that should help mitigate the connection attempts from unauthorised used

- Adding a 3 second delay slows down the connection frequency attempts.
- Requires passwords to be a minimum of 6 characters or more to even connect
- For the VTY preferably use a stand ACL
- On the interface facing the internet, add an ACL allowing the specific hosts to connect & deny any other hosts from logging in. This way you can filter traffic before it even enters the router, wasting CPU cycles & AAA resources

!
service tcp-keepalives-in
service tcp-keepalives-out
!
security passwords min-length 6
login delay 3
!
!
interface GigabitEthernet0/0
 description ** interface facing the internet **
 ip access-group WAN-INPUT-FILTER in
!
!
ip access-list extended WAN-INPUT-FILTER
 permit tcp 209.117.253.128 0.0.0.63 any range ssh telnet
 deny tcp any any range ssh telent
 permit ip any any
!
ip access-list extended vtyaccess
 permit 209.117.253.128 255.255.255.192
 permit 172.16.0.0 255.255.15.0
 deny any log
!
!
line vty 0 4
 access-class vtyaccess in
 exec-timeout 5 0
 transport input ssh
!
 

It looks like 121.12.121.217 is not a legitimate host that needs to log in

HELLFIRE
Premium
join:2009-11-25
kudos:18
reply to Zippy833
Another Q and D way to have resolved this would've been this :

config t
ip route 14.160.87.130 255.255.255.255 null0
^z
 

Otherwise, what aryoba See Profile gave you is working, and I second what was mentioned about cleaning
up the deny log statement so your syslog server doesn't go nuts with noise.

I'd also add when the Network Engineer comes back, prepare a 4page document of what transpired here,
plop it on his desk, and tell him, "this needs to be fixed ASAP."

Regards

cramer
Premium
join:2007-04-10
Raleigh, NC
kudos:9
Well, it's only "broken" because someone (new) is looking at it.
- if you don't want to see it, don't log it.
- if you don't want to see ssh dictionary attacks, don't open port 22 to the internet (even if you aren't running ssh on that port)
- it's generally bad practice to allow console (vty) access to untrusted hosts. (i.e. no acl)

Zippy833

join:2013-01-16
reply to Zippy833
Thanks guys

so I removed the "log" flag on the permit and deny so that it dosent fill up the loggs.

and Yes the 121.xx.xxx.xx is not authorized on the network

ip access-list extended vtyaccess
 permit tcp 172.16.0.0 0.15.255.255 any range 22 telnet 
 permit tcp 209.117.253.128 0.0.0.63 any range 22 telnet 
 deny   tcp any any
 


TomS_
Git-r-done
Premium,MVM
join:2002-07-19
London, UK
kudos:5
Now wait for the network admin to come back and ask why he cant log in from home any more.

Zippy833

join:2013-01-16
reply to Zippy833
LOL that faker should be using VPN to get connected anyway

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to cramer
said by cramer:

Well, it's only "broken" because someone (new) is looking at it.
- if you don't want to see it, don't log it.
- if you don't want to see ssh dictionary attacks, don't open port 22 to the internet (even if you aren't running ssh on that port)
- it's generally bad practice to allow console (vty) access to untrusted hosts. (i.e. no acl)

I second cramer See Profile's statement. Removing log parameter from deny statement may not fill up your syslog server. However such log parameter on deny statement may still be needed if the remote connection attempt is coming from Trusted or Inside network for audit/review purposes.

Here is what some organizations implement.
* Block incoming ssh from the Internet without the log parameter on deny statement
* Block incoming ssh from unauthorized source IP addresses or subnets that are within Trusted or Inside network, and have log parameter on deny statement for audit/review purposes

aryoba
Premium,MVM
join:2002-08-22
kudos:4
reply to HELLFIRE
said by HELLFIRE:

I'd also add when the Network Engineer comes back, prepare a 4page document of what transpired here, plop it on his desk, and tell him, "this needs to be fixed ASAP."

At least now you know what can be improved and learn a little bit about network security from network engineering perspective