[isf-wifidog] MAC Address Whitelisting and Blacklisting

Samuel Leathers disasm at gentux.org
Ven 21 Juil 01:00:29 EDT 2006


Looks like to do this, on the gateway router, line 151 in auth.c
we need some more return values for the auth_response.authcode, mainly
AUTH_WHITELIST and AUTH_BLACKLIST.

then in auth/index.php when it detects STAGE_LOGIN, it needs to check the
db if mac passed is on the whitelist or blacklist, and return
AUTH_WHITELIST or AUTH_BLACKLIST respectively.

Anyone agree/disagree with this?

If people agree on this, I'll write a patch for auth/index.php and
src/auth.c to enable this functionality. I haven't searched the db to see
if there is a table for whitelisted and blacklisted macs, so I'm not sure
if the sql code to setup the db will need to be altered.

Sorry for all the e-mails, just jumped the gun and kept digging,

Sam

> well, cat *.c|grep mac makes a huge difference, things are making a lot
> more sense:
>
>  snprintf(buf, (sizeof(buf) - 1), "GET
> %sauth/?stage=%s&ip=%s&mac=%s&token=%s&incoming=%llu&outgoing=%llu
> HTTP/1.0\r\n"
>         "User-Agent: WiFiDog %s\r\n"
>         "Host: %s\r\n"
>         "\r\n",
>         config_get_config()->auth_servers->authserv_path, request_type,
> ip, mac, token, incoming, outgoing,
>         VERSION,
>         config_get_config()->auth_servers->authserv_hostname
>     );
> centralserver.c starting at 86
>
> Does the above code block happen before the redirect is sent to the
> client? If so, well, this should be a lot easier than I thought it was,
> cause the mac is already being posted to the auth server, and before the
> redirect is thrown, a white/black list can be checked and either authorize
> or deny access before the login page shows to the user.
>
> Sam
>
>>
>> Hey all, I didn't run away ;-) just been reading docs and source code
>>>> 5) mac address blocking from auth server. This way a known abuser
>>>> can't
>> create a new user. maybe timed, so an abuse expires after a month.
>>>
>>> Not only should we add blocking by MAC, but we shall add
>>> whitelisting, because some devices that here plugged to our routers
>>> need
>> to access the Internet at all times (right now we manually
>>> configure each router). I'd recommend you start working on this
>>
>> I've been reading the code for the auth server and gateway, and I think
>> I'm starting to understand the auth process (also looked at the flow
>> diagram)
>>
>> In firewall.c I see a function called arp_get, which appears to
>> determine
>> what MAC belongs to what IP address. I haven't figured out if it already
>> does this for all incoming connections, and if so where it is being
>> called, but I think if this data is posted to the login page, right
>> after
>> the Start Login Process comment in login.php, a query to the database to
>> try to match the MAC to a white or black list could be done, if it's
>> white
>> listed, then:
>>
>> $token = $user->generateConnectionToken();
>> header("Location: http://" . $gw_address . ":" . $gw_port .
>> "/wifidog/auth?token=" . $token);
>>
>> should do the trick I think.
>>
>> if it's blacklisted, somehow we need to notify the router, so maybe
>> $token
>> = $user->generateFailedConnectionToken();
>> (function above would need written, and the the router would need to
>> know
>> what a failed token looks like, so it could call an iptables rule to
>> block
>> that mac.
>>
>> Then, else, continue on with the login process.
>>
>> I'd like to get some feedback before I try modifying things to make sure
>> I'm going the direction everyone wants out of this feature, and also to
>> make sure I understand how things are working currently.
>>
>> The other thing I think that may work is when the router detects an
>> incoming connection with a new ip address/mac it contacts the auth
>> server
>> to detect if it's white or blacklisted before redirecting, but I assume
>> this would create a little lag time before the redirection page showed
>> up.
>>
>> Also, when wifidog is started, it can contact the auth server and
>> retrieve
>> both lists, and setup the rules immediately, and then have it detect at
>> login as well.
>>
>> Sam
>> --
>> Sam Leathers
>> Sam Leathers Computer Services
>> 814.574.7307
>> sam at samleathers.com
>> www.samleathers.com
>>  -Computer repair services
>>  -Reliable business consulting
>>  -Web design and hosting that meets your needs
>>  -Collection of computers no longer needed
>>  -Student discounted repair rate
>>  -Server setups and networking
>> -------------------------------------
>>
>>
>>
>> --
>> Sam Leathers
>> Sam Leathers Computer Services
>> 814.574.7307
>> sam at samleathers.com
>> www.samleathers.com
>>  -Computer repair services
>>  -Reliable business consulting
>>  -Web design and hosting that meets your needs
>>  -Collection of computers no longer needed
>>  -Student discounted repair rate
>>  -Server setups and networking
>> -------------------------------------
>>
>> _______________________________________________
>> WiFiDog mailing list
>> WiFiDog at listes.ilesansfil.org
>> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>>
>
>
> --
> In life direction is everything, distance is secondary, so keep your
> bearings
>
> And he went into the Wilderness and prayed.
>
> I can do all things through Christ who strengthens me.
>
> _______________________________________________
> WiFiDog mailing list
> WiFiDog at listes.ilesansfil.org
> http://listes.ilesansfil.org/cgi-bin/mailman/listinfo/wifidog
>


-- 
In life direction is everything, distance is secondary, so keep your bearings

And he went into the Wilderness and prayed.

I can do all things through Christ who strengthens me.



Plus d'informations sur la liste de diffusion WiFiDog