Wiki - Recent changes [en]

Nftables

Scott — Thu, 02 Jul 2026 22:56:25 GMT

TRAVEL SCENARIO: my current IP can't SSH in

← Older revision		Revision as of 22:56, 2 July 2026
Line 49:		Line 49:
	Options, in order of preference:		Options, in order of preference:

	# '''~~UCI~~ VPN''' — connect, then SSH from the VPN address (~~10.0.0.0/8 and~~ campus ranges are in <code>$ssh_nets_v4</code>).		# '''VPN''' — connect, then SSH from the VPN address (campus ranges are in <code>$ssh_nets_v4</code>).
	# '''IPMI console''' — log in via BMC, then fix from the console.		# '''IPMI console''' — log in via BMC, then fix from the console.
	# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):		# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):

Fail2ban

Scott — Thu, 02 Jul 2026 22:55:32 GMT

TRAVEL SCENARIO: I banned myself

← Older revision		Revision as of 22:55, 2 July 2026
Line 55:		Line 55:
	Symptoms: SSH connects then drops instantly, or times out, from one specific location — while the VPN or another network works fine.		Symptoms: SSH connects then drops instantly, or times out, from one specific location — while the VPN or another network works fine.

	# Get in another way (~~UCI~~ VPN, IPMI console, or another host).		# Get in another way (VPN, IPMI console, or another host).
	# <code>sudo fail2ban-client status sshd</code> → confirm your IP is listed.		# <code>sudo fail2ban-client status sshd</code> → confirm your IP is listed.
	# <code>sudo fail2ban-client set sshd unbanip <your-ip></code>		# <code>sudo fail2ban-client set sshd unbanip <your-ip></code>

Nftables

Scott — Thu, 02 Jul 2026 22:49:24 GMT

Created page with "= nftables Cheat Sheet = Config: <code>/etc/nftables.conf</code> · table <code>inet filter</code> · chains <code>input</code> / <code>forward</code> / <code>output</code> Input policy is '''drop'''; SSH allowed only from <code>$ssh_nets_v4</code>. Out-of-band rescue: IPMI/BMC console (H5Viewer or Serial-over-LAN). == Everyday commands == <syntaxhighlight lang="bash"> # Syntax-check the config WITHOUT applying (always do this first) sudo nft -c -f /etc/nftables.con..."

New page

= nftables Cheat Sheet =

Config: <code>/etc/nftables.conf</code> · table <code>inet filter</code> · chains <code>input</code> / <code>forward</code> / <code>output</code>

Input policy is '''drop'''; SSH allowed only from <code>$ssh_nets_v4</code>.

Out-of-band rescue: IPMI/BMC console (H5Viewer or Serial-over-LAN).

== Everyday commands ==

<syntaxhighlight lang="bash">
# Syntax-check the config WITHOUT applying (always do this first)
sudo nft -c -f /etc/nftables.conf

# Check + reload in one line (reload only runs if check passes)
sudo nft -c -f /etc/nftables.conf && sudo systemctl reload nftables

# Show the live ruleset
sudo nft list ruleset

# Show live ruleset WITH handles (needed for deleting single rules)
sudo nft -a list ruleset

# Just the input chain
sudo nft list chain inet filter input

# Service status / enabled at boot?
systemctl status nftables
systemctl is-enabled nftables
</syntaxhighlight>

== Am I being firewalled? (diagnosis) ==

<syntaxhighlight lang="bash">
# Watch the drop log live (rules log with prefix "nft drop: ")
sudo journalctl -kf | grep 'nft drop'

# Recent drops
sudo journalctl -k --since "1 hour ago" | grep 'nft drop'

# Counters: add a counter to a rule temporarily, or check conntrack
sudo conntrack -L | grep <ip> # is there an established session?
</syntaxhighlight>

Remember: broadcast/multicast is dropped '''silently''' (no log). Everything else that's dropped is logged at max 5/minute — absence of log lines does not mean absence of drops during a flood.

