Score:3

Block all incoming requests but local network

gb flag

I have a dedicated server that I spun up an Ubuntu 22.04.1 LTS server on with a public ip address. I want to lock down the ssh port to only allow specific ip addresses through.

I have 3 ip adresses from work and the network I setup on the server with an ip range.

How would I go about allowing only these ip addresses to log in to my server?

I found this in another post:

iptables -I INPUT -p tcp ! -s yourIPaddress --dport 22 -j REJECT

Would this work if I ran it for each ip address or would there be complications?

Also, is this enough? Should I be locking down any other ports? This is a fresh install with only postgresql on it. I'm attempting to learn more about Ubuntu and postgresql but I don't want my server to targeted.

Thanks for your input!

pk flag
if your home IP address changes, will you be willing to go to the data center where the dedicated server is, plug in a keyboard and a screen and update the rule?
Score:6
ru flag

I would suggest you adjust your approach from single-port-focus to a full 'defense' posture: Whitelist IPs, reject all other connection attempts. This applies for most all ports on your environment - because otherwise you're going to have to blacklist every IP known to existence that does service scanning, so you're going to have an insanely long list in its place. Service scanners scan for every port so you should adopt a "denial of trust" approach first and foremost. Things like a web server (port 80, 443 for HTTP/HTTPS may need wider access than specific IPs if it's a public site) are also scanned but can be 'protected' by properly hardening the web server and content. However, all ports are scanned by service scanners, and all internet connected devices are subjected to scans, so denying everything to start is the better approach.

As such, the most effective approach to "denial of trust" is to simply allow certain IPs to connect to the port(s) and all other services on the machine, and then reject all other attempts to connect. While also allowing localhost to communicate to itself, which is OK.

Start by protecting everything with whitelisting before opening other ports. If you need more services we can configure additional ALLOW rules for HTTP traffic from everywhere, etc.

# Allow localhost traffic
iptables -A INPUT -i lo -j ACCEPT

# INVALID type packets should be DROPped regardless of source.
iptables -A INPUT -m state --state INVALID -j DROP

# Allow traffic for related/established connections already running
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow all new connections/traffic from the local subnet you're on 
# (10.20.30.0/24 is used in example)
iptables -A INPUT -m state --state NEW -s 10.20.30.0/24 -j ACCEPT

# Whitelist your IPs - repeat this step for each of your IPs permitted
# to access the machine outside of local network
iptables -A INPUT -s IPADDRESS -m state --state NEW -j ACCEPT

# If you have other services you want to configure for *public* access, then
# use this rule as a template and execute this before you follow the last step.
#
# Change PROTO to the protocol (tcp/udp, etc.) and PORT to the port number 
# (80 for HTTP, ex.)
#
# Add this to the end of the rule if you want to allow only certain 
# IPs to the specified service:
#   -s IPADDRESS 
iptables -A INPUT -p PROTO --dport PORT -m state --state NEW -j ACCEPT

# Deny all other traffic
iptables -A INPUT -j REJECT --reject-with icmp-host-unreachable

This is based on my experience with servers for almost 15 years, and my network security training. As well as my knowledge as an IT Security Professional.

ErocM avatar
gb flag
Thomas, that's a great reply! The notations really help me understand what you are doing and learn from it. TYVM!
Guntram Blohm avatar
cn flag
`iptables` is, very slowly, being replaced by `nftables`. While I myself know `iptables` well, and don't know much more about `nftables` than that they exist, for somebody who doesn't know either, it might make sense to directly jump to `nftables`.
ru flag
@GuntramBlohm fun fact theres tools to migrate rulesets over. However, I dont see what your comment has to do with my answer nor the asker's question.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.