The course of the young fighter: intercepting authentication on the routers

Inhuman effort of will :) did finish the promised piece of protection by the router - cut-through proxy . I have described here not all the subtleties, but rather, as always, “on the fingers” in order to make it easier to understand. A clever fighter, yes, he 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 go inside the perimeter. This is part of the overall ideology of IBNS (Identity Based Network System), where the user’s name 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 a given client can do.
To verify users, you can use external databases that are available via the TACACS protocol (ciskin 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 force the router to request external user bases, you need to enable the new AAA model (Authentication, Authorization, Accounting)
')
aaa new-model

This command is cunning, because includes default authentication rules, and these rules state “Use Local User Database”. If there are no local users, then you are trapped (lockout), from which there is only one way out - the password recovery procedure (password-recovery)
Next, you need to create an authentication rule that points to an external server and describe this server itself: what protocol to contact with it, to what address and with which key

radius-server host {ip} key {key}

Or

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

You need to configure the rule of intercepting authentication, specifying which protocol is used for the initial client access (http, telnet, ftp) and what traffic initiates a response from the client (described in the access list, where the permit lines mean “give the client a login / password request window)

ip auth-proxy name {name} {http | ftp | telnet} [list {ACL}]

By default - any traffic on the selected protocol.
Now it remains to describe how to use the authentication rule for access via http and hang the authentication rule on the interface (the rule is always hung up 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 http authentication, 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 by http, but also a separate rule for command authorization and enter exec mode via http (SDM, CCE)
Additionally, in order to initially allow a user a little bit, and only after authentication, explicitly allow him what he is supposed to, a rather strict access list must be hung on the same interface that would allow only what everyone can and always, for example, initial packages for authentication and, for example, some common local resources

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

Because the incoming access list on the interface always works first, then it will work like this:
1. Package arrives. We check it with the access list, whether it is allowed
2. If enabled, then we check further whether the packet came from the authenticated ip source address.
3. If not, then we check which protocol the packet came from.
4. If according to the protocol specified in the ip auth-proxy rule, then we give out in the browser, ftp or telnet client application a window for entering a login / password, otherwise just destroy the package

Let us examine an example :
Let there be a router, with an internal interface f0 / 0. We want traffic sent 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, in order to not block yourself accidentally)
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 (enable http server on ziska)
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 satisfied with the insecure http protocol, you can use the secure https protocol. To do this, you need to develop a key pair of RSA and enable the https server (the self-signed certificate of the tsiska will be written out by itself)

Router (config) # hostname Ro (you must specify a 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 connection via https will also be intercepted by cisco to check the login / password.
It should be noted that the technology is rather cumbersome, when working on https, the first connection significantly slows down if you do not save the self-signed tsiska certificate as trusted and not too flexible. However, it allows you to verify users and their rights and is an integral part of a number of perimeter security implementations.

Sergey Fedorov