IP-login2 - access control daemon
IP-login2 is a client monitor for network login systems. It handles access control for individual users in a network, and will keep track of them until they stop responding to probes, at which time their network access is removed to force them to login the next time they connect.
iplogin2 can provide users with user-specific access in conference rooms and the like, by using a special authenticating server that can tell iplogin2 which access filters to open for each user.
Typically, iptables chains are set up to redirect all HTTP accesses for non logged in to a login page, on which a login system will be used to authenticate the user and then authorize them to use the network by telling iplogin2 to grant them access.
iplogin2 then keeps probing each user with either ARP ping or ICMP ping until it stops responding.
The system is built to scale very well, and has been running for many years in a few large-scale environments, handling up to around a thousand of users on a single server.
You will be able to glean some information from the manual page reproduced below. Beyond that download the package and read the rest of the manpages, the README file etc. You need the source code for iptables to compile this - refer to README for more information.
For developers looking for bizarre solutions, I built in a strange cooperative multithreading mechanism into this, because I didn't want to handle concurrency and locking issues, and didn't want to force the user to install a pthreads library on the servers. Whether this was a good design or a bad one is open for debate, but if you're curious, the major part of this code is located in engine.c. iplogin2 also uses a non-prefix-matching version of the "lc-trie" data structure as used for the Linux kernel's routing table.
iplogin2 - client monitor for network login systems
DESCRIPTIONiplogin2 is a daemon that monitors network users' access to the Internet in a controlled environment, such as a commercial broadband service or a conference room.
Logging in, logging out and any manual/automatic administration is made through an encrypted TCP connection directly to the iplogin2 daemon, using a set of commands defined by the server.
The monitoring is achieved using either ICMP ping (for non-local clients) or ARP ping (for clients on logically connected networks). When a client has been nonresponsive for a specified time, it will be logged out automatically.
iplogin2 will re-read its configuration file withing ten seconds, if it detects that the file has been modified. Changes in the configuration file will generally not affect already logged in users, with the exception of the probe timing parameters.
- -c conffile
- is the configuration file, containing numerous parameters controlling the behaviour of iplogin2 and the access of administrative clients to the daemon.
- -s servername
- is the name of the server process (defined in conffile) that the program should run as.
- -l statefile
- is a file from which iplogin2 will load its state, and to which iplogin2 can also be configured to auto-save its state periodically. This option overrides the loadfile attribute in the configuration file.
- -p pidfile
- specifies a fully qualified path name to a file used for storing the process ID of this iplogin2 process. This option overrides the pidfile attribute in the configuration file.
- This option will cause iplogin2 to print out its version number and exit.
- [-t] [-v] address account [chain [,...]]
Add a new client with IP address address, account name account (for informational purposes), and a list of netfilter chains to add the client to. -v will cause iplogin2 to report back some status to the caller, including the ping source address and a few flags. -t will cause iplogin2 to initiate tracing of this client upon login.
- addblock address chain[,...]
- Add tcp block (DENY rule) for address address to iptables chain chain.
- check address
Check whether the client with address addressis logged in.
- checkuser account
Check whether the client with account account is logged in.
Count logged-in clients.
- del address
Delete (log out) the client with the address address.
- delblock address chain[,...]
Delete tcp block for address address from iptables chain chain.
- deluser user
Delete (log out) the client with the account name user.
Show information on all logged-in clients.
Dump the usernode LPC-trie (debug).
Print the list of commands.
List all clients on short form.
Load state from file filename.
Stop the daemon.
- [-r] [-R] [-l]
Reload all iptables chains. -r will cause iplogin2 to reset traffic counters for all users at the same time. -R will cause iplogin2 to set the login time to the current time for all users. -l will cause reload to return a short-form list of logged-in users and their stats, before resetting the stats.
Reset state - log out all clients. Also flushes any iptables chains that have been created by iplogin2
Get RSS (debug).
- savestate filename
Save state to file filename.
- stat address
Get stats for the client with the address address.
- traceuser user [-s ]
Start trace for the client with the address or account user or stop it with -s
- [-a] filename
Dump traffic stats to the file filename. -a will cause iplogin2 to include the account names as the first column.
Get vsize (debug).
CHAIN SPECIFICATIONSnetfilter filter chain specifications are used both when logging in users and when specifying a blocking chain in the configuration file.
The format of these specifications is as follows:
where "s", "d" and "b" denotes "source", "destination" and "both", respectively.
The default values are table="filter", direction="s" and target="ACCEPT".
IDLE LOGOUTiplogin2 can be configured to logout idle users automatically. This depends on several things being set up correctly.
There must be an iptables chain where the users that are monitored for this feature are present. This chain must be set up in the netfilter subsystem so that the rx and tx counters will reflect the type of traffic that is considered relevant from and "idle timeout" standpoint. In the normal case, the standard "users" chain used by iplogin2 may already serve this purpose.
You may want to make sure that this chain is used as "bidirectional", i.e. users are logged with "users/b" in their filter chain list.
This feature is enabled on a per host or per network basis, via the idlehosts configuration parameter attribute.
LAZY MONITORINGiplogin2 can be configured to never send any probes to non-idle users. See the section on IDLE LOGOUT for information on how to set up iplogin2 to monitor idle time for users.
This feature is enabled on a per host or per network basis, via the lazyhosts configuration parameter attribute. Any users for whom 'lazy monitoring' is enabled will have 'idle logout' turned off automatically.
SIGNAL HANDLINGIf a loadfile has been specified on the command line using the -l parameter, the signals SIGUSR1, SIGUSR2 and SIGTERM will cause iplogin2 to save the current state to the specified file. Additionally, SIGUSR2 and SIGTERM will cause the program to quit gracefully, unloading the users first.
BUGSiplogin2 shouldn't assume that all networks that it handles have the same interface characteristics. Timing parameters should be selectable by network prefix.
iladmin(8), ilcmd(8), ilcount(8), iplogin2-conffile5
HISTORYiplogin2 was developed as a replacement for IP-login, which is part of Bifrost Nomad (see http://bifrost.slu.se)
Magnus Nilsson (Magnus.Nilsson (at) udac.se) has spent lots of time discussing features and solutions with me, in particular concerning the accounting mechanism.
Emil Pedersen (Emil.Pedersen (at) its.uu.se) has done a lot of invaluable field testing, worked as a very useful discussion partner and contributed ideas, like the "extrachains" mechanism.
Martin Josefsson (gandalf (at) wlug.westbo.se) has made invaluable contributions and bug fixes to this code.
Gunnar Lindberg (lindberg (at) cdg.chalmers.se) has contributed lots of Radius-related stuff and improved the ARP probing code.
Robert Olsson (Robert.Olsson (at) its.uu.se) made the first version on which this was originally built, and has helped out with certain mechanisms, like the netlink code.