Young Fighter Course: Intercepting Authentication on Routers

By inhuman willpower :) I added the promised piece of router protection - cut-through proxy . I have described here far from all the subtleties, but rather, as always, “on the fingers” to make it easier to understand. A clever fighter will figure it out without me :)

The task of this technology is to check the user name and password before releasing it outside or letting it inside the perimeter. This is part of the general ideology of IBNS (Identity Based Network System), where the username is decisive and it is by name that you can match the settings of a particular client, for example, an access list that describes what this client can do.
To verify users, you can use external databases accessible via the TACACS protocol (tsiskina technology, TCP / 49), RADIUS (standard technology, UDP / 1645 or UDP / 1812 for authentication, UDP / 1646 or UDP / 1813 for collecting statistics) or Kerberos 5 (Microsoft technology).


In order to make the router ask for external user databases, you must enable the new AAA model (Authentication, Authorization, Accounting)

aaa new-model

This command is insidious, because includes default authentication rules, and these rules read "Use a local user database." If there are no local users, then you fall into a trap (lockout), from which there is only one way out - the procedure for password recovery (password-recovery)
Next, you need to create an authentication rule that points to an external server and describe this server itself: what protocol to communicate with, what address and which key

radius-server host {ip} key {key}

Or

tacacs-server host {ip} key {key}
aaa authentication login {name} group {radius | tacacs}

It is necessary to configure the rule of intercepting authentication, indicating by which protocol the client first calls (http, telnet, ftp) and what traffic initiates the client’s response from tsiska (described by the access list, where lines permit means "to give to the client window to request login / password)

the ip the auth-proxy name { mja} {http | ftp | telnet}

[list {ACL}] Default - any traffic for the selected protocol.
Now it remains to describe what authentication rule to use when accessing via http and attach the authentication rule to the interface (the rule is always hung on the interface input)

Ro (config) # ip http authentication aaa [login-authentication {name}]
Ro (config) # int f0 / 0 (internal interface where packets come from the client)
Ro (Config-if) # ip auth-proxy {name}

In older IOS, it was not possible to explicitly specify the authentication rule used for authentication via http, i.e. the default rule was always used and it was necessary to change it to use the TACACS or RADIUS server

aaa authentication login default group {radius | tacacs}

Now it is possible to explicitly specify not only the rule for login via http, but also a separate rule for command authorization and entering the exec mode via http (SDM, CCE).
Additionally, to initially allow the user a little bit, and only after authentication explicitly allow him what it is supposed to do, it is necessary to hang up a fairly strict access list on the same interface that would allow only what everyone can and always, for example, initial packets for authentication and, for example, some kind of shared local resources

ip access-list ext ZLOY
permit tcp any host 1.2.3.4 eq 80
permit tcp any host 135 172.16.1.100 eq
int f0 / 0
ip access-group ZLOY in

Since the incoming access list on the interface always fulfills first, then it will work like this:
1. A package comes. We check it with the access list, if it is allowed
2. If it is allowed, then we check further whether the packet came from the authenticated source IP address.
3. If not, then check by what protocol the packet came.
4. If according to the protocol specified in the ip auth-proxy rule, then we issue a window for entering the login / password in the browser, ftp or telnet application of the client, otherwise we simply destroy the packet.

Let’s analyze an example :
Let us have a router with the internal interface f0 / 0 . We want the traffic directed to all networks except the 172.16.1.0/24 network to be authenticated using the http protocol first.

Ro (config) # ip access-l ext AUTHACL
Ro (config-ext-nacl) #deny ip any 172.16.1.0 0.0.0.255
Ro (config-ext-nacl) #permit ip any any
Ro (config) # username admin pass cisco (just in case, not to accidentally block yourself)
Ro (config) # aaa new-model
Ro (config) # radius-server host 1.1.1.1 key cisco
Ro (config) # aaa authentication login AUTH group radius
Ro (config) # ip http server (we turn on the http server on cisco)
Ro (config) # ip http authentication aaa login-authentication AUTH
Ro (config) # ip auth-proxy name OUT http list AUTHACL
Ro (config) # ip access-l ex ZLOY
Ro (config-ext-nacl) # permit tcp any h 1.2.3.4 eq 80
Ro (config) # int f0 / 0
Ro (config -if) # ip access-group ZLOY in
Ro (config-if) # ip auth-proxy OUT

If you are not comfortable with the unsafe http protocol, you can use the secure https protocol. To do this, you need to work out the RSA key pair and turn on the https server (it will write the self-signed tsisk certificate)

Router (config) # hostname Ro (you need to set the default hostname)
Ro (config) # ip domain name mydomain.com
Ro (config) #crypto key generate rsa [modulus-size {size}] [label <label>]
Ro (config) # do wr
Ro (config) # ip http secure-server


After this, https connections will also be intercepted with a tsiska to verify the login / password.
It should be noted that the technology is rather cumbersome, when working on https it significantly slows down the first connection if you do not save the self-signed tsiska certificate as trusted, and not too flexible. However, it allows you to check users and their rights and is an integral part of a number of implementations to protect the perimeter.

Sergey Fedorov