Features

FIXME

Net::LanWarden is really just in it's-self a friendly and flexible Perl module that expects a number of services configured in a specific manner so that you can write your own code easily enough to do more exotic tasks.

link neutral policing

Whether users connect wirelessly or wired (and in theory this could apply to VPN systems) the system treats everyone the same. For example, if you treat wireless users as if they are a less secure entity then there is something fundementally wrong with your network that should be addressed. Treating laptop users differently to workstations is fine as their usage profile is different (taking to potentially hostile networks in the case of laptops), this would be a VLAN based decision.

As long as that access layer support 802.1X (and VLAN assignment by RADIUS) it can be used with Net::LanWarden.

seperation of host and user based authentication

User authentication is something that is used to gain access to applications, email, network shares and secure websites. If the host connecting does not have it's own authentication

If no registration method is registered then the user credentials can be used to get the machine online

eduroam, federation user access

If you provide access for federation users, such as eduroam, then this is is great for you. Although you are not permitted to invade the privacy of these users (aka, identify them) you expect them to agree to some term's and conditions and be able to disable their MAC address. Abuse reports you then pass up to this home organisation.

802.1X support

A bit of a 'duh', as this system only supports 802.1X. You cannot use non-802.1X enabled access layer. Note that this does not mean you cannot connect non-802.1X aware workstations such as printers. The limitation is that your access layer must be able to generate an 802.1X packet where the MAC address is used for AAA instead.

For user based authentication EAP-TTLS (although reconfiguring FreeRADIUS to use PEAP could be done) is used when host based authentication it not available. At some stage I will get around to adding EAP-TLS host based authentication to the mix however it's MAC based authentication for now (can only be enabled by adminstrative users).

snmp

Uses SNMP to speak to the access layer. The switch/AP is on the fly identified and given commands. Such as 'shutdown the port for ten seconds and re-enable', or 're-initialise the 802.1X state machine for a particular port'.

handle abuse issues

As you are using 802.1X throughout your network, by using the DHCP data you can associate IP addresses to users and particular workstations easily. You can query the SQL database and find out usage patterns and what not.

Another advantage is that you can use this data to purge 'stall' data and also get SQL SELECT access to the data so that your asset tracking people can work out where the 'lost' leased workstations have gotten to on the network.

stateless

Where ever possible everything is kept stateless. This means that if something like a power cut occurs you do not spend the rest of the week repairing a complicated system that has fallen out of sync with it's self

opensource servers used

Regular run of the mill opensource software projects are used to provision FreeRADIUS, OpenLDAP, ISC DHCP, ISC BIND9, either MySQL or PostgreSQL, etc.

any Perl monkey can use it

If you know Perl and want some system of yours (for example) such as an IDS to disable a particular workstation, you can do so with just 'use Net::LanWarden'.

all data is stored in LDAP

With the exception of the logs generated by FreeRADIUS (authentication, authorisation and accounting details), everything is stored in LDAP. Host registration, DDNS, DHCP, VLAN membership, historical notes, etc are all there. This makes backups (LDIF dumps) dead easy and of course the data is easy to read from other systems if need be

whole of DHCP in LDAP

Everything regarding DHCP is stored in an LDAP database. This means you get to instant host registeration and changes are made live without the need to restart any services or rebuild any databases

dynamic IP addressing the rule of thumb

Static IP addresses need to be assigned to official servers and that's it. No workstation really needs a static IP, but it might need a static method to be able to access the host. Mobile IP is typically not available (and the correct solution) so we turn to DDNS instead

The advantages of this, a very flexible network that can grow boundlessly and will not involve awkard IP re-addressing. In addition you will find firewalling actually becomes easier as all those people expecting special IP based holes poked in a firewall or access list find themselves moving to IPsec in transport mode. Now the administrator's of those servers get to decide who uses their servers without needing the firewall administrator to get involved.

live DNS host tracking

Users can register their own DNS record that can follow the host on the network (uses all that DDNS] in the background)

agentless

Agent based solutions are Evil(TM). A solution based on getting trusted information from an untrusted source is asking for trouble no matter which way you look at it. Net::LanWarden makes decisions such as DNS amendments, VLAN and what-not.

Of course being agentless places no dependencies on the client (so Apple Mac weenies can quit their whining) and prevents the usual punishing of the Clued(TM). For example those that run 'unsupported' or do not need to run anti-virus software can connect to the network. In the commericial solutions you can opt that Linux or Apple Mac folk do not need this agent...this just drives home the point how pointless these agents actually are; of course there is NACATTACK to consider too..ho hum :)

security through accountability

MAC addresses are considered unique and are used as the identifier for that host. This might be considered a bad idea however every host connecting has to be

automatic deletation of 'orphaned' hosts

If the host has no valid user (the user has been deleted) then the host is deleted. The worst scenerio from this is the machine will need re-registration, which needs to be done anyway.

self-service

Where ever possible, sysadmin administration is offloaded to the users of the network. You can decide how many hosts a particular user is able to register. This pretty much makes MAC spoofing a pointless affair, especially as each spoofed address used is registered against the user's credentials

For members of the organisation, you can use user based authentication to register a host. Depending on the LDAP group membership of the user, the user will be able to decide how the host authenticates its-self to the network. By default all the user can do is register themselves as responsible for the host and then a user's credentials have to be used for the host to connect; not necessary the person who registered the machine

Form's, details, and self cleaning services can be dealt with by the user (or helpdesk) and the sysadmin will only need to be called upon in the extreme cases of luser-dom.