Smoothwall Authentication - Safeguarding issue?

[TechMonkey]

Ok, am I over reacting? (Ok, Ok, I know the answer will be yes but bear with me)

 

We have been having an issue where a lot of requests through our Smoothwall box end up being 407'd, which is proxy authentication required, and no username shown, just an IP. I posted about this and someone mentioned that they get it occasionally if the NTLM handshake plays up, I looked at the logs and this didn't seem to be the issue. I logged a call with Smoothwall and was originally told that this was normal. I've never seen this behaviour before and asked for it to be escalated.

 

Just had a call from Smoothwall to say this is a known issue with NTLM and Kerberos. If the end host, so the website the user is requesting, doesn't use NTLM or Kerberos authentication then the information isn't sent and the Smoothwall proxy can't ID who the user is. The only way around this is to use SSL authentication, meaning to browse the web every user will have to log on through the web portal. In the 5 years of using Smoothwall I've not come across this, unless something od has happened or a site is in proxy bypass then a username has been logged. It also seems odd that Smoothwall is pushed in Education but it can't guarantee an audit trail for a pupils web traffic.

 

For me this means Smoothwall is next to useless as I can't produce a full audit on pupil's web activity in the event something happens, or to prevent something happening unless I make everyone log in via the portal which with small ones is a real hassle. I also don't understand how Smoothwall can be used as a proxy if it can only be used to identify users based on the server at the other end of a request allows Authentication, I would expect the majority of web servers to use anonymous access as they have no need to know user credentials. How does it know which group to assign someone or policies to apply?

 

So as I asked at the beginning, am I over reacting? Or am I off to Lightspeed?

[OB1]

Ok, am I over reacting? (Ok, Ok, I know the answer will be yes but bear with me)

Yes

 

We have been having an issue where a lot of requests through our Smoothwall box end up being 407'd, which is proxy authentication required, and no username shown, just an IP. I posted about this and someone mentioned that they get it occasionally if the NTLM handshake plays up, I looked at the logs and this didn't seem to be the issue. I logged a call with Smoothwall and was originally told that this was normal. I've never seen this behaviour before and asked for it to be escalated.

 

Just had a call from Smoothwall to say this is a known issue with NTLM and Kerberos. If the end host, so the website the user is requesting, doesn't use NTLM or Kerberos authentication then the information isn't sent and the Smoothwall proxy can't ID who the user is. The only way around this is to use SSL authentication, meaning to browse the web every user will have to log on through the web portal. In the 5 years of using Smoothwall I've not come across this, unless something od has happened or a site is in proxy bypass then a username has been logged. It also seems odd that Smoothwall is pushed in Education but it can't guarantee an audit trail for a pupils web traffic.

 

Those 407s shouldn't be leaving your network.

That's the Smoothie saying 'hold on, you're asking for x, but I don't know who you are or whether I should give it to you'.

The client should then supply the Smoothwall with the relevant information, cheked against Active Directory or similar depending on your setup, after which all the requests from that client for that session are authenticated and can be traced back to it.

 

If the client fails to provide valid credentials, it will end up in the Unauthenticated IPs group. This is just like any other group, and you can use it to block/allow categories as you wish. Most people use it as a catchall and keep it very restricted, or deny internet access entirely.

 

For me this means Smoothwall is next to useless as I can't produce a full audit on pupil's web activity in the event something happens, or to prevent something happening unless I make everyone log in via the portal which with small ones is a real hassle. I also don't understand how Smoothwall can be used as a proxy if it can only be used to identify users based on the server at the other end of a request allows Authentication, I would expect the majority of web servers to use anonymous access as they have no need to know user credentials. How does it know which group to assign someone or policies to apply?

 

So as I asked at the beginning, am I over reacting? Or am I off to Lightspeed?

 

I think there are some crossed wires here. Authentication is between the client and the Smoothwall. Nothing to do with the external server.

Have a look in Logs and reports » Reports » Reports » Users. If you feel there are any serious holes in your audit trail, we can take a closer look.

Correctly configured, a Smoothwall can provide a pretty comprehensive audit trail.

Edited April 2, 2014 by OB1

[TechMonkey]

Yes

 

Those 407s shouldn't be leaving your network.

That's the Smoothie saying 'hold on, you're asking for x, but I don't know who you are or whether I should give it to you'.

The client should then supply the Smoothwall with the relevant information, cheked against Active Directory or similar depending on your setup, after which all the requests from that client for that session are authenticated and can be traced back to it.

 

If the client fails to provide valid credentials, it will end up in the Unauthenticated IPs group. This is just like any other group, and you can use it to block/allow categories as you wish. Most people use it as a catchall and keep it very restricted, or deny internet access entirely.

 

I think there are some crossed wires here. Authentication is between the client and the Smoothwall. Nothing to do with the external server.

