Today it has become popular to convert rectangular Starlink terminals into a flat “automotive” version.
There are tons of projects like this one or this. People cut the terminal case and pack it in a custom flat housing. Typical usage: RV.
An essential part of such modifications is the change of the power scheme.
In the automotive version, powering the terminal from 230/110 AC is inefficient. Power supply modification includes a custom PoE injector and DC/DC converter (12V – > 48V). I propose an even more efficient power supply scheme without additional voltage conversions.
Please note that most information below applies only to current rectangular rev3_protoX terminals.
Rev3 terminal PoE circuit
Let’s look at the PoE schematic on the board.
Here we can see Ethernet/Power connector, PoE transformer, current measurement circuit (0.05R shunt + AD8541 opamp), and primary DC/DC converter L3751. Plus, the PoE detection circuit and PD controller.
Here is the block diagram:
The primary internal power bus is 12V. All other Dishy’s voltage regulators feed from this bus. Thus we can bypass the input voltage regulator and provide 12V directly to the primary bus.
To protect the primary voltage regulator from reverse current, we need to disconnect it from the 12V bus. This can be done simply by removing the big inductor and feedback diode. You can see them in the picture below.
I do not recommend removing L3751 IC or MOSFETs. It’s more complicated, and there is a risk of messing up.
You may have noticed that we are also bypassing the current measurement circuit. This is okay. The Dishy firmware doesn’t care about zero consumption in runtime.
12V connection
After the components removing it’s safe to connect external PSU wires directly to the board. The most optimal connection point is the output ceramic capacitors array. I highlyrecommend connecting an electrolytic capacitor in parallel.
The minimal capacitance is 470 µF when you have relatively short wires from the 12V source. If your wires are a few meters long, you can use a 2200 µF capacitor. I tested with 5 meters 12AWG cables. The capacitor voltage rating should be 25V.
Ethernet cable connected directly to a host/custom router with 8P8C/RJ45. Don’t connect the reworked Dishy to any PoE power supply or Gen2 Starlink router.
Measurements
I connected my shelf multimeter to the 12V rail and used the ut-reader to collect and plot current measurements.
As you can see, Dishy jumps to 7A, and the median consumption is around 5-6A, depending on the operation. The values can change very quickly, so your power supply must be able to handle sudden surges in consumption. When stowed, Dishy consumes a constant 1.1A.
The minimum supply voltage is 10V, and the absolute maximum is 15V. Please, do not exceed 15V value. It might damage your Dishy.
Please note that powering the Dishy from the car’s 12V line might be dangerous when ICE is running. The voltage levels might be pretty unstable. Also, Tesla’s low voltage line is 16V instead of 12V (Li-ion low voltage battery). Consider this if you plan to power your Dishy from the modern Tesla car.
Keep your server safe with a few extra steps, from tosdn.
SSH is essential to server management. This post will walk you though some of the options available to harden OpenSSH. The instructions may work for other flavors of Linux but is intended fro Ubuntu 16.04 LTS.
Warning: Messing with how SSH works can be dangerous. You can very easily lock yourself out of the server. Be careful.
OpenSSH Server Configuration
The settings file for OpenSSH on Ubuntu 16.04 is located at /etc/ssh/sshd_config. You will need to be root or use sudo to edit and control the SSH server.
Backup Configuration File
It is always a good idea to make a backup of any configuration files before editing them.
I am not fancy so, I use nano for configuration file edits.
nano /etc/ssh/sshd_config
SSH Configuration Test
After editing the configuration file you should test that it is valid before reloading the service.
sshd -t
Reload the Configuration File
Once you think your edits are good, reload the SSH daemon.
sudo systemctl reload sshd
Check the Protocol
Our very first edit will be very simple. It is really more of a double check than an edit. Open /etc/ssh/sshd_config and check the line that starts with Protocol. Make sure it is set to 2 and not 1. The current default is 2.
Protocol 2
Disable Root
Instead of using root, we should be using connecting as user with sudo permission. Make sure you have sudo setup properly before continuing. So let’s disable the ability of root to login using SSH. Inside the configuration file find the line:
PermitRootLogin yes
Change that to no:
PermitRootLogin no
Disconnect Idle Sessions
Idle sessions can be dangerous. It is a good idea to log people out after a set amount of inactivity. The ClientAliveInterval is the amount of time in seconds before the server will send an alive message to the client after no data has been received. ClientAliveCountMax is the number of times it will check before disconnecting. In the example below, the server will check on the client after 5 minutes of inactivity. It will do this twice then disconnect.
ClientAliveInterval 300 ClientAliveCountMax 2
Whitelist Users
We can limit the users that are allowed to log in SSH. This is a whitelist. Only users in this list will be allowed. Everyone else will be denied. Let’s say that I want to allow user norton to log in remotely through SSH. We will add the line:
AllowUsers norton
Don’t forget to add your username to the AllowUser list.
Change Ports
My second least favorite way of hardening SSH is changing the default port. Normally SSH runs on port 22. The idea is that most script kiddies are only going to target that port. If you change you default port, maybe your attacks will decrease. I don’t do this or recommend it. But, maybe you disagree. In the configuration file find the line:
Port 22
Then change it to another available like maybe 2222.
Port 2222
SSH Keys
By default you log into the system through SSH with a username and a password. These can be brute forced. People will try an enormous amount of username and password combinations until they find one works. So, instead of using passwords we should use SSH keys.
Generating a Key Pair
If you already have a key pair, skip ahead.
We are going to make some public key encryption keys. They come in pairs. Private and public. If you are not familiar with this system of encryption, than check out my video, A Very Brief Introduction to Public-key Cryptography.
Run the following command to generate your keys on the client machine. Do not run this command sudo. It will ask you for a passphrase to protect the key. You can keep this blank but I do not recommend that. A private SSH key with no passphrase protection can be used by anyone with possession of that key to access the server.
ssh-keygen
Share Your Public Key
Use ssh-copy-id to send you public key to the server.
ssh-copy-id jason@192.168.1.1
Now try logging in. You may be asked for your passphrase.
ssh jason@192.168.1.1
You should get a message back that looks similar too:
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. ECDSA key fingerprint is ff:fd:d5:f9:66:fe:73:84:e1:56:cf:d6:ff:ff. Are you sure you want to continue connecting (yes/no)?
Say yes and you should be logged in without a password.
Disable Password Authentication
If we have SSH keys working we can just disable all password authentication. Find the line:
PasswordAuthentication yes
And change that to no.
PasswordAuthentication no
Disable X11Forwarding
This guide is intended for use with remote servers. Generally speaking, there is no reason to use a GUI for a remote server. So disable X11 forwarding. Find the line:
X11Forwarding yes
and change that to no.
X11Forwarding no
Fail2Ban
This is a great program that can scan logs and ban temporarily ban IPs based on possible malicious activity. You will need to install Fail2ban.
apt-get install fail2ban
Once installed, we copy the fail2ban configuration file.
Open the /etc/fail2ban/jail.local files and find the spot that starts [sshd]. Edit it like so, adding enabled = true:
[sshd]enabled = true port = ssh logpath = %(sshd_log)s
Then restart fail2ban
service fail2ban restart
Fail2ban will monitor your SSH logs for possible malicious activity and then temporarily ban the source IP.
Multi-Factor Authentication
We can also user TOTP (Time-Based One-Time Passwords) to harden our SSH security. In this example we will be using Google Authenticator. When we attempt to log into the system we will be challenged to provide a verification code. We will use the Google Authenticator app to generate that code. First we need to install some software.
sudo apt-get install libpam-google-authenticator
Then run the initialization
google-authenticator
It will ask: Do you want authentication tokens to be time-based (y/n) and we need to say yes. Then it will print out the QR code and ask if want to update our .google_authenticator file. We do.
Don’t worry this code was never used and the server no longer exists.
Scan that code into the Google Authenticator app and save those emergency codes! You will next be asked a few more question. We will answer them all with yes.
Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) yBy default, tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of 1:30min to about 4min. Do you want to do so (y/n) yIf the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s. Do you want to enable rate-limiting (y/n) y)
Edit the PAM rule file /etc/pam.d/sshdadding the follow at the end:
auth required pam_google_authenticator.so
Edit the ssh configuration file.
UsePAM yes
ChallengeResponseAuthentication yes
And restart the SSH server. The system will now require a verification code when you log into the server.
Banners and MOTD
My least favorite way of hardening SSH is adding legal mumbo jumbo to the ssh banner and MOTD. Usually some redundant statement saying “unauthorized access is prohibited”. This is security theater. The advice is usually given by the same armchair lawyers who add “confidentiality notices” at the end of emails. If an actual US lawyer says that you need this to be protected by the CFAA, you need a new lawyer. I think this myth originated from a poor understanding of the UK’s Computer Misuse Act 1990 and basic legal jurisdiction. Also if you ask an undercover cop if they are a cop, they don’t have to say yes.
Banner
Often people will talk about the banner leaking system info. They will leave out the fact that the Banner is disabled by default in Ubuntu 16.04. Let us enable it to see what happens. This banner is sent out before authentication. Everyone attempting to connect through SSH will see this banner. You may need to enable PasswordAuthentication to see the banner.
Edit the SSH configuration file then find and uncomment:
#Banner /etc/issue.net
Now try to connect to the server with a fake user:
Ubuntu 16.04 uses a dynamic MOTD. We will just be editing the header of the message. Before we change the anything, let’s make a backup of that original header.
Now we are in compliance with the laws of make believe.
SSH Audit
So far we have been covering the basics. Now we move into some more advanced SSH hardening. SSH Audit is a Python script that will scan your SSH server for some security issues. Download it and run it like any other python script, just point it at your target SSH server.
python ssh-audit.py labs.seattlebot.net
Then we get a rather large report.
This report gives us a peek behind the SSH curtain. This is a report on the ciphers and algorithms used by your SSH server to secure communications with the client. If you have done work with OpenSSL some things might look familiar. As you may have learned using OpenSSL, not all ciphers and algorithms are equal. Some are strong and some are weak. Eliminating the weak ones can help harden your system.
Change Hostkey Preference
We will be following the advice of stribika, mozilla, and the SSH audit report. We will change our HostKey preferences. Remove the current HosyKey entries in the ssh configuration file. Replace them with the following.
Continuing to follow the advice of stribika, mozilla, and the SSH audit report. We change our Key exchange algorithms, symmetric ciphers and, message authentication codes. Add or replace the following to the ssh configuration file.
Let us see if our changes made the SSH audit happy.
python ssh-audit.py 173.255.250.98
Green is good.
That is looking better.
Regenerate Moduli
The /etc/ssh/moduli file contains prime numbers and generators used by the SSH server for the Diffie-Hellman key exchange. Your current /etc/ssh/moduli is probably not unique. Generating a new file may harden your server. Generating these file might take awhile.
Hopefully you have found this useful and your server will now be just a bit more hard to break into now. There is much more to learn about OpenSSH. Good Luck.
(-12 it’s just a zero point or ground. Not some negative rail)
