topic Re: Cisco Auth Logging in Communications and Wireless

Cisco Auth Logging

adam_82 — Wed, 02 Jul 2003 13:10:55 GMT

Hi, I have a cisco soho series router and I am logging events to a syslog server.. I am trying to log whenever someone logs into the router but not having much success.. Any ideas?

Re: Cisco Auth Logging

Ron Kinner — Wed, 02 Jul 2003 14:16:56 GMT

Since you already have it talking to a syslog server (if not: http://www.cisco.com/warp/customer/477/SNMP/snmp_traps.html#topic1) and since there does not appear to be a trap for logins, I would try building a logging access list which would look for telnet traffic to the router and log it. I have never worked with such a small router before so can't be sure it will take the usual IOS commands but try (assuming you do not have any access-lists already programmed. If so use a different number in the 100-199 range):

conf t
access-list 101 permit tcp any any log

(Then apply the access list to the vty interfaces.)

line vty 0 4
access-class 101 in
end
wr me

Note you can use this method to block access to all but a certain group of IP addresses if you want by changing the first "any" to "host a.b.c.d" and repeating the line for each host with ip address a.b.c.d which should be allowed to access the router or replacing the "any" with a network address and reverse mask ( class C example: a.b.c.0 0.0.0.255) which would restrict access to only hosts on the a.b.c.0 network.

Ron

Re: Cisco Auth Logging

adam_82 — Wed, 02 Jul 2003 14:31:34 GMT

Thanks for your reply Ron.

I already have a big access list set up to prevent access to the router from unknown sources.

I want to be able to specifically log any auth attempts to the router itself.

I guess this is more for audit reasons so that I can see who logged in, when.. The method of using the acl shows that some kind of traffic was either accepted or denied by my acl, I really need it to be auth specific??

Re: Cisco Auth Logging

Ron Kinner — Wed, 02 Jul 2003 19:51:05 GMT

Make a separate access list using a different number just for the virtual terminals and if the log file doesn't tell you what IP address tried to do it then you can expand the access list by making it look for a particular IP address. Since the access list is only used by the terminals then any indication would indicate an attempt and should tell you when and what IP tried to get in.

You can also set it up to use an external database for authentification tho you would have to have a server running radius (http://www.freeradius.org/) or tacacs+ (http://www.gazi.edu.tr/tacacs/)

Cisco set up: http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_command_reference_book09186a00800ca4ad.html

Finally if you don't mind a lot of garbage in your syslog you can turn on aaa authentification and then turn on debug aaa auth.

conf t
aaa new-model
aaa authentication login default local
user YOU password YOURPASSWORD
cons logg deb
logg buff
logg trap deb
end
debug aaa auth

You may not need the "cons logg deb" command but it doesn't seem to work on 11.0 without it and that's all we have in the lab to play with. You will now have to login with a username and password and you should get something like this each time:

AAA/AUTHEN: free user='you' ruser='' port='tty3' rem_addr='172.16.4.71' authen_t
ype=1 service=1 priv=1
AAA/AUTHEN: create_user user='' ruser='' port='tty3' rem_addr='172.16.4.71' auth
en_type=1 service=1 priv=1
AAA/AUTHEN/START (0): port='tty3' list='' action=LOGIN service=LOGIN
AAA/AUTHEN/START (0): using "default" list
AAA/AUTHEN/START (67502978): Method=LOCAL
AAA/AUTHEN (67502978): status = GETUSER
AAA/AUTHEN/CONT (67502978): continue_login
AAA/AUTHEN (67502978): status = GETUSER
AAA/AUTHEN/CONT (67502978): Method=LOCAL
AAA/AUTHEN (67502978): status = GETPASS
AAA/AUTHEN/CONT (67502978): continue_login
AAA/AUTHEN (67502978): status = GETPASS
AAA/AUTHEN/CONT (67502978): Method=LOCAL
AAA/AUTHEN (67502978): status = PASS

It shows up in Sh log so I suppose it would also get sent to your syslog. If you decide to try this, test it with a second telnet session before saving the config or logging off. That way if you mess it up and it won't let you in then you can fix it with the first session and you won't be locked out.

Ron