ACL deny log - interpretation

[Damo14]

Hi and aplogies if I have posted this in the wrong forum.

I have an ACL denying inbound tcp22 for VTY mgmt access, we have changed the SSH port from default. I am seeing denies logged by the ACL ass expected, but the destination address is not this box. It is always 2 leading "0" octets followed by 2 unknowns. Certainly unrelated to the router in question or its route table. I am sure this has been asked and answered before but I cant find it! Thanks for any assistance. Example log below - along with corresponding entry from the ACL that is applied to VTY 0 4.

Nov 1 08:15:46.853: %SEC-6-IPACCESSLOGP: list VTY_Access denied tcp 211.248.242.36(61502) -> 0.0.240.62(22), 1 packet

10 deny tcp any any eq 22 log (1249 matches)

[Richard Burts]

When you say the ACL is applied to vty am I correct in assuming that it is applied with access-class? If so I will start with a suggestion that when using access-class it is better to use a standard access list rather than an extended access list which you are currently using.

I agree that the destination address in the log message is strange and suspect it is some type of masking issue. Is there any interface using a mask of 255.255..63?

[Damo14]

Thanks for the reply Richard..... yes ACL applied to lines VTY 0 4 with access-class. No masks as suggested. 2 interfaces - both with /30 public IPs. Just noticed though, when I connected just now, I forgot the custom ssh port and at first attempt was to tcp22. This was logged for my failed attempt:

Nov 3 09:01:47.416: %SEC-6-IPACCESSLOGP: list VTY_Access denied tcp x.x.x.x (54334) -> 0.0.212.62(22), 2 packets

The 0.0.212.62 makes no sense at either end.

Cheers

Damien.

[Richard Burts]

Damien

Thanks for the update. I find it interesting that in this instance the value of the third octet is different but the fourth octet is still .62. I am not sure what is causing this. I wonder if you change from an extended acl to a standard acl (which is more usual for access-class) if these messages would stop?

But then I realize that you do not want to control by specifying address but want to specify the protocol. So I am now wondering if you have an access list applied on interfaces (using access-group). If so you could use the deny tcp 22 in that acl. If not then you may need to accept that these log messages will be part of your environment.

[MHM Cisco World]

I think is random IP try to hack your R/SW.

 Thanks A Lot
MHM

[Damo14]

Thanks to you both for the responses.... MHM, yes understand that these are attempts to connect to SSH. The curiosity is the format of the destination eg 0.0.212.62 (that one was me). It makes no sense from either the source or destination ip addressing. I take Rick's point that I may simply have to accept these in the log, I just wanted to understand what IOS was doing in logging the destination that way. I started looking at these as I was wanting to minimise log collection to the bare essentials, for a SOC/SIEM implemntation that is costing me dearly for the hot storage assocated with the log size. I have many of these ISR "transit" routers in front of remote site firewalls. I would prefer that tcp22 wasn't listening or responding at all, but it seems that isn't possible in IOS on these ISRs. I guess I could remove "log" for the tcp22 deny in my ACL and applied to the VTY lines (we have customised the SSH port). I guess another question.... since the VTY lines are not responding to tcp22, is there any point denying it in the ACL.

Cheers

Damien.

[MHM Cisco World]

hacker not use traceable public IP, this IP 0.0.212.62 is randomly select. 
hacker dont want to SSH but make CPU full of endless SSH. 
anyway 
for tcp22 
there are two level of ACL 
one ACL apply to Inbound interface (face internet)
other ACL apply to VTY 

I think if you use ACL under interface of each router you will totally disable tcp22 from access through Inbound interface and in same time you can access R via any other interface except one facing Internet.
here you can also use VTY ACL to tune who can access via SSH through other interface except the one facing internet.

Thanks A Lot
MHM

[Richard Burts · Accepted solution]

Damien

I wish I understood exactly what IOS is doing here. But I can find no logical explanation for those addresses. I was hoping that a Cisco employee might join the discussion and provide some insight, but has not happened yet.

If your concern is originally about size of log files then removing the log parameter would be a very valid thing to do. It would certainly remove all those messages from the log. And it would have an additional advantage, in that any packet matching an acl using log must be process switches (the cpu must generate the log message) rather than any of the enhanced forwarding methods.

And your last point is interesting. If vty are not responding to tcp 22 then perhaps you do not need to have it in the acl at all.

[Damo14]

Thanks again Rick and MHM.... thinking will close this out and open TAC case to satisfy my curiosity.

After seeing my own failures on tcp22.... I noted these after a connect attempt - erroneusly leaving out my custom ssh port. So I know it's IOS generating the destination address. But can't fathom whether it relates to an artifact at source or destination or just random as MHM suggests. I have thought through timestamp (since destination address does vary, even from same source address) but can't see a relationship. In my endeavour to reduce log size I will not log the tcp22 attempts (Rick) - since nothing is listening there. Here are my own recent connect failures fyi.

Thanks for the contributions.

Damien.

Nov 3 08:56:32.499: %SEC-6-IPACCESSLOGP: list VTY_Access denied tcp 49.255.x.x(54334) -> 0.0.212.62(22), 1 packet
Nov 3 09:01:47.416: %SEC-6-IPACCESSLOGP: list VTY_Access denied tcp 49.255..x.x(54334) -> 0.0.212.62(22), 2 packets
Nov 6 07:54:42.560: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 49.255..x.x(58418) -> 0.0.228.50(22), 1 packet
Nov 6 07:59:48.241: %SEC-6-IPACCESSLOGP: list sl_def_acl denied tcp 49.255..x.x(58418) -> 0.0.228.50(22), 2 packets
Nov 6 08:06:09.006: %SEC-6-IPACCESSLOGP: list VTY_Access denied tcp 49.255..x.x(58484) -> 0.0.228.116(22), 1 packet

[Richard Burts]

Damien

Thanks for the update. If you do open a case with TAC and if they can provide any insight please do post an update here.

A couple more observations:

- interesting that there is more than one acl generating the error (VTY_Access which we already knew about and also sl_def_acl) 

- also interesting is the first 2 attempts from what appear to be same source address and same source port, but approximately 5 minutes apart. And the second 2 attempts from what appear to be same source address and same source port, but approximately 5 minutes apart.

- finally (and most importantly) let us think about some aspects of access-class as compared to access-group for applying acl. One advantage of access-class is that it evaluates every attempt to access the local device and does not care about what destination address was used. (which is why if you use an extended acl with access class that it must specify any as the destination) So if processing of access-class has ignored the destination address, and then processing of access-class needs to create a log message including destination address, then what would it use for the destination address?? Perhaps some random bits from an area of memory?

So maybe I do have an explanation of what IOS is doing?

[Damo14]

I did just notice something as I posed that.... the destination address changes as the source port changes. Still no idea though!!

Cheers

[Damo14]

Rick, thanks. I hadn't noticed the action of the sl_def_acl in that block I posted.... all me btw. Also, had seen that hidden acl many times before but never investigated its purpose, so thatnks for pushing me to that bit of research. Noted your presence there too in some old posts.

I do like your "random bits" theory. The only thing that so far makes sense to me. If I do get an explanation, affirmation of "random bits" or otherwise, from TAC - will definitely post here.

Cheers

Damien.