Securing Captive Portal with OS fingerprinting

[cs1]

Hi all!

I would like to discuss something with you that crossed my mind: pfSense uses pf's OS detection in firewall rules. I'm thinking about adding to the security of a Captive Portal scenario by using OS fingerprinting. pfSense allows net access to the MAC and IP of a client who successfully logged in. My question is: wouldn't it make sense to add the OS (that has been detected by pf) to the pf rule as well that allows guest access? Any thoughts? It definitely isn't a solution that will prevent spoofing 100% but it very likely makes things much more difficult. Adding something like Ipguard would add even more security. The only question is what a good way would be to integrate pf's OS fingerprinting and Ipguard with the Captive Portal. Your thoughts are highly appreciated.

Cheers,
cs1

EDIT: Clarified some terms (OS fingerprinting is included in pf) and included mentioning of Ipguard.

[heper]

pf isn't used for Captive Portal itself, ipfw handles that.

what would be the point of using os-fingerprinting in addtion to the voucher/user/mac authentication scheme's? Why would you want to restrict a certain user to a specific OS ?

captive portal to authenticate on general purpose / free / "public' / networks. like in hotels/bars/cafe's/guest access in enterprises/…). I personally see no use i such a feature.

[sebastiannielsen]

no, he isn't out to restrict to a specific OS.

what he is out for, is, when a client authenticate correctly, the client's MAC, OS-fingerprint, and IP is saved in the firewall rule.
So the OS-fingerprint must match whatever the user authenticated with, to prevent spoofing.

[cmb]

There are no pf rules added for captive portal users and ipfw has no OS fingerprinting.

[cs1]

@sebastiannielsen:

no, he isn't out to restrict to a specific OS.

what he is out for, is, when a client authenticate correctly, the client's MAC, OS-fingerprint, and IP is saved in the firewall rule.
So the OS-fingerprint must match whatever the user authenticated with, to prevent spoofing.

Yes, that's precisely what I'm looking for. I wasn't aware that pf wasn't used for the Captive Portal. However, since pf is still available for filtering, I was thinking about something like this:

• Create a pf rule that logs the OS fingerprints of clients.

• After a successful login of a user, create a pf rule for the IP that the user got that only allows TCP traffic with the OS fingerprint that has been detected during login.

• After either a voluntary logout by the user herself or after the soft / hard timeout, remove the pf rule for the user's IP.

This should add one more layer of security. Sure, it's not foolproof but certainly would add one more hurdle to abuse.