== TRAVEL SCENARIO: my current IP can't SSH in ==

Options, in order of preference:

# '''UCI VPN''' — connect, then SSH from the VPN address (10.0.0.0/8 and campus ranges are in <code>$ssh_nets_v4</code>).
# '''IPMI console''' — log in via BMC, then fix from the console.
# '''Temporary runtime rule''' from the console (does NOT survive reload/reboot):

<syntaxhighlight lang="bash">
# Allow one address into SSH, inserted before the drop logic takes effect
sudo nft insert rule inet filter input ip saddr <MY.IP.ADDR.HERE>/32 tcp dport 22 ct state new accept

# Verify
sudo nft list chain inet filter input

# Remove it later: find its handle, then delete
sudo nft -a list chain inet filter input
sudo nft delete rule inet filter input handle <N>
</syntaxhighlight>

For a permanent change, edit <code>$ssh_nets_v4</code> in <code>/etc/nftables.conf</code>, check, reload (see above). Runtime rules are lost on the next <code>reload</code> because the config starts with <code>flush ruleset</code>.

== Emergency: firewall is broken / I need it out of the way ==

<syntaxhighlight lang="bash">
# From the IPMI console ONLY — this leaves the box wide open:
sudo nft flush ruleset

# Restore known-good config
sudo nft -c -f /etc/nftables.conf && sudo nft -f /etc/nftables.conf
</syntaxhighlight>

== Reload interactions ==

* <code>flush ruleset</code> (any reload) '''wipes fail2ban's ban sets''' too. Restore them: <code>sudo systemctl restart fail2ban</code>
* Established connections (incl. your live SSH session) survive reloads — they match <code>ct state established</code>, not the <code>new</code> rules.

== After-reboot sanity check ==

<syntaxhighlight lang="bash">
systemctl is-active nftables && sudo nft list ruleset | head -20
</syntaxhighlight>

Empty ruleset after boot = config failed to parse = sshd exposed to everything. Check <code>journalctl -u nftables -b</code> for the parse error.

== Config gotchas (this file specifically) ==

* Comment block and <code>define ssh_nets_v4</code> must be kept in sync — every CIDR needs a documented reason.
* ICMPv6 rules are load-bearing: IPv6 breaks without NDP/PMTU. Don't trim.
* <code>output</code> policy is accept (egress open) — intentional, matches old script.
* SSH rate-limiting is fail2ban's job, not nft's. Don't add limit rules to the SSH accept line; they'll fight with ThinLinc multi-connections.

[[Category:Sysadmin]]
[[Category:Cheat sheets]]

Fail2ban

Scott — Thu, 02 Jul 2026 22:48:10 GMT

Created page with "= fail2ban Cheat Sheet = Config: <code>/etc/fail2ban/jail.local</code> (jails) · <code>/etc/fail2ban/fail2ban.local</code> (daemon) Backend: '''systemd journal''' (not log files) · Ban action: '''nftables''' Jail: <code>sshd</code> · maxretry 4 · findtime 10m · bantime 1h Bans trigger on '''auth failures''', not connection counts. == Status & inspection == <syntaxhighlight lang="bash"> # Daemon alive? sudo systemctl status fail2ban sudo fail2ban-client ping..."

New page

= fail2ban Cheat Sheet =

Config: <code>/etc/fail2ban/jail.local</code> (jails) · <code>/etc/fail2ban/fail2ban.local</code> (daemon)

Backend: '''systemd journal''' (not log files) · Ban action: '''nftables'''

Jail: <code>sshd</code> · maxretry 4 · findtime 10m · bantime 1h

Bans trigger on '''auth failures''', not connection counts.

== Status & inspection ==

<syntaxhighlight lang="bash">
# Daemon alive?
sudo systemctl status fail2ban
sudo fail2ban-client ping # should answer "pong"

# Which jails are running?
sudo fail2ban-client status

# The sshd jail: current bans, totals, failure counts
sudo fail2ban-client status sshd

