RaDius

TableOfContents
Category:Sasecurity
 * NoCatsplashpage
 * RadiusAndWiana
=== Login script ===
=== Notes 1 ===
{{{
<pre>
I can report I have tried the "nocatsplash" based login and the attempts are indeed logged as you say. I guess they are emailed once a week? Is it always the same day/time? I guess I will have to wait to validate 
this... 
1. After getandverify tobuild25dev103 I lost my additional software 
modules. I had go to Wiana and "update" the software modules to get them back. 
Not really sure if there is any reason it has to work this way? It would 
be great if the software modules could reload themselves automatically 
after a software upgrade.
2. VPN login attempts are not logged, so the login logs only tell half 
the story! It would be nice to log ALL login attempts - including VPN 
ones. In the meantime, does anyone know any cunning work-arounds/scripts etc. 
to log VPN login attempts?
3. I guess you already know that the new Wiana "Record login attempts" 
menus are not present in the local admin module.
Another useful feature (either locally or on Wiana) would be to list 
peoples IP addresses along with their last used date/time (and MAC address). 
This way it would be easy to see the IPs that are still being used (vs the 
ones that have been used recently but are currently unused). It would also 
help security by showing a time-related view of repeated or related MAC 
address activity, which is currently not easy to see.
This latest development build includes radius failover and the ability 
to record login attempts to text files and to receive these via email.
To upgrade to this release simply login to your MeshAP via ssh and 
issue the following command:
getandverify tobuild25dev103
The radius failover just means that if one of the wiana radius servers 
is unreachable it will use an alternate one.
For info about the recording of login attempts I've included the wiki 
pag http://locustworld.com/tracker/wiki?p=RecordingLoginAttempts
There are several ways that this can be achieved. You can select which 
type of logins are recorded (valid logins, invalid logins or both). Logs can be 
kept in memory or stored on the local flash storage if you have more than 32MB of
flash installed. The system will store login logs for the previous week and can be configured to email copies of these logs to a designated email address. Configuration instructions are detailed below:
The first step to recording login attempts is to decide which login attempts you wish to record. 
Manage the node concerned and expand the "Splash Page Customization" menu. 
Locate the option "Record login attempts" and 
select either "All" or "Valid" or "Invalid" which will log the various type of
login attempts.
Valid will only record correct authentications and Invalid will only record failed/incorrect login attempts.
Selecting "All" will record both valid and invalid logins.
By default the logs are stored in memory on the /tmp directory. The files will
appear as "loginattempts-Mon.txt" in this directory. "Mon" will be replaced by the current day of the week and 7 days will be stored with the files being overwritten the following week.
The /tmp drive is erased during reboot and so if you want a more 
permanent record of login attempts, utilizing the flash storage is recommended. 
If your MeshAP compact flash or disk on module is bigger than 32MB then the 
MeshAP will automatically partition the additional space and mount this 
storage on the path /drv2
The configuration option "Logfile path" specifies where to store these 
logs, if you have a /drv2 directory (check by logging in to the node and 
issuing the "df" command) then this would be the recommended place to store the
logfiles on the flash.
You can also specify an additional subdirectory, for example "/drv2/logins" and the system will automatically create this subdirectory and place the log files there. If you don't have a /drv2 partition and your flash storage is only 
32MB, then you can store the logs on the master drive by specifying a path along the lines of "/logins" - Please note however that this is not recommended and if your log files fill up your master partition it is likely to crash the
MeshAP. You have been warned! To receive email copies of your logs, complete the "Email logs to address"
field with the email address where you wish the logs to be delivered. You also need to specify a mail server to use, this setting needs to be carefully chosen, there are several ways this can be done: 
1) Via "sendmail" relay on the local node: Select the "sendmail local relay" option in the software module manager 
for the node you are recording login attempts on. This will install a sendmail mail server which can only be accessed via the internal address of 127.0.0.1 - With this software module in place, set the "Email logs via server"
address to 127.0.0.1 - Whenever the node needs to email the logs to you, they will
be sent to the local server which will then determine how to deliver the email and keep trying until it gets through. A sendmail relay on every node you're recording logs on simply for the purposes of relaying those logs could 
be considered overkill of course.
2) Via a LAN hosted open relay: If at the gateway end of your mesh you have a LAN with an "open mail relay" present, and this mail server will accept connections coming from the gateway meshbox and then relay mail to your destination email address. In this case you set the "Email logs via server" option to the LAN IP address of 
this open relay. Make sure that the LAN IP range doesn't conflict with your 
remote nodes by setting the "Ethernet local range" parameter to a different 
subnet than your gateway side LAN subnet. The MeshAP can't do SMTP-auth/secure 
SMTP or any other type of SMTP authentication so this really needs to be a 
relay which will relay mail from the IP address of the gateway meshbox.
3) Direct to the destination mail server:
Using this method the email is not relayed but delivered directly to a 
mail server which services the domain hosting your destination email 
address. This avoids any need for a mail relay but requires determining a server 
address to use and being careful to ensure that the settings are updated if the 
email server changes. To explain how to set this up an example is included.
If you were sending logs to an address such as example.address@yahoo.com
then you need to know one of yahoo.com's email servers that will accept mail 
for this address. This information can be determined from the DNS system 
and some helpful internet citizens maintain webpages which can do this for you.
http://www.davidj.org/tools/whatmx.php
At the time of writing, this page allows you to look up the "Mail Exchanger"
records for a domain. Entering "yahoo.com" and clicking "MX Lookup" gives
the following results:
yahoo.com preference = 5, mail exchanger = mx4.mail.yahoo.com
yahoo.com preference = 1, mail exchanger = mx1.mail.yahoo.com
yahoo.com preference = 1, mail exchanger = mx2.mail.yahoo.com
yahoo.com preference = 1, mail exchanger = mx3.mail.yahoo.com
The lower preference servers are the "preferred" servers and so a good
choice in this example would be "mx1.mail.yahoo.com" - Entering this into the
"Email logs via server" field would allow the MeshAP to send logs to any 
@yahoo.com email address. Don't try to send email to non-yahoo addresses using 
yahoo's servers or you'll likely get yourself blocked as a suspected spammer.
Obviously replace "yahoo.com" in this example with whatever domain name 
you would like to receive the log emails to and of course using the dns 
records as described above to select an appropriate mail server.
General notes on the log format: The log files (and associated emails) contain details of the login 
attempts. These consist of 5 comma delimited fields as follows: The date and time of the login attempt The username concerned The password entered The remote MAC address of the client Whether the login was successful
indicated by either a Y or N 
General notes on security:
If you have the option selected to send you either All attempted logins or Valid attempted logins and you also are receiving copies of the logs via email, then you need to remember that the emails you are receiving contain active passwords for your mesh. You should take care to ensure these emails remain private to avoid any potential for passwords being misused.
}}}
=== Setting up users on a Radius server ===
=== Free radius ===
=== no cat ===
The documentation is on the NoCatSplash site. 
And I sure wouldn't use Winduhs for this.
I have a client that is starting out with a mesh system but wants to 
use their own radius server. Currently they are using the radius that 
comes with windows 2000 server. When we try to do cwradius user pwd we get 
the following response immediately:
rad_decode: Received Access-Reject packet from 192.168.1.4 with 
invalid signature!
According to the 2000 server log, the meshbox is looking for a 
digital certificate. Is this correct. We are running qcode on this box. I 
added the address of the radius in usr/local/etc/raddb/client/servers along 
with the secret and still get the same response above.
=== Radius and Wiana ===
Yep, that was it. radius only local was set to no.
> At 07:10 -0500 6/3/06, clark wrote:
>>I replaced a gateway AP over the weekend. This is the first time I 
have >>had a radius server failure. The relay nodes perform user 
authentication >>correctly, but my new gateway node will only authenticate 
owner/owner. 
>>Users in the realm cannot use their given username/password. The 
wiana >>settings look correct: Radius local prefix is the same number that is 
in >>the parenthesis. Lock to realm prefix is correct. When I do a 
radping it >>returns DOWN. But this is also what is returned when I do a radping 
from >>the relay nodes which authenticate users correclty. I can do a 
cwradius >>with usernames and passwords from the relay nodes and it returns OK. 
But >>from the gateway node it returns denied for everyone except 
owner/owner. If owner/owner is working, then the "radius only local" parameter is 
not set to yes. If it appears to be set to yes in wiana, check the 
equivalent parameter in /etc/wiana.settings - it is possible that the settings 
failed the check when they downloaded, and so are out of sync with wiana.
=== Trouble Shooting Radius ===
 UserName| Attribute | op | Value
