You are reading content from Scuttlebutt
@Hendrik Peter %z0daxWP5rGioPDPWHUO0z3GKAFjthPxzJWAjMSvfEi0=.sha256
Re: %nAQiCVKUa

Hey @Giulio Prisco!

I persuaded the room to work by brute-force

that sounds rather extreme now doesn't it ;).

I assume you executed

ufw default deny

Which blocks all traffic through the "uncomplicated firewall" that isn't specifically whitelisted. (if you haven't than that's probably a good idea. it will keep baddies out of postgres/redis/telnet/etc services that you have installed on the machine unless you open those up)

you then executed

ufw allow 8007
ufw allow 8008

to whitelist those specific ports.

Now if you want to white-list http traffic, https traffic as well as SSH access to your server you can simply just:

ufw allow http
ufw allow https
ufw allow ssh

http, https, and ssh are ufw TCP template presets. if you run ssh on another port than 22 (I'd recommended this to make it harder for baddies to get in), then you need to allow that specific port using ufw allow [your-custom-port-number]/tcp (so as an example ufw allow 5001/tcp

You would also do this for all other services you are running on your machine that you'd like to expose.

As soon as you have set all your rules you can type ufw enable or ufw reload to activate or reload ufw with the new configuration.

You can check all your rules (when the firewall is enabled) by executing:

ufw status

Here's a full list and handy guide on how to use the UFW firewall.

https://help.ubuntu.com/community/UFW

@Hendrik Peter %TqIZHSpN89eGnYkh6upgRpZELB0NfVx8OAekFZY+Dxo=.sha256

Forking out with a general tip when it comes to VPCs and root users.

Feel free to ignore this @Giulio Prisco if you already know this :p

I don't see you using sudo in any of your commands, I'd recommend creating a new user once you get access to a VPS that needs to elevate with sudo before being able to run root commands. This to prevent shell scripts and other pieces of code from running as root by default. you can do this like so:

useradd <username> -m --group sudo

where you replace <username> with some inconspicuous username.

passwd <username>

To give your <username> user a password. and then:

sudo chsh -s /bin/bash <username>

To allow your user to login to a bash shell.

(Next step if you connected to the root user using your SSH keys)
You then allow yourself to connect to the new user using ssh by public-key-login by logging in to that user

# Login to that user
su <username> 
# Generate SSH keypair and .ssh folder
ssh-keygen -t rsa
# open the authorized keys file
nano ~/.ssh/authorized_keys

and paste in the public key that sits in ~/.ssh/id_rsa.pub on your own local computer.
(end of special logic that you should do if you logged in to the root user using your public key)

Open up a new terminal tab and see if you can ssh to your brand-spanking new user using:

ssh <username>@<ip-address>

if that succeeds, block people from accessing the root account by going through the following steps:

  • sudo nano in to the /etc/ssh/sshd_config file on your server and make sure to set "permit root login" to "no",
  • Expire the password of your root account (system accounts that have no password can't be logged in to) by executing: sudo passwd -e root

Update your VPS and then restart it for all the changes to take effect ;)

User has not chosen to be hosted publicly
User has not chosen to be hosted publicly
@Hendrik Peter %uDBdozbz4I+Qz9YTQWkWfpOeGx7UUBLClw/vLUaKxsg=.sha256

nice @Giulio Prisco!

would be good to specifically add HTTP and HTTPS (80/tcp and 443/tcp respectively) I think Nginx is mostly for the maintenance ports (if there are any), but I can be wrong.

I fix most who goes and redirects where problems by assigning sub-domains to the DNS settings on my host and then do things per incoming sub-domain.. and then "proxy-pass" the HTML bits and bops to port 80 for that domain.

as an example (with real slightly altered config)

server {
  server_name picoroom.hendrikpeter.net;

  access_log /var/log/nginx/ssb-room-access.log;
  error_log /var/log/nginx/ssbg-room-error.log;

  location / {
    proxy_intercept_errors on;
    proxy_pass http://127.0.0.1:8007;
  }

  error_page 502 @offline;

  location @offline {
    root /home/serveruser/Sites/nothing-to-see-pages/;
    try_files /502.html 502;
  }

   listen [::]:80
   listen 80
}

the proxy-pass bits here tell the incoming port 80 loop to the internal port 8007 for any requested internet address called "picoroom.hendrikpter.net" (on port 80). so people can just visit http://picoroom.hendrikpeter.net:80 or http://picoroom.hendrikpeter.net for short.

Then as a bonus you can serve custom error pages for error statusses from another folder with static html files.

This bit of config is also compatible with certbot (an automated bot from letsencrypt that automagically upgrades the http bits to https)

Put the config in, change your server_name to the sub-domain you chose for your room pages and then install certbot and execute:

sudo certbot --nginx -d subdomain.domain.org

follow the instructions and voila, your room is now HTTPS ;)

Join Scuttlebutt now