The key issue for authentication is, we want our own users to be able to do normal activities on Mathnet machines, and we want unauthorized hackers to be able to do only standard public activities. The activities include:
Mathnet and other institutions are experiencing frequent password guessing attacks against the SSH service, and FTP is also attacked less frequently. The passwords used are pretty lame and if we enforce password strength rules we should be able to resist such attacks, but sooner or later either our user will get a weak password past the strength rules, or the attacker will get lucky guessing a strong password.
Password guessing attacks, even if not successful, use quite a bit of system resources, interfering with normal operation, and we want to put a stop to this.
While password guessing against SSH is the current nemesis, it's only a matter of time before other authenticated services are attacked. FTP is already being worked on, and IMAP or POP is the hackers' logical next target.
In addition, recently we had one user whose password, we believe, was obtained by a keystroke logger on another network. We would like to resist attacks even when the attacker has the authentic credential.
It must be reasonably self-maintaining. If we have to massage a blacklist or whitelist daily by hand, that's not going to fly.
It must work for unsophisticated users.
It must work on borrowed equipment in foreign countries with little or no advance preparation. Our faculty visit at foreign institutions, and expecting them to set up authorization in advance is not realistic, if only because they cannot know from which IP range they will be connecting.
Improved authentication mechanisms, such as smart cards, one-time passwords, or radical strength requirements on passwords. At the very least we should regularly run a standard password cracking program.
Iptables blacklists. Guessing attacks generally come from one site at a time, believed to be zombies in a bot-net. This means that once recognized, they can be blocked, even system-wide, i.e. the zombie is recognized on one host and all hosts blacklist it.
This style is very attractive since all risk and resource usage is quenched quickly, even if the actual password is guessed after blacklisting. In addition, rejecting a connection from a blacklisted host takes almost no system resources.
One behavior has been seen in which the attacker tries several loginID-password pairs over a single connection; if the server is not picky about authentication failures, the entire attack could be carried out over one connection. The iptables ruleset must be designed to break this off: use the filter chain to dispose of packets even in ongoing connections.
Iptables whitelists. In this style all connections (except to public services) are blocked unless the client site is on the whitelist.
This style has similar advantages to the blacklist, but the big problem is to get needed sites onto the whitelist. The remote user needs to do some special procedure, involving authentication, to a public port.
An additional advantage is that it protects all present and future services automatically; there is no need to modify software or configurations to become protected or to recognize attacks (assuming that our user's remote host is not simultaneously attacking us, which is very unlikely).
Basically, something looks for frequent login failures from the same host. There are two easy sources of failure information:
A daemon reads syslog, watching for messages about authentication failure. There are several programs that do this, but it strikes me as something of a kludge, and the message formats are not designed to coordinate with a defense daemon; in particular, they are subject to change without notice.
A PAM module reports failures. Many of Mathnet's services use PAM to handle authentication, but not all of them. Specifically, webmail and Apache Basic Authentication don't use PAM.
However, we've heard of, and seen, attackers who try only one or two loginID-password combinations at a time, presumably trying them on every host on its list before revisiting our host. A rate-based attack spotter cannot recognize such an attack.
For the whitelist method attacks are suppressed by default and the problem is to allow legitimate users to get in. The client needs to send something to the server that induces the server to trust the client and add it to the whitelist. This authorization would expire after a certain time, either time after authentication or after a period of non-use.
Portknock and friends: In the original implementation the client sends UDP packets to several ports in sequence. This technique requires special software on the (Windows) client, and the knocking sequence is publicly visible and can be re-played by an attacker.
Portbang and friends: A shared secret is used to create a UDP packet that the server will trust. In Jimc's portbang program a RSA key pair is used; the client has the secret key and the server has the public key. This method operates in secret and resists replay attacks, but it still requires special software on the client, plus the server must be pre-configured with the shared secret, a problem in our environment.
Web form: The client connects to a public SSL-enabled port on the server (probably not 443) and gives his loginID and password, or some more modern alternative. This has the advantage that every credible client machine can be expected to be able to do the interaction. But it has two disadvantages: First, the server needs a webserver; it need not be full-blown Apache (thttpd would be enough), but it needs enough smarts to handle the web form. Second, if the method becomes popular enough, password guessing attacks could be directed against it.
If the attacker has stolen the actual password he can make the web form let him on -- provided he knows our procedure. Security by obscurity is a rather weak protection, but it probably would have kept out the various attackers in the case of the user whose password was stolen. Another alternative is a second, independent password (which also could be stolen, and if the two passwords are used on a client with a keystroke logger, correlated theft is likely).
I've assumed that each server will demand authentication from each client or will recognize and blacklist attackers independently. However, we could set up a global server which would manage a whitelist or blacklist that protects the entire Mathnet at once. There are several styles for this:
A central server manages a list of good or evil hosts. For the blacklist, a host recognizing an attack reports it to the central server; for the whitelist, the special authenticator is on this server. All (UNIX) hosts are instantly aware of list changes and install the needed iptables rules.
Instant
awareness could happen by a broadcast on each subnet,
or by a persistent TCP connection from each of 133 Linux boxes to the
server, or by having the 133 clients poll the server once a second.
In principle a client daemon could be written for Windows, but that
would take some expertise and would at least double the number of
clients.
Central administration and local execution is tempting, because to some extent it retains protection if the central server goes down. But this style is quite complex and could use a lot of network bandwidth and execution time to serve the clients' queries. It also would not help Windows vulnerabilities, unless a local daemon were written specially for Windows.
If there is a chokepoint router which the attacker's packets
absolutely must traverse, an ACL could be installed there to block the
attack. If the router is a Cisco box the good/evil server would
send updates there; if it's a Linux box the good/evil service daemon
would naturally be on it and would install iptables rules locally.
This style works well for the portbang
software, and local
iptables rules are much more manageable and controllable than an
ACL on a separate Cisco box.
At this point we're not ready for production deployment; the idea is to set up some software and estimate how well our users will like it.
I think the whitelist approach gives the most draconian protection for the least effort. There are several blacklist-type protection programs, but the one we're most seriously considering is only effective for SSH attacks, and although that is our currently obvious problem, if we're going to go to the trouble of improving our defenses, we ought to protect against future attacks as well.
The whitelist method also gives us protection for the videoconference equipment, which is notoriously hard to lock down; H.323 is bad in any case. A globally effective whitelist also protects Windows boxes while allowing unusual or advanced techniques like RDP, with no need to adjust Windows firewall rules on the target machine.
Let's set up the per-machine whitelist, and in parallel, investigate a chokepoint router running Linux, which is the preferred router if we want a globally enforced whitelist (or blacklist).
Let's create a CGI to accept the web form (using SASL/PAM for the actual authentication engine, following the model of the Certificate Authority). We'll protect all the MCG Linux boxes, and the MCG people can evaluate the procedure. Then we'll sell it to early adopters such as Anderson and Bertozzi, who may particularly value security. Finally, assuming it's satisfactory, we'll roll it out for the whole department.
stunnel with thttpd. thttpd does not support SSL natively, but you can get inetd to spawn stunnel which will accept the SSL connection, then pipe it to your favorite web server on whatever port you choose. The server then speaks normal HTTP. There is a SuSE package for stunnel.