Have a look in Logs and reports » Reports » Reports » Users. If you feel there are any serious holes in your audit trail, we can take a closer look.

Correctly configured, a Smoothwall can provide a pretty comprehensive audit trail.

 

Right, thank you @OB1. This was my understanding but the explanation I posted is from the the Tech I spoke to moments before my post and the Tech I was dealing with on the original call thought lots of 407 entries were normal and not a config error. The Tech I spoke to categorically stated and confirmed when I reiterated back to him that without using SSL sign on you couldn't get a full audit trail while contacting remote websites that don't support NTLM or Kerberos. I asked if this was a new thing in one of the updates and he said that he had been there a year and it had always been like that. Now either there was a spectacular misunderstanding by me (which is possible), the tech didn't get my explanation and subsequent example (contacting the BBC) or something is greatly awry

My understanding previously was that Smoothwall could audit nigh on everything, hence why I've used you for 5 years+ and was very happy when I moved schools that Smoothwall was in place here.

 

What is my best route to resolve this?

[OB1]

PM me your ticket reference, I'll take a look.

[AMLinington]

 

 

 

Right, thank you @OB1. This was my understanding but the explanation I posted is from the the Tech I spoke to moments before my post and the Tech I was dealing with on the original call thought lots of 407 entries were normal and not a config error. The Tech I spoke to categorically stated and confirmed when I reiterated back to him that without using SSL sign on you couldn't get a full audit trail while contacting remote websites that don't support NTLM or Kerberos. I asked if this was a new thing in one of the updates and he said that he had been there a year and it had always been like that. Now either there was a spectacular misunderstanding by me (which is possible), the tech didn't get my explanation and subsequent example (contacting the BBC) or something is greatly awry

My understanding previously was that Smoothwall could audit nigh on everything, hence why I've used you for 5 years+ and was very happy when I moved schools that Smoothwall was in place here.

 

What is my best route to resolve this?

 

When using NTLM there are 3 stages to the request/handshake and each of these is shown in the logs. When the client makes a request to the Smoothwall for a site (the first 407) the Smoothwall says 'I need authentication', so the client responds with Authentication details (the second 407) then the Smoothwall authenticates via the directory and the request becomes authenticated.

 

So in any request you'll see a URL appear 3 times - twice as 407, once as 200.

 

Authen::NTLM::HTTP - search.cpan.org

 

If the site, client machine or software the client is using doesn't support providing the Smoothwall with Authentication credentials, then the Smoothwall receives nothing from the client machine that it can check via the AD. This is not a 'Smoothwall issue' per se but a limitation of the choice of NTLM. It is a known limitation - not everything supports this. The Smoothwall can only authenticate if the client is providing creds. In these instances you have to bypass authentication for those domains. Kerberos is generally pretty good and supported by most things EXCEPT java. Which is a pain. There isn't really anything we can do if a client isn't sending the Smoothwall anything to take to the AD. This is likely why our engineer recommended an alternative authentication method. This is a limitation of the Authentication type, not the Smoothwall.

[tom_newton]

OB's right - what you're seeing is actually an artefact of a change to our logging: we used to just not display 407s, because NTLM naturally generates a lot of them. now we do, because the logging system can handle the extra workload, and *because* of our commitment to safeguarding we want to be able to say "we log everything we can".

[TechMonkey]

Right. Thank you for explaining. That makes sense, and explains why I've not noticed it ever before, as it was brought in by the change in logging. I can kind of see what the Engineer was trying to say but failed to.

[AMLinington]

Right. Thank you for explaining. That makes sense, and explains why I've not noticed it ever before, as it was brought in by the change in logging. I can kind of see what the Engineer was trying to say but failed to.

 

NTLM is a tricksy thing and the whole handshake thing is complicated to get your head around. It's probably easier to explain it in text than it is verbally because you can lay it out logically. Either way, bottom line is that if you are using NTLM and seeing 407 entries in the logs, this is normal. You will have to bypass auth for some things - this is an inevitable result of using NTLM but most often the ease of use outweighs the hassle.

[Harlquinth]

Hi,

 

We're having similar problems with an increasingly (so it seems) number of websites coming up as unauthenticated, which means they get blocked as we don't allow unauthenticated websites through. Quite a few of the websites seem to be Microsoft websites, such as office helpfiles, clipart, etc - is there a particular reason why Microsoft sites seem to be more prone to this problem?

 

The most recent website we have had problems with is outlook.com/login.live.com, which seems to have become a problem since the updates that we did to our smoothwall box over halfterm last week (although this could perhaps be a coincidence).

 

Is there a way of setting up NTLM authentication so that it falls back to Kerberos if it can't authenticate, or is there something else that can help prevent this problem?

Particulary with things like webbased email on Microsoft websites, we need to be able to have an audit trail, as (for example) we have had cases in the past where a student has used web-based email services to send anonomous emails to staff.

 

Many thanks