Sitter med en 90+ siders Powerpont-presentasjon som skal ryddes, forbedres og tilpasses oppdragsgivers nye grafiske designspråk.
Alle bilder har hvitt innhold rundt de faktiske bildene og dekker derfor teksturen i den nye fargende bakgrunnen, langt utover det faktiske billedinnholdet. Det var ikke så farlig da alle sidene hadde hvit bakgrunn, men nå må alle bilder innom GIMP før de kan brukes.
Logoen er selvsagt også ny og det er i grunnen ganske mye som skal endres på hver enkelt side.
«Prosjektet» er lovet ferdig i løpet av 2025 og jeg merker at denne selvpålagte fristen frustrerer mer enn hvor tungvint slikt arbeid er i Powerpoint.
Godt man finner trøst i: «Om hundre år er alt glemt…»
Jeg har ved en rekke anledninger hatt stor glede av å styre lyd for bandet DDS – Det Daarlige Selskab. Nå har DDS gitt meg lov til å leke litt med nettsiden deres og jeg er litt stolt av fremgangen.
Nå i jula har det bare vært begrenset tilgang på bilder, video og annet innhold, men heldigvis har jeg klart å legge mine klamme fingre på nok innhold til å ha noe å vise frem.
The word will never be without monkeys scratching our doors, but some are delayed, even deterred by altering the default iptables policy for REJECT to DROP.
Destroy this mad brute Enlist – U.S. Army (1918) vintage poster by Harry R. Hopps. Original public domain image from the Library of Congress. Digitally enhanced by rawpixel.
IMNSHO, there’s a huge difference between REJECT – returning an error message & DROP – whereas my server just drops packets, without waisting time or resources.
The default policy of Fail2ban is REJECT, providing offending monkeys the benefit of seeing the error and catch it early. DROP will silently act like a black hole, forcing the monkey’s script to die or time out, slowing down the process along the way.
For my servers, a DROP policy will aloso potentially free up resources and limit network traffic.
I’ll rarely enforce a DROP policy on LAN hosts, hence they are not exposed on the internet and immidiate feedback are more frendly for internal users and problem solvers.
The magic happens in /etc/fail2ban/jail.local where the [DEFAULT] section cover the basics:
# /etc/feil2ban/jail.local
..
[DEFAULT]
..
# Default banning action (e.g. iptables, iptables-new,
# iptables-multiport, shorewall, etc) It is used to
# define action_* variables.
# Can be overridden globally or per
# section within jail.local file
#banaction = iptables-multiport
banaction = iptables-multiport[blocktype=DROP]
banaction_allports = iptables-allports
If testing reveals that the policy doesnt change, (iptables -L), you have to take a look at different jails further down in jail.local. Policy can be overwritten for spesiffic jails.
The Infinite Monkey Theorem is a thought experiment stating that; a monkey hitting keys randomly on a typewriter for an infinite amount of time would eventually type any given text, like Shakespeare’s complete works, because all possibilities will occur given enough chances.
In my logs, I often find the same hosts probing my doors, despite efforts to block them using sensible ban times, (bantime) and allowed retries, (maxretry):
A short ban time and a few retries will take care of some script kiddies, but servers scratching my doors indefinitely, will eventually get lucky.
# /etc/feil2ban/jail.local
..
[sshd]
#Sensible limits for blocking the most obvious attempts to break in, accounting for some human mistakes.
enabled = true
findtime = 1h
bantime = 30m
maxretry = 5
filter = sshd
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
To mitigate this issue, without banning legitimate users making human mistakes, I’ve set up Fail2ban with 2 different jails and matching filters. The normal default jail takes care of manual probing, without banning unlucky human errors:
To counter script kiddies starting a new probe just minutes after the expired ban time, I’ve set up an identical filter, by copying the default filter into a new filter definition:
Then crate a new jail in /etc/fail2ban/jail.local:
# /etc/feil2ban/jail.local
..
[sshd-persistent]
#Aggressive ban time and retries for blocking hosts that can't seem to stay away
#mode = normal
enabled = true
findtime = 14d
bantime = 7d
maxretry = 7
filter = sshd-persistent
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
NB! I have chosen two different filters in two separate files because I want the ability to apply slightly different filters. By specifying the same filter in both jails, any filter change will affect both jails using the same filter:
# /etc/feil2ban/jail.local
..
[sshd]
#Normal jail for short ban time
enabled = true
findtime = 60m
bantime = 30m
maxretry = 6
filter = sshd
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
..
[sshd-persistent]
#Aggressive ban time and retries for blocking hosts that can't seem to stay away
#mode = normal
enabled = true
findtime = 14d
bantime = 7d
maxretry = 7
filter = sshd
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
It’s even possible to set an infinite ban, by providing a value of «-1» for the ban time:
# /etc/feil2ban/jail.local
..
# Sorry Mack..! :-P
bantime = -1
# maybe give them 11 tries?
maxretry = 11
Please make sure that at least one IP address for a host you can ssh out of is whitelisted in the [DEFAULT] section of /etc/fail2ban/jail.local before testing this…!