1 | tjohnson | password | == | MACAddress
2) Make sure that you have enabled the PAM module that your NAS is 
using 
by uncommenting it in the radiusd.conf file.
3) Start radiusd with very verbose output so you can see more info 
about 
the login failure. That will tell you the true tale. I don't remember 
the command line switch right off hand for that.
>I reset to Capture on, and now I am getting invalid login. Here's the
>output from my log file:
>
>Wed May 26 08:10:32 2004: Info: Ready to process requests.
>Wed May 26 08:12:01 2004: Auth: Login incorrect: 
[QX:2220::tjohnson/xxxxxxx]
>(from nas 255.255.255.255/S0)
>Wed May 26 08:12:01 2004: Auth: Login incorrect:
>[QX:2220::tjohnson/0e044db5a4d5ada2] (from nas 255.255.255.255/S0)
>Wed May 26 08:12:02 2004: Auth: Login incorrect:
>[QX:2220:bogus:tjohnson/xxxxxxx] (from nas 255.255.255.255/S0)
>
>I'm not sure I have my users file set correctly. I've only used 
radius with
>Lucent AP's, and all authorization was MAC based.
>>Sure,
>>I had thought about it once I'd finished my accounting setup, but I
>>suppose I could upload the simple setup first.
>>
>>There is already one document that is pretty informative here:
>>http://www.locustworld.com/tracker/wiki?p=UsingOwnRadius
>>
>>For the question about the hardcoded "testing" secret, just change it 
in
>>/hj/cwradius2 (I think).
>>Any chance on putting a document together on your free radius setup ?
>>i.e free radius + config + wiana changes that could be uploaded to 
the
>>wiki for people to be able to configure their own free radius 
servers.
>>make sure you are using wiana based splash, and you should be all 
set.
>>I'm running the same build with freeradius. -----Original 
>>Thanks to Joel Smith for suggesting I move to build25dev85. I now 
have
>>3 meshed nodes. One last thing I need to figure out, how do I send
>>authentication through my radius server? Right now it is letting 
anyone
>>in. I have it set for Auth Only, but I don't see anything in my 
radius
>>log file for authentication.
>>
>>Thanks to all for the help!
Make sure you have choosen realms from wiana and node has downloaded 
changes. and make sure again that said MAC address downloaded into the 
mesh node allready. If your customer still cannot logon then check if 
you 
have choosen username + password OR MAC authentication. If you have 
choosen AND option, then your router need extra port settings for 
radius. 
(Dont remember which ports but you can find in wiki too)
Customers gets IP leased because splash page faces them first so node 
has 
to hand out IP anyhow.
We are using MAC only authentication with no problem on 20 node mesh 
with 
allmost 300 users. single problem we had similar to your was that we 
forgot adding realms to a node which that customer tried to connect.
hope this helps.
> i STILL have login issues on a fairly regular basis and often enough 
> for some of my customers to tell me they want to pay twice as much 
for 
> satilite dsl than to keep my service when my speed is always 3+ times 
as 
> fast.
> it seems if i dont put the mac in the realm its a no go most of the 
> time. i dont mind putting the mac address in but sometimes i dont 
get 
> the chance like today when a customer who just purchased a brand new 
> computer called me and said and i quote " Come get your shit off my 
> property I dont want your so called service anymore"... he couldnt 
log 
> in but had been been given a dhcp lease. All my signal levels between 
> nodes and clients are as good or better than anyones.
> i searched the wiki and found this
> """'cwradius <username> <password>' will test the Radius 
authentication 
> """"""
> the 3 user names and passwords are fake but the ones actually used 
were 
> real and are in the realm that the node is locked to
> they were copy and pasted from my realm manager to prevent a typo
> this is what was returned
>
> 1.208.98.142@meshbox:~# iptables -L | grep MAC
> ACCEPT all -- anywhere anywhere MAC 
> 00:60:08:37:9B:A3
> ACCEPT all -- anywhere anywhere MAC 
> 00:0E:7F:B6:4A:75
> ACCEPT all -- anywhere anywhere MAC 
> 00:AA:00:BC:44:28
> ACCEPT all -- anywhere anywhere MAC 
> 00:0B:DB:1D:17:D6
> ACCEPT all -- anywhere anywhere MAC 
> 00:04:5A:7B:64:8A
> ACCEPT all -- anywhere anywhere MAC 
> 00:02:A5:2D:35:9D
> ACCEPT all -- anywhere anywhere MAC 
> 00:60:97:DC:6D:09
> ACCEPT all -- anywhere anywhere MAC 
> 00:08:54:13:E6:8E
> 1.208.98.142@meshbox:~# cwradius stupid1 stupid1
> DENIED
> DENIED
> radclient: no response from server
> No reply
> 1.208.98.142@meshbox:~# ping signon.communitywireless.org
> PING signon.communitywireless.org (213.219.19.76): 56 data bytes
> 64 bytes from 213.219.19.76: icmp_seq=0 ttl=238 time=142.981 ms
> 64 bytes from 213.219.19.76: icmp_seq=1 ttl=238 time=140.414 ms
> 64 bytes from 213.219.19.76: icmp_seq=2 ttl=238 time=150.397 ms
> 64 bytes from 213.219.19.76: icmp_seq=3 ttl=238 time=140.420 ms
> 64 bytes from 213.219.19.76: icmp_seq=4 ttl=238 time=150.417 ms
> 64 bytes from 213.219.19.76: icmp_seq=5 ttl=238 time=140.402 ms
> 64 bytes from 213.219.19.76: icmp_seq=6 ttl=238 time=140.273 ms
> 64 bytes from 213.219.19.76: icmp_seq=7 ttl=238 time=150.430 ms
> 64 bytes from 213.219.19.76: icmp_seq=8 ttl=238 time=140.931 ms
> 64 bytes from 213.219.19.76: icmp_seq=9 ttl=238 time=140.919 ms
> 64 bytes from 213.219.19.76: icmp_seq=10 ttl=238 time=140.911 ms
> 64 bytes from 213.219.19.76: icmp_seq=11 ttl=238 time=140.267 ms
> 64 bytes from 213.219.19.76: icmp_seq=12 ttl=238 time=150.404 ms
> 64 bytes from 213.219.19.76: icmp_seq=13 ttl=238 time=150.268 ms
> 64 bytes from 213.219.19.76: icmp_seq=14 ttl=238 time=150.274 ms
> 64 bytes from 213.219.19.76: icmp_seq=15 ttl=238 time=150.258 ms
> ^C64 bytes from 213.219.19.76: icmp_seq=16 ttl=238 time=140.252 ms
> 64 bytes from 213.219.19.76: icmp_seq=17 ttl=238 time=150.253 ms
> 64 bytes from 213.219.19.76: icmp_seq=18 ttl=238 time=150.269 ms
> 64 bytes from 213.219.19.76: icmp_seq=19 ttl=238 time=140.227 ms
> --- signon.communitywireless.org ping statistics ---
> 20 packets transmitted, 20 packets received, 0% packet loss
> round-trip min/avg/max/stddev = 140.227/145.048/150.430/4.811 ms
> 1.208.98.142@meshbox:~# cwradius stupid 1234567
> radclient: no response from server
> No reply
> 1.208.98.142@meshbox:~# cat /etc/wiana.settings | grep REALM
> RADIUSREALMPREFIX2:bogus
> RADIUSREALMPREFIX:OHMROGER
> 1.208.98.142@meshbox:~# cwradius thad happy
> radclient: no response from server
> No reply
> 1.208.98.142@meshbox:~# cat /etc/wiana.settings | grep REALM
> RADIUSREALMPREFIX2:bogus
> RADIUSREALMPREFIX:OHMROGER
> 1.208.98.142@meshbox:~# cwradius stupid 1234567
> DENIED
> DENIED
> DENIED
> 1.208.98.142@meshbox:~#
>
> INSTALLING 3 customers and uninstalling one... at least i wont run 
out 
> of customer equipment as fast
> the login issue has been ongoing since the first week the origional 
two 
> meshaps was deployed and has remained a prob as more nodes were 
> deployed thats been several months.. it seems to come and go for no 
> apparent reason.
========
[:Online management system]
[:Trouble shooting]