# Watch fail2ban's own log live
sudo journalctl -u fail2ban -f

# See the auth failures fail2ban is reading (same source it uses)
sudo journalctl -u ssh --since "1 hour ago" | grep -i fail
</syntaxhighlight>

== Bans: check / remove / add ==

<syntaxhighlight lang="bash">
# Is a specific IP banned? (listed under "Banned IP list")
sudo fail2ban-client status sshd

# UNBAN an address (the "I locked myself out" fix — run from IPMI console)
sudo fail2ban-client set sshd unbanip <ip>

# Unban everything in the jail
sudo fail2ban-client unban --all

# Manually ban an address
sudo fail2ban-client set sshd banip <ip>
</syntaxhighlight>

The actual block lives in nftables — verify with:

<syntaxhighlight lang="bash">
sudo nft list ruleset | grep -A5 f2b
</syntaxhighlight>

== TRAVEL SCENARIO: I banned myself ==

Symptoms: SSH connects then drops instantly, or times out, from one specific location — while the VPN or another network works fine.

# Get in another way (UCI VPN, IPMI console, or another host).
# <code>sudo fail2ban-client status sshd</code> → confirm your IP is listed.
# <code>sudo fail2ban-client set sshd unbanip <your-ip></code>
# Fix whatever failed auth 4× in 10 min (wrong key? stale agent? password typos?). Otherwise you'll be banned again in minutes.
# Worst case, do nothing: bantime is '''1 hour''', then it clears itself.

Note: with the minimal <code>ignoreip</code>, your travel IPs are NOT exempt. Four bad auth attempts from the hotel wifi = 1-hour ban. Use keys, and check <code>ssh -v</code> output before retrying blindly.

== Config changes ==

<syntaxhighlight lang="bash">
# Test config without applying
sudo fail2ban-client -t

# Reload after editing jail.local (keeps existing bans by default)
sudo fail2ban-client reload

# Full restart (re-reads everything; bans are restored from the
# persistent sqlite DB at /var/lib/fail2ban/fail2ban.sqlite3)
sudo systemctl restart fail2ban
</syntaxhighlight>

== Interaction with nftables ==

* Any <code>nft flush ruleset</code> / <code>systemctl reload nftables</code> '''wipes the f2b ban sets'''. fail2ban still ''thinks'' they're banned. Fix: <code>sudo systemctl restart fail2ban</code> after firewall reloads.
* Ban actions: <code>nftables-multiport</code> (per-jail ports), <code>nftables-allports</code> for allports bans.

== Current policy notes (jail.local) ==

* <code>ignoreip</code> — keep minimal: loopback + witchetty's /32 (backup source). Anything listed here can brute-force sshd forever without a ban.
* Consider <code>bantime.increment = true</code> in <code>[DEFAULT]</code> for escalating bans on repeat offenders.
* <code>allowipv6 = auto</code> lives in '''fail2ban.local''' <code>[Definition]</code>, not jail.local (daemon setting, silences the startup warning).

== Quick triage flowchart ==

<pre>
Can't SSH in?
├─ Works from VPN but not current IP?
│ ├─ IP not in $ssh_nets_v4 → nft issue (see nft sheet: temp rule)
│ └─ IP in allowed range → probably banned → unbanip
├─ Works from nowhere?
│ ├─ nftables ruleset empty/broken → nft sheet, IPMI console
│ └─ sshd itself down → journalctl -u ssh -b
└─ Connects but auth fails? → not a firewall problem; check keys/PAM
</pre>

[[Category:Sysadmin]]
[[Category:Cheat sheets]]

Main Page

Scott — Thu, 02 Jul 2026 22:46:54 GMT

Packages and Commands

← Older revision		Revision as of 22:46, 2 July 2026
Line 68:		Line 68:

	[[emacs]] \|		[[emacs]] \|
			[[fail2ban]] \|
	[[fastcgi++]] \|		[[fastcgi++]] \|
	[[find]] \|		[[find]] \|
