The Intro

One of the things I do regularly for my clients is to build LNS Infrastructure to take wholesale L2TP handoff. It is not uncommon to take these handoffs from several suppliers covering technologies such as DSL, Dialup ports, Wireless, 3G etc.

Wholesale pricing in Australia means that it is not unreasonable to take a wholesale L2TP handoff from an Aggregator company and to build your corporate WAN using wholesale DSL services. Often these networks are built for customers who’s primary business is not running networks, but rather delivering a service. I have an upcoming series of blog posts that will cover creating these services in more detail.

Once building this infrastructure, barring a new wholesale type, there is little more required than to order the service from the wholesaler and add a service to your RADIUS server. Other than the regular maintenance and patching of any network device, things generally go smoothly day-to-day.

That is until the “provisioning team” from said customer sends out a poorly configured router, and nobody discovers till it gets onsite. Usually this manifests in an incorrect PPP password.

I wont say that this happens often, but it happens enough that I need a “fix” ready to apply when the customer calls.

Isn’t it amazing how a poorly configured CPE is my fault?.

The Fix

The RADIUS standard provides us with an attribute that can be utilised in this situation – The Auth-Type Attribute. This attribute can be used to forcibly “Accept” or “Reject” a RADIUS account. All you need to do is to add “Auth-Type := Accept” to your RADIUS Check entry and RADIUS will ignore the password stored.

A simple RADIUS entry looks something similar to:

ppp-user        User-Password:= "password"
		Framed-IP-Address = "10.10.10.10"

With the Auth-Type override it would look like this:

ppp-user        User-Password:= "password", Auth-Type := "Accept"
		Framed-IP-Address = "10.10.10.10"

Next time the client tries to re-authenticate, RADIUS will choose to authorise this user even if the password is wrong.

The Catch

So after having to once again implement this attribute earlier this week to fix a router that was only sending a CHAP (and therefore encrypted) password, I decided to make a tweet about it. Not long after had I posted this, Ivan Pepelnjak of IOS Hints replied with:

It's also a terrific security hole. How do U make sure the acct is not used to log into your router?

My first response was that you should use a separate AAA server for your Console/Admin Authentication to Customer/PPP Authentication. Ivan promptly replied with:

Still, is there a way to prevent that acct from being used as a router login?

Thinking this was some kind of test, I started thinking…

The Answer

Before I was able to tweet a reply, Petr Lapukhov replied with:

@ioshints @networkjanitor hmmm, "autocommand=ppp" for PPP accts? remember doing that back in 98's :)

Now while I believe Petr’s response will have the desired overall effect, I suggest that it is less than ideal. Essentially the “autocommand” feature is used to run a set command on login of the user and then log them out. Ivan has written some posts on this on his blog. The two short-comings I see to this method are:

1. If the you try to use this account for console access to the router you are given a session with either a stream of rubbish on the terminal, or “This line may not run PPP.” followed by a disconnection.
2. The user is actually authenticated “OK”, by the RADIUS server, and no denied attempt will be logged for auditing purposes.

My view is the correct fix to this problem lies in RADIUS Best Practice implementation of the “Service-Type” Attribute.

Yes, I purposely left this out of the RADIUS configurations above!)

When used in the RADIUS Check section, the Service-Type attribute will only allow a match if the Correct Service type is sent. The two general ones that relate to this post are:

1. Service-Type = Login-User – Used for console/vty access to a RADIUS client
2. Service-Type = Framed-User – This is generally the service type that is used for PPPoE and L2TP termination.

I built a test lab this morning, and tested the above assumption with the following results:

When configured with the original settings listed above. the “ppp-user” account was able to successfully authenticate and log into the router.

The modification below was able to successfully stop the account for being used for vty login to the router, while still successfully being able to login via PPP.

ppp-user        User-Password:= "password", Service-Type = Framed-User
		Framed-IP-Address = "10.10.10.10"

And just because I wanted to ensure that “Auth-Type” would not override the “Service-Type” attribute, I tested the below config as well, and confirmed that this also would not allow vty console access to the router.

ppp-user        User-Password:= "password", Service-Type = Framed User, Auth-Type := "Accept"
		Framed-IP-Address = "10.10.10.10"

The Wrap Up

What was meant to just be an off handed tweet about a useful feature ended up sending me to the lab to test a bunch of assumptions I had been making in the past. I ended up learning a lot about a task I spend a lot of my week doing.

If you have any other suggestions (or corrections!), then please comment below.

Stay tuned for the upcoming series on creating your own LNS infrastructure.

Update: The Forgotten Credits

I would also like to thank Marko Milivojevic from IPExpert who acted as a sounding board while working through this post, and confirmed some of my suspicions before I went on to lab them. As always Marko, thankyou for your assistance!

RADIUS