Why should I restrict OpenSSH access to my IP block?

Restricting OpenSSH access to your own IP block enhances security by blocking unauthorized connection attempts, reducing the risk of brute-force attacks and data breaches.

How does firewalling improve OpenSSH performance?

Firewalling reduces unwanted traffic to your server, decreasing load and increasing responsiveness, which results in better OpenSSH performance.

What happens if my IP address changes?

If your IP changes, your firewall rule may block your access. It's important to regularly update firewall rules or have a dynamic DNS setup to maintain remote access.

What backup access options should I have?

You should always have a backup access method like a secondary administrative account, VPN with a static IP, or a serial console (e.g., Oracle Cloud) in case of accidental lockout.

Are firewall rules enough to secure OpenSSH?

No. While firewalling is crucial, you should also update OpenSSH regularly, use key-based authentication, and monitor SSH logs for suspicious activity.

HiddenSSH - Secure OpenSSH Hardening

Firewall

Firewalling

By blocking unwanted traffic, you can reduce the amount of unnecessary network traffic and improve the speed and responsiveness of your service.

Firewall Theory

Linux Software Layers

Netfilter is the Linux kernel firewall framework, implemented through kernel hooks/modules that inspect, modify, drop, or forward packets.
iptables is the classic user-space command-line tool that creates rules for Netfilter, organizing packet decisions into tables, chains, matches, and targets. Netfilter features depend on kernel support. If a required kernel module or built-in option is missing,
the related iptables function will not work and will usually error.

If you are gona build a custom kernel, you are gona need custom, secureboot key and import the key if you are using custom kernel.
Only prebuilt kernel signatures exist in the default secureboot database.

Netfilter interface tools

Firewall Layering

Many people were taught to firewall in only one place to avoid complicating rules, and that idea still persists.
In practice, proper firewalling is done in layers, different layers serve different purposes.

Application layer = An Application firewalls IPs.
Layer 3 firewall = Network layer
Network-layer filtering = IPv4/IPv6 filtering
IP-layer filtering = filtering by source/destination IP
Packet filtering = filtering packets by IP, protocol, port, interface, or state

This depends on the specific infrastructure you are using, but the basic idea is to have the first firewall absorb the heavy denial hits.
Offloading resource usage from the server to the outer layers at each step, with more specific rules as traffic moves inward.

Example; router infront of server blocking most, and server firewall duplicating some of them, and narroving usage down even more.
Finally, traffic reaches the application-level firewall, where rules define which IPs can perform specific actions.
For example, User1 may only be allowed to connect from a specific IP address, or from a specific IP block.

Open Sockets

Filtered vs open sockets;
Sockets should never be exposed unless there is a specific purpose, this applies to sshd sockets.
(filtering, firewalling, or blocking) sockets refers to the server where the sshd socket is running.

You never want an sshd socket fully exposed, even if the chances of an attacker gaining access is minimal.
Reason; being you dont wan't any bad actors poking around anywhere they should not be, and being able to communicate with the sshd is bad enough.

Always use (firewall/iptables) chains for ssh users, and comment, what IP belongs to each user, for simplify management.
This means all the IPs in the ssh users chain, are allowed to communicate with the socket, send and recieve data.
But (sshd config file/sshd/application level firewall) will define what IP belongs to what user.
Example; 20 IPs are allowed to communicate with sshd socket, but only 1 is allowd to login as your user.

Meaning (exposure risk/attack surface), is much much smaller compared to an (*/wildcard/open socket).