Line 86:		Line 87:
	[[netplan]] \|		[[netplan]] \|
	[[nfs4]] \|		[[nfs4]] \|
			[[nftables]] \|
	[[nginx]] \|		[[nginx]] \|
	[[openclaw]] \|		[[openclaw]] \|

Firewall config 2026

Scott — Thu, 02 Jul 2026 22:46:13 GMT

Replaced content with "nftables fail2ban"

← Older revision		Revision as of 22:46, 2 July 2026
Line 1:		Line 1:
	~~# fail2ban Cheat Sheet~~		[[nftables]]

	~~Config: `/etc/fail2ban/jail.local` (jails) · `/etc/fail2ban/fail2ban.local` (daemon)~~		[[fail2ban]]
	Backend: systemd journal (not log files) · Ban action: nftables
	~~Jail: `sshd` · maxretry 4 · findtime 10m · bantime 1h~~
	~~Bans trigger on auth failures, not connection counts.~~

	~~---~~

	~~## Status & inspection~~

	~~```bash~~
	~~# Daemon alive?~~
	~~sudo systemctl status fail2ban~~
	~~sudo fail2ban-client ping # should answer "pong"~~

	~~# Which jails are running?~~
	~~sudo fail2ban-client status~~

	~~# The sshd jail: current bans, totals, failure counts~~
	~~sudo fail2ban-client status sshd~~

	~~# Watch fail2ban's own log live~~
	~~sudo journalctl -u~~ fail2ban -f

	~~# See the auth failures fail2ban is reading (same source it uses)~~
	~~sudo journalctl -u ssh --since "1 hour ago" \| grep -i fail~~
	~~```~~

	~~## Bans: check / remove / add~~

	~~```bash~~
	~~# Is a specific IP banned? (listed under "Banned IP list")~~
	~~sudo fail2ban-client status sshd~~

	~~# UNBAN an address (the "I locked myself out" fix — run from IPMI console)~~
	~~sudo fail2ban-client set sshd unbanip <ip>~~

	~~# Unban everything in the jail~~
	~~sudo fail2ban-client unban --all~~

	~~# Manually ban an address~~
	~~sudo fail2ban-client set sshd banip <ip>~~
	~~```~~

	~~The actual block lives in nftables — verify with:~~

	~~```bash~~
	~~sudo nft list ruleset \| grep -A5 f2b~~
	~~```~~

	~~## TRAVEL SCENARIO: I banned myself~~

	~~Symptoms: SSH connects then drops instantly, or times out, from one~~
	~~specific location — while the VPN or another network works fine.~~

	~~1. Get in another way (UCI VPN, IPMI console, or another host).~~
	~~2. `sudo fail2ban-client status sshd` → confirm your IP is listed.~~
	~~3. `sudo fail2ban-client set sshd unbanip <your-ip>`~~
	~~4. Fix whatever failed auth 4× in 10 min (wrong key? stale agent?~~
	~~password typos?). Otherwise you'll be banned again in minutes.~~
	~~5. Worst case, do nothing: bantime is 1 hour, then it clears itself.~~

	~~Note: with the minimal `ignoreip`, your travel IPs are NOT exempt.~~
	~~Four bad auth attempts from the hotel wifi = 1-hour ban. Use keys,~~
	~~and check `ssh -v` output before retrying blindly.~~

	~~## Config changes~~

	~~```bash~~
	~~# Test config without applying~~
	~~sudo fail2ban-client -t~~

	~~# Reload after editing jail.local (keeps existing bans by default)~~
	~~sudo fail2ban-client reload~~

	~~# Full restart (re-reads everything; bans are restored from the~~
	~~# persistent sqlite DB at /var/lib/fail2ban/fail2ban.sqlite3)~~
	~~sudo systemctl restart fail2ban~~
	~~```~~

	~~## Interaction with nftables~~

	~~- Any `nft flush ruleset` / `systemctl reload nftables` **wipes the~~
	~~f2b ban sets*. fail2ban still thinks* they're banned. Fix:~~
	~~`sudo systemctl restart fail2ban` after firewall reloads.~~
	~~- Ban actions: `nftables-multiport` (per-jail ports),~~
	~~`nftables-allports` for allports bans.~~

	~~## Current policy notes (jail.local)~~

	~~- `ignoreip` — keep minimal: loopback + witchetty's /32 (backup source).~~
	~~Anything listed here can brute-force sshd forever without a ban.~~
	~~- Consider `bantime.increment = true` in `[DEFAULT~~]~~` for escalating~~
	~~bans on repeat offenders.~~
	~~- `allowipv6 = auto` lives in fail2ban.local `[Definition~~]`,
	~~not jail.local (daemon setting, silences the startup warning).~~

	~~## Quick triage flowchart~~

	~~```~~
	~~Can't SSH in?~~
	~~├─ Works from VPN but not current IP?~~
	~~│ ├─ IP not in $ssh_nets_v4 → nft issue (see nft sheet: temp rule)~~
	~~│ └─ IP in allowed range → probably banned → unbanip~~
	~~├─ Works from nowhere?~~
	~~│ ├─ nftables ruleset empty/broken → nft sheet, IPMI console~~
	~~│ └─ sshd itself down → journalctl -u ssh -b~~
	~~└─ Connects but auth fails? → not a firewall problem; check keys/PAM~~
	~~```~~

