Ubiqiti / Ubnt stuff

Setting up unifi devices

If you don't want to ssh to all new devices on their default IP address of
192.168.1.20 (and for that purpose create an alias ethernet interface in that
subnet) there is a very easy solution.

The default inform URL of unifi devices is http://unifi:8080/inform.
To make devices automatically connect with your individual unifi controller
server, you have to configure your DNS server so it resolves unifi to the IP address of your controller
example for the /etc/hosts file:
123.123.123.123 unifi

After that change I restarted my OpenWRT router and all the new unifi devices connected instantly with the controller.

They showed as Pending adoption. I clicked on adopt and the adoption was done
without any problems.

Unifi with SSL certificate from letsencrypt

I had nothing else running on the server, so I installed lighttpd and used the
webroot module to install a certificate. I will not cover that here since there
is enough documentation for letsencrypt/certbot out there.

The problem is to make that script only run when the certifcate for the
unifi-controller is updated. Of course I could run it each time the cronjob for
updating the certificates is run, but that's not what I want (unifi controller
takes some time to restart, so it would be offline every day in the morning for
some seconds/minutes).
As far as I understand the letsencrypt documentation, the option renew-hook can
only be used in the main config file

It should work like that
letsencrypt renew | tee | grep -q "/etc/letsencrypt/live/<domain>/fullchain.pem (success)" && /usr/local/bin/update-unifi-cert

but the more elegant way would be to have the renew-hook parameter available in each single file in /etc/letsencrypt/renewal/*

Server Port Problem

There is a Problem with Aircontrol 1 (version 1.4.2-beta.3839), that the HTTP
connection from antenna to server tries to connect to port 22 on the
serverside, no matter what is configured in the Aircontrol server settings
(there port 9080 was configured).

After provisioning the antenna we check the settings on the antenna via CLI:$ mca-ctrl -t status
http://name-of-the-server.domain:22/heartbeat
$

So the correct server port is not set, instead the server sets (server) port
22. Of course on the server on port 22 nothing is listening for the
connection from the antenna.
The heartbeat gets through if I manually set the correct port on the antenna

After that the antenna comes online instantly. Of course the setting is lost as
soon as the antenna is disconnected / unprovisioned, each time after
reconnecting the correct port has to be set again. That is of course too
complicated (and the mere heartbeat doesn't help for provisioning antennas
anyway).

The easier way is to make the server listen on port 22. Since there is no way
(I know of) to change the server port it is easier to create a port redirect
with iptables.

On the server run (adapted if necessary):# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-port 9080
After that all antennas come online by themselves. Yeehaaaah!
The heartbeat can then also be set withmca-ctrl -t connect -s http://name-of-the-server.domain:22/heartbeat

How to change password and admin user on AirOS device via command line
interface and ssh

Such a change might be necessary if the password is not accepted by the login
of the webinterface, e.g. because it is too long.

If you make these changes yourself step by step it is important to sync all
changes, otherwise you can easily lock out yourself of your antenna (and having
to drive to a remote place for resetting your antenna is never what you want).
This is exactly what is done by the webinterface if you change username or
password there.

Add a new line for the new admin into /etc/passwd, copy & paste from another
device, hash type / length should be the same (to be on the safe side). The
line for the old admin can stay there, it will be deleted automatically later.

Edit /tmp/system.cfg and look for the linesusers.1.name=adminusername
users.1.password=HeReIsThEhAsH

Edit users.1.name to correspond with the username added to /etc/passwd
copy&paste the password hash from this user's line in /etc/passwd to /tmp/systemf.cfg
run cfgmtd -p /etc/ -w
reboot

The public key authentication set up previously (as a backup in case something
went wrong with the passwords) will automatically work for the new admin user
name.

You can log in via ssh with all usernames that are listed in /etc/passwd.
When rebooting all other admin usernames apart from the one set as
users.1.name will be removed from /etc/passwd

How to remove the motherfucker virus / worm

It is written rather simple and can be removed without any major problems.

The virus does (at least) the following things:

Create a system account (mother, moth3r, motherfucker or similar)

store and camouflage its files somewhere on the filesystem

make sure it gets loaded at every reboot

scan the network around him to distribute itself aka infect other devices

set aliases for the shell so it gets run / loaded e.g. when the user runs the ps command (nice one! :) )

There are 3 variants of the motherfucker virus (known to me after cleaning
several antennas (don't ask, fortunately I wasn't responsible for them))

Variant 2

All the files of the virus are located in /var/lib/dhcp
Probably motherfucker can use /var/lib/dhcp/.ssh/authorized_keys, so you have
to write your own key (via exploit) into that file to be able to login, if your
password doesn't work
rm /etc/persistent/rc.poststart
rm -r /var/lib/dhcp

Variant 3

The virus writes itself to /var/bin/cgi and runs itself at every boot from
/etc/persistent/rc.prestart
rm /etc/persistent/rc.prestart
rm /var/bin/cgi

Attention:
I have found several devices that had open ssh connections originating in China
and Argentinia that were (due to the high traffic usage) obviously used as a
proxy for whatever illegal purpose.

Since the motherfucker worm had been removed and the firmware updated to a
(hopefully) not vulnerable version the only option how the ssh-tunnel could
have been established is via public/private key authentication.

So I had a look at /etc/dropbear/authorized_keys, this file was empty.
Then I had a look at