With (open socket/*/wildcard) you run into hygine problems and log sorting problems.
99% connections you get incoming are garbage and just a security risk.
slowing your (computer/instance/VPC) down in the process, by forcing CPU to performe tasks.

Seeing as how important sshd is, ssh user ips, (should be narrow/specific as possible).

Application Level Firewall

In sshd, application level firewall only checks if the user has the correct IP.
It doesn't process anything before (nft tables/iptables);
sshd works independently from (nft tables/iptables), and only checks line allow users, in sshd_config;

AllowUsers user1@144.24.46.145

You can always define more IPs to a user by;

AllowUsers user1@144.24.46.145 user1@144.24.46.*

To apply allow all IP's to specific user

AllowUsers user1@*

Important part; is that user IPs stay static much as possible otherwise it becomes a nightmare with updating all constantly.

Oracle VCN Example;

Example; (Oracle VCN/"Oracle Virtual Cloud Network")

First Layer: VCN Security List (Have a list allow only ssh IPs)
Second Layer: (Network security groups/Instance)
Instance Traffic is controlled by its firewall rules in addition to the associated subnet's security lists and the VNIC's network security groups.
Third Layer: (nft tables/iptables).
Fourth Layer: sshd, by using AllowUsers user1@144.24.46.145 in the sshd_config

Note: That ssh allow ips chain, is applied 3 times before, before they are defined for each user, at the application level firewall.
And even if the first layer is (compromissed/wrongly configured), second layer will block it. etc..

Firewall Server Level

Important note; iptables are by default in ACCEPT mode, in main chains; INPUT OUTPUT FORWARD. Meaning everything is allowed, except what is defined as not allowed. Proper way to use iptables is having it set to DROP MODE, for chains INPUT, OUTPUT, and FORWARD. Meaning its blocking everything that isnt defined as allow.

BASIC iptables allow; ssh-ingress chain and adding it.

Create SSH ingress chain first:

iptables -N ssh-ingress

Add the ssh-ingress chain to incoming traffic:

iptables -A ssh-ingress -j INPUT

Allow SSH traffic only from your IP block:

iptables -A INPUT -p tcp --dport ssh -s x.x.x.0/24 -j ACCEPT

Iptables - Important (settigs/flags/config).

When an iptables chain is set to DROP by default, it blocks all traffic unless explicitly allowed.
Without this rule, all SSH (outgoing connections are denied/egress traffic is denied). And any connection cant be fully established, because traffic is blocked outgoing back to the client.

iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

You would ideally put it in an iptables chain called base-service-egress as an example, and as close as possible to the top of the OUTPUT chain.

Source port

In iptables, a source port is defined with --sport or --source-port. iptables -A OUTPUT -p tcp --sport 32768:60999 -j ACCEPT

Command shows where the source port range is defined in the linux kernel, you can change it but not recommended.

cat /proc/sys/net/ipv4/ip_local_port_range

Why source ports matter: many binaries need this defined in their firewall rules in order for local connections to be made.
This is not specific to SSH or sshd, but you may run into problems without it.

(nftables/nft/Netfilter)

iptables = older frontend / older rule model
nftables = newer frontend / newer rule engine

/etc/nftables.conf

Iptables set input drop

Changing the iptables default policy from accept to drop, will result in droping any connections that doesn't match the allow rules.

iptables -P INPUT DROP

You would do this step by step, for each inviduall main chain.

Firewall/Iptables chains

Whatever tool you might be using, the rules are normally processed from top to bottom.

This means the rules at the top of the list are processed first.

To avoid unnecessary (CPU tasks/load/load on the CPU), it can make huge difference in latency and, dependent on how many rules are in the list and location in the array.

Chain INPUT (policy DROP)
target       prot opt source               destination
ACCEPT       all  --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
ssh-ingress  all  --  0.0.0.0/0            0.0.0.0/0

Iptables and many other firewall tools use chains. Their main purpose is to make rules more manageable.

Note: This is not always that important if you have few rules, but if you have like 25,000 firewall rules it becomes absolutely vital.

Open Socket sshd

You should never run sshd open at the server listening on a wildcard and allowing all traffic.
Use a SSH Proxy for dynamic IP Purposes.

Readme

Having a backup access method is crucial in case of accidental lockout, such as using a secondary administrative account and serial console in Oracle Cloud for an (instance/VPC), or IMPI access, in classical servers.