Firewall config 2026

Scott — Thu, 02 Jul 2026 22:31:45 GMT

Created page with "# fail2ban Cheat Sheet Config: `/etc/fail2ban/jail.local` (jails) · `/etc/fail2ban/fail2ban.local` (daemon) Backend: **systemd journal** (not log files) · Ban action: **nftables** Jail: `sshd` · maxretry 4 · findtime 10m · bantime 1h Bans trigger on **auth failures**, not connection counts. --- ## Status & inspection ```bash # Daemon alive? sudo systemctl status fail2ban sudo fail2ban-client ping # should answer "pong" # Which jails are running?..."

New page

# fail2ban Cheat Sheet

Config: `/etc/fail2ban/jail.local` (jails) · `/etc/fail2ban/fail2ban.local` (daemon)
Backend: **systemd journal** (not log files) · Ban action: **nftables**
Jail: `sshd` · maxretry 4 · findtime 10m · bantime 1h
Bans trigger on **auth failures**, not connection counts.

---

## Status & inspection

```bash
# Daemon alive?
sudo systemctl status fail2ban
sudo fail2ban-client ping # should answer "pong"

# Which jails are running?
sudo fail2ban-client status

# The sshd jail: current bans, totals, failure counts
sudo fail2ban-client status sshd

# Watch fail2ban's own log live
sudo journalctl -u fail2ban -f

# See the auth failures fail2ban is reading (same source it uses)
sudo journalctl -u ssh --since "1 hour ago" | grep -i fail
```

## Bans: check / remove / add

```bash
# Is a specific IP banned? (listed under "Banned IP list")
sudo fail2ban-client status sshd

# UNBAN an address (the "I locked myself out" fix — run from IPMI console)
sudo fail2ban-client set sshd unbanip <ip>

# Unban everything in the jail
sudo fail2ban-client unban --all

# Manually ban an address
sudo fail2ban-client set sshd banip <ip>
```

The actual block lives in nftables — verify with:

```bash
sudo nft list ruleset | grep -A5 f2b
```

## TRAVEL SCENARIO: I banned myself

Symptoms: SSH connects then drops instantly, or times out, from one
specific location — while the VPN or another network works fine.

1. Get in another way (UCI VPN, IPMI console, or another host).
2. `sudo fail2ban-client status sshd` → confirm your IP is listed.
3. `sudo fail2ban-client set sshd unbanip <your-ip>`
4. Fix whatever failed auth 4× in 10 min (wrong key? stale agent?
password typos?). Otherwise you'll be banned again in minutes.
5. Worst case, do nothing: bantime is **1 hour**, then it clears itself.

