FANDOM


TableOfContents

* NoCatsplashpage
* RadiusAndWiana

Login script Edit

{{{

=================================
#echo "$*" >>/tmp/cw.log
prefix="/usr/local"
exec_prefix="${prefix}"
bindir="/hj"


Just remove the # from the first line
Then if you want the date just add it in, like so

echo "`date` $*" >>/tmp/cw.log
prefix="/usr/local"
exec_prefix="${prefix}"
bindir="/hj"

And now you have /tmp/cw.log logging just like it is supposed to, with
the additional date field

modified the cwradius1 script to log all logins to a file.

#echo "$*" >>/tmp/cw.log
prefix="/usr/local"
exec_prefix="${prefix}"
bindir="/hj"
!!!!!!!
date=`date`
echo $date >>/drv2/logins
echo "username:-$1,  Password:-$2,  MAC:-$3 " >>/drv2/logins !!!!!!!
usage() {
 echo "Usage: radtest user passwd radius-server[:port] nas-port-number
secret [ppphint] [nasname]" >&2  exit 100 }

the bit that I added in in-between the !!!!!!!!, don't include the
!!!!!!!!

This writes all logins to a file called logins into the drv2 folder.
From this you can see exactly who has logged in with username,password
and MAC address. Once you have found what username is being used change the settings in
your realm for that user to username password and Mac Address using the
Mac address of the correct user.. That will stop them but if the 
correct user changes their wifi card then you will have to change the Mac
address.

Any one out there know if there is a way of telling what mac address
logged on with what username and password. Not talking about wiana. We are
talking  within the mesh box. 
I.e  you have a unknown mac address that is passing a lot of traffic, 
but you do not know that mac address! its not one of your registered 
customers (hacker or some sharing there user name)is there a way of 
showing the username and password that it logged in with.

}}}


=== 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 Edit

{{{

>Setting up users on a Radius server, Wiana settings: 
 In Wiana I've now got:<BR>
> 1. captive portal  =  on<BR>
> 2. portal mode = both auth and open<BR>
> 3. Radius only local: Yes<BR>
> 4. Radius local prefix (x) = x (i.e. matching what Wiana says)<BR>
> 5. Lock to realm prefix: XYZ<BR>
> 6. accounts setup in realm manager to realm "XYZ" with a "class" of<BR>
> member<BR>
> I am currently authenticating userA with MAC addr OR pwd pair<BR>
> I am currently authenticating userB with MAC addr AND pwd pair<BR>
> Running...<BR>
> #cwradius userA passwd<BR>
> I get<BR>
> "OK"<BR>
<BR>
> #cwradius userB passwd<BR>
> I get<BR>
> "DENIED"<BR>
> "DENIED"<BR>
> "DENIED"<BR>
> So it seems that if you turn on MAC addr & pwd pair in Wiana<BR>
> the cwradius test fails (I guess since that 'local' test doesn't<BR>
> present the right MAC addr to signon.communitywireless.org<BR>
> radius server, right?)<BR>

> Also...<BR>

> #iptables -L | grep MAC<BR>
> gives nothing... why?  I this only the current<BR>

> #cat /etc/wiana.settings | grep REALM<BR>
> RADIUSREALMPREFIX2:bogus<BR>
> RADIUSREALMPREFIX:XYZ<BR>
<BR>
> #ping signon.communitywireless.org<BR>
> is fine (I like to know the syntax to do a specific port on port
> 10443 or 1812 though...)<BR>
> If anyone spots anything wrong with this please let us know as<BR>
> a complete explanation of these settings could be handy to me/
> others... <br>
<BR>
ANSW: <BR>
Only thing seems to me is that MAC addresses should have been 
downloaded locally. Sometime when you made changes to realm, somehow it does not 
download changes to local node(s). Update realm (by just editing or adding a 
user) and then force nodes to remotemanagement and make sure MACs are downloaded
afterwards.

}}}


Free radius Edit

{{{

Got it working with free radius Heres what I do  Setting up external RADIUS 
Commandline Side
1. cd /etc/radiusclient
2. vi servers
3. add RADIUS_IP SECRET
4. save
5. vi radiusclient.conf.master
6. goto /authserver
7. add RADIUS_IP PORT
Wiana Side
1. disable local radius in wiana
2. add external radius IP
3. Make sure Capture is on.

>I need to turn mac address auth. off. I have set up a
>relm and added the user name and password but it will
>not let me on.
Are you getting to the splash screen, or are you being authenticated 
straight through? If you are getting to the splash screen, are you 
able to authenticate as owner/owner? If this is the case, then you 
need to set the Radius only local: to yes. Also check out 
[http://www.locustworld.com/tracker/wiki?p=CantAuthenticate]

}}}

no cat Edit

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 Edit

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 Edit

UserName


[:Online management system]

[:Trouble shooting]