MAC/IP spoofing protection like in Zerotruth (Zeroshell CP)



  • Hi all,

    I've seen that the topic of MAC or IP spoofing has been addressed plenty of times with respect to the captive portal and most of the time, the result was: "you can't do anything against MAC/IP spoofing". However, there seems to be an elegant solution included in Zerotruth (CP on top of Zeroshell) that significantly reduces the risk of MAC or IP spoofing by using a technique that the Zerotruth guys call "Authenticator packet". When logging in on a captive portal (which should be secure via SSL), you get a popup window that needs to stay open on the client and it regularly sends an AES256 "token" of some sorts to the captive portal that is only known to the client that originally logged in and to the captive portal. An attacker that spoofs the original client's MAC or IP can't know of the token and hence won't be able to send it to the captive portal. This means that an attacker is logged out automatically.

    On the Zeroshell page there's a nice explanation of this feature:http://www.zeroshell.org/hotspot-router/#spoofing. A good resource is also the documentation on the download page of Zerotruth: http://zerotruth.net/downloade.php.

    Unfortunately I'm not much of a coder so my question would be directed towards anyone who knows the captive portal code in pfSense: do you think it would be feasible to include such a feature in pfSense's captive portal? I don't think that it makes sense to port the Zerotruth feature 1:1 but maybe a simple PHP session token or something similar might already do the same job. It sounds like a very useful and effective feature. I searched the forum but I'm not aware that this method has been discussed before. Looking forward to your opinions. Thanks for your input!



  • Interesting.

    But even before thinking about coding, think about this : what if the client instructed his 'client' (the web navigator he is using) NOT to open any pop-ups from unknown sources (like our captive portal) ?

    Coding a captive portal that makes assumption on some settings that could be different for every other visitor, that a support-nightmare.



  • In agree with you in general. However, for our old captive portal solution we needed JavaScript (which usually isn't enabled in security enthusiasts' browsers) and have positive experiences with printing the minimum requirement of enabling JavaScript at least for the CP onto the voucher handouts. We think that we can do the same with instructions to enter an exception for popups into the browser's preferences for the CP. (As a footnote: putting checks on the login page that check for JavaScript and disabled popup windows is not that difficult to do and you could easily inform users about the requirements "in place" and only present login buttons when both requirements are met.) The security gain is significant and the solution that is present in the Zerotruth CP is very refreshing. :) It's a very elegant solution to a very well known problem.

    I'd be interested in opinions by you CP devs – do you see a chance to put something like a session token onto the logout button page?



  • @cs1:

    …. do you see a chance to put something like a session token onto the logout button page?

    Well ….. the default logout-"popup"-page  has this line:

    	.....
    	LogoutWin.document.write('');
    

    …..
    The $sessionid is a unique, session specific value.



  • @Gertjan:

    The $sessionid is a unique, session specific value.

    Interesting! So what we need is basically a "Dead man's switch", that is, some mechanism that would demand regular automatic POST commands from the popup page that include the session ID and that would kill the session if the post command doesn't contain the correct session ID. Are there any source code docs on this logout page (except for the source code in the GIT repository) or the CP mechanism itself?



  • @cs1:

    …. Are there any source code docs on this logout page (except for the source code in the GIT repository) or the CP mechanism itself?

    It all starts in /usr/local/captiveportal and this file /etc/inc/captiveportal.inc
    Then its you coding it all up.



  • Ok, I'll try to have a look at it. Thanks for pointing me to theses "entry points". :)



  • @cs1:

    I've seen that the topic of MAC or IP spoofing has been addressed plenty of times with respect to the captive portal and most of the time, the result was: "you can't do anything against MAC/IP spoofing". However, there seems to be an elegant solution included in Zerotruth (CP on top of Zeroshell) that significantly reduces the risk of MAC or IP spoofing by using a technique that the Zerotruth guys call "Authenticator packet".

    You can't do anything (good at least) at the firewall level. That Zerotruth hack is ugly and only prevents hijacking sessions that aren't currently connected, which isn't all that useful. You're not going to stop someone good enough to hijack sessions (unless it gets down to 0 active sessions), and there's a good chance you'll introduce problems for legit users. Your APs and switches are where you can prevent that type of thing in a useful way (where the equipment has such functionality).