💾 Archived View for thrig.me › tech › openbsd › fingerd.gmi captured on 2024-12-17 at 10:30:41. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

fingerd

fingerd can be enabled on OpenBSD, though the default configuration is perhaps not suitable to expose to the whole internet, as this will expose the IP addresses that one logs in from. This may not be a good idea, especially if one is prone to annoy young males at their "wild age", as Stilgar puts it, or for various other reasons. It is difficult to avoid creepy corporate tracking these days, but one may not want to give them free hand-outs.

You could only login over a wireguard tunnel, in which case the IP address shown will probably be RFC 1918 something, but it's probably more sensible to expose only the information you want to the whole internet, which probably does not include the IP addresses you use to connect from.

The last step should be to open up TCP/79 in the firewall to the internet. The first step might be to ensure that TCP/79 is blocked by the firewall. Next, write a custom script for fingerd to execute. Most simply:

    $ cat /usr/local/libexec/lawn
    #!/bin/sh
    echo get off my lawn
    $ chmod +x /usr/local/libexec/lawn

And then to modify /etc/inetd.conf to execute this program:

    $ grep fingerd /etc/inetd.conf
    finger          stream  tcp     nowait  _fingerd /usr/local/libexec/fingerd   fingerd -lsmP /usr/libexec/lawn
    finger          stream  tcp6    nowait  _fingerd /usr/local/libexec/fingerd   fingerd -lsmP /usr/libexec/lawn

You may want to remove the -l flag to cut down on log noise? Once things are debugged, that is.

inetd will need to be enabled and started. This should properly be done with configuration management (Ansible or whatnot), if you are that organized.

    $ doas rcctl enable inetd
    $ doas rcctl start  inetd
    $ finger root@localhost
    [localhost/127.0.0.1]
    get off my lawn

But What About Multiple Users?

The observant may notice that our lawn script gives the same answer regardless of the user, or lack of user given:

    finger @localhost
    finger squarebobspongepants@localhost
    ...

Here the dreaded "second-system effect" comes into play, as we must bloat our elegant lawn script with features and wingdings and cover various annoying edge cases, such as someone connecting but then leaving the connection open without sending anything.

myfingerd.c

    myfingerd: myfingerd.c
    	${CC} ${CFLAGS} ${COMPILE} {body}lt; -o $@

Maybe run some tests (automatic tests would be good to add, to check for various testable edge conditions, especially if you are selling services to folks and not just running code yourself).

    $ COMPILE=-DDEBUG make myfingerd
    ...
    $ printf "testuser\r\n" | ./myfingerd
    ...
    $ rm myfingerd; make myfingerd

And then install and configure inetd for the custom finger daemon.

    finger		stream	tcp	nowait	_fingerd /usr/local/libexec/myfingerd
    finger		stream	tcp6	nowait	_fingerd /usr/local/libexec/myfingerd

A security risk here is that an attacker might use this script to enumerate users on the system, perhaps to find people to spam, phish, check for weak passwords by way of SMTP, etc. Attackers can be terribly clever here and may be able to use timing information to determine if an account exists or not. If this is a concern, maybe delay the responses so that "no account exists" cannot be distinguished from "there was an account, but they did not have a .lawn file".

Another downside is that this daemon requires access to the user's home directory. If this is a problem, maybe move the finger directory to be /somewhere/else/$USER instead of being under their home directory, but then you'd need to link to that from their home directory, or write a wrapper script that lets the user edit the finger message, or so forth.

gemini://gemini.thebackupbox.net/~epoch/blog/fingering

Probably you should not run finger on the squeaky clean corporate and spammer overrun internet. But where is the fun in that?