Details to implement local user/password VPN authentication

[fmt_cisco]

I'm using a PIX 515E with PIX Firewall Version 6.3(3) I've got a working VPN using group password. I'd like to implement user/password authentication.

I know this is possible using a second authentication server, like a Radius. But since my user base is small (about 30 users), so I'd like to store the user list locally in the Pix. I think this is possible, isn't it? Could someone give me the steps or point me to any webpages? And how to create a username so that this username can only be used for VPN access but not for access to PIX through telnet?

TIA

[p.vdvoort]

Hi,

To use local authentication for VPN users, use this in your crypto-map:

crypto map MyMap client authentication LOCAL

And then add local users with:

username password

For telnet access you can use another authentication method like tacacs+:

aaa authentication telnet console TACACS+

aaa authentication enable console TACACS+

With this, the local userbase is no consulted for telnet users.

HTH

Peter

[fmt_cisco]

So, if I understand it correctly, VPN user base and telnet access user base can't be in the same server, right?

Well, my original idea was to avoid using an extra server for authentication....

[p.vdvoort]

Ah, I misread that part.

You can have only one local user base. So if you can't make a separation there, you could do it using the telnet ACL. Only allow telnet via the inside interface.

I see your point though, that you want to separate engineers from VPN-users.

Peter

[fmt_cisco]

I wanted to separate PIX admin and normal VPN users above all.

Right now, I'm the only person who could telnet into the Pix and change config, because I know the password and nobody else.

If I create a user and a password in the local user base for VPN, could he use this credential to get into the Pix and change config?

As to allow telnet via the inside interface or not is not a protection because we've got terminal services for users. So anyone could log into TS, and then telnet from there to the PIX.

[p.vdvoort]

Well, best thing to do obviously is to find another way for yourself to telnet to the pix so that you can deny access from the terminal server. Now, if a VPN user was able to sniff network traffic, and you're using telnet to get to the pix..... your credentials are exposed.

But I guess that's not an option.

In this case, you can't stop VPN users from telnetting to the pix. The only thing that separate them from you then is the enable password (until a clever one starts sniffing the network).

What you could do to at least mitigate the problem a bit is to use:

username password privilege 0

Now people will still be able to login to the pix, but there's not much they can do besides some show commands (I don't know exactly which ones, you'll have to try it).

Also, you should switch to using SSH so that sniffing becomes useless.

(Obviously, users with priviledged access to the terminal server could still find ways to get your credentials.)

Maybe there's something more that you can do with authorization (like being authenticated to start a shell, but not being authorized to start one). I know how to do that with tacacs+ but I don't think it's possible with LOCAL.

Hope this gets you a bit further.

Peter

[fmt_cisco]

Hmm, I thought I'd better concentrate on setting up a working xauth VPN, and then see the security later.

So, I've made another vpngroup, thinking that I could set it up to show how xauth is working. But when I came upon your

crypto map MyMap client authentication LOCAL

it seems to me that this command affects everything relating to VPN on the outside interface. Am I correct?

My worry is that my second vpngroup is useless because those who are using the first vpngroup will also be asked to identify themselves, right?

And I hope it won't affect the current site-to-site VPN configuration.

[p.vdvoort]

You can only have one crypto map on an interface. When I said "MyMap", I meant the crypto map you're already using. But yes, this affects the existing Remote-access VPNs (not LAN-to-LAN VPNs).

You cannot have one group of users having to authenticate and the others not.

[fmt_cisco]

OK, thanks for this last reply. That's particularly useful.

[mherald]

This is just my $.02. Although this solution is possible, it puts a ton of administration tasks on the IT admin staff just to keep users up to date on their passwords. Users loose thier passwords all the time, rarely during work hours or a convenient time for you.

From a security perspective, the IT admin staff or an additional person will know another users VPN username/password combination.

There are way too many benefits of using RADIUS or TACACS+ to authenticate users via a Microsoft, Novell, pick your favorite directory services, even with a small user base.

If you really need to proceed with this method (and I strongly advise not going forward with it), when you create a username, assign a low (not 0) priv level with the username. Certainly do not assign a priv level on 15.

Additionally, if you have enough memory in this device, I would look at upgrading the code if/when possible.

Mike