Note: with the minimal `ignoreip`, your travel IPs are NOT exempt.
Four bad auth attempts from the hotel wifi = 1-hour ban. Use keys,
and check `ssh -v` output before retrying blindly.

## Config changes

```bash
# Test config without applying
sudo fail2ban-client -t

# Reload after editing jail.local (keeps existing bans by default)
sudo fail2ban-client reload

# Full restart (re-reads everything; bans are restored from the
# persistent sqlite DB at /var/lib/fail2ban/fail2ban.sqlite3)
sudo systemctl restart fail2ban
```

## Interaction with nftables

- Any `nft flush ruleset` / `systemctl reload nftables` **wipes the
f2b ban sets**. fail2ban still *thinks* they're banned. Fix:
`sudo systemctl restart fail2ban` after firewall reloads.
- Ban actions: `nftables-multiport` (per-jail ports),
`nftables-allports` for allports bans.

## Current policy notes (jail.local)

- `ignoreip` — keep minimal: loopback + witchetty's /32 (backup source).
Anything listed here can brute-force sshd forever without a ban.
- Consider `bantime.increment = true` in `[DEFAULT]` for escalating
bans on repeat offenders.
- `allowipv6 = auto` lives in **fail2ban.local** `[Definition]`,
not jail.local (daemon setting, silences the startup warning).

## Quick triage flowchart

```
Can't SSH in?
├─ Works from VPN but not current IP?
│ ├─ IP not in $ssh_nets_v4 → nft issue (see nft sheet: temp rule)
│ └─ IP in allowed range → probably banned → unbanip
├─ Works from nowhere?
│ ├─ nftables ruleset empty/broken → nft sheet, IPMI console
│ └─ sshd itself down → journalctl -u ssh -b
└─ Connects but auth fails? → not a firewall problem; check keys/PAM
```

Main Page

Scott — Thu, 02 Jul 2026 22:28:57 GMT

Linux How-To

← Older revision		Revision as of 22:28, 2 July 2026
Line 134:		Line 134:
	[[How to find a MAC address\|find a MAC address]] \|		[[How to find a MAC address\|find a MAC address]] \|
	[[How to find an executable\|find an executable]] \|		[[How to find an executable\|find an executable]] \|
			[[Firewall config 2026\|firewalls 2026]] \|
	[[How to free kernel memory\|free kernel memory]] \|		[[How to free kernel memory\|free kernel memory]] \|
	[[How to interrogate a computer's hardware\|interrogate a computer's hardware]]		[[How to interrogate a computer's hardware\|interrogate a computer's hardware]]

← Older revision		Revision as of 22:46, 2 July 2026
Line 68:		Line 68:

	[[emacs]] \|		[[emacs]] \|
			[[fail2ban]] \|
	[[fastcgi++]] \|		[[fastcgi++]] \|
	[[find]] \|		[[find]] \|
Line 86:		Line 87:
	[[netplan]] \|		[[netplan]] \|
	[[nfs4]] \|		[[nfs4]] \|
			[[nftables]] \|
	[[nginx]] \|		[[nginx]] \|
	[[openclaw]] \|		[[openclaw]] \|

← Older revision		Revision as of 22:28, 2 July 2026
Line 134:		Line 134:
	[[How to find a MAC address\|find a MAC address]] \|		[[How to find a MAC address\|find a MAC address]] \|
	[[How to find an executable\|find an executable]] \|		[[How to find an executable\|find an executable]] \|
			[[Firewall config 2026\|firewalls 2026]] \|
	[[How to free kernel memory\|free kernel memory]] \|		[[How to free kernel memory\|free kernel memory]] \|
	[[How to interrogate a computer's hardware\|interrogate a computer's hardware]]		[[How to interrogate a computer's hardware\|interrogate a computer's hardware]]