I forsøget på at blive alene på sin VPS er her nogle lidt stærkere tiltag. Det første er IPtables;

IPtables kan sættes op således at det kan bruges til at blokke SSH angreb. Følgende reglsæt har jeg fundet på en blog af Andrew Pollock og det tillader max 3 connections pr. minut fra hvilken som helst host. Overskrides disse regler blokkes den host i et minut.

Typiske brute force angreb, når man kigger i sin log fil, er jo 100 forsøg med gennemsnitligt et sekund mellem hvert, så nedenstående tillader 3 og så lukkes der - 98% af tilfældene smutter hackeren igen.

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP

I tilføjelse til Andrews definition - kan man jo godt gå hen og blive små #¤%!" på nogen af de kejle polakker der via der nedslidte ADSL forbindelse stadig forsøger. Heldigvis er der råd for det;

iptables -A INPUT -s $IPADRESSE -j REJECT

Så kan de lære det! Hvis man derimod ønsker en liste over godkendte hosts, sammen med førnævnte regler, er her en variation der også fundet på Andrews blog:

(1) Opret en gruppe over godkendte først:

iptables -N SSH_WHITELIST

(2) tilføj herefter hvilken somhelst host(s):

iptables -A SSH_WHITELIST -s IPADRESSE -m recent --remove --name SSH -j ACCEPT

(3) tilføj herefter regler for afvisninger:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set  --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
 --seconds 60 --hitcount 4 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update 
 --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Ovenstående virker fint i et Dedicated miljø, desværre tillader Virtual Environments ikke -m som option til IPtables - derfor er undertegnede i dette tilfælde nødt til at nøjes med Blockhosts.

 

Jeg kører jo bl.a. med blockhosts på mit system - dvs. hvergang en eller anden fejler på f.eks login et antal gange bliver ip adressen tilføjet hosts.allow. Blockhosts udemærker sig ved man i konfigurations filen kan specificere metode brug. Ved brug af IPtables i samspil med blockhosts, kan jeg nu helt effektivt sætte TCP/IP blokkering op vha. IPtables pakke filtrering. I blockhosts.cfg der ligger i /etc udkommenteres blot linien #IPBLOCK = "iptables" og så skulle det være på plads, således vil en hacker på samme subnet også ville blive blokket.

Afvikling af blockhosts ser således ud efterfølgende;

[hosting:/etc]/usr/bin/blockhosts.py --verbose
blockhosts 2.0.3 started: 2007-06-21 10:04:11 CEST
 ... load blockfile: /etc/hosts.allow
 ... found both markers, count of hosts being watched: 11
 ... loading log file, offset: /var/log/secure 63459
 ... will discard all host entries older than  2007-05-22 10:04:11 CEST
 ... updates: counts: hosts to block: 5; hosts being watched: 11
 ... created user-defined chain blockhosts
 ... creating jump from INPUT to blockhosts chain
 ... iptables, adding rule to block:  200.85.34.166

og så fremdeles tilføres IPtables regler for de IPadresser der er afvist i hosts.allow filen.

En anden måde er at sætte systemmet op til at benytte RSA authorisation ved login. Det betyder at du genererer RSA nøgler - og brute force forsøg på at finde valide passwords vil derfor være nytteløs da de ikke eksisterer, du bruger jo nøgler istedet.

Ulemperne er først og fremmest at der er nødvendigt du har din RSA nøgle med, hvis du vil logge ind fra en anden maskine. Ligeledes hvis du ikke er teknikker, kan det nok virke svært at lave nøglerne. Hvis nogen ved et tilfælde finder din private RSA nøgle, kan man jo logge ind, til hviklen somhelst maskine, hvor den tilhørende offentlige nøgle ligger.

(1) Du genererer en RSA nøgle med ssh-keygen -t rsa. Dette laver filerne /home/username/.ssh/id_rsa (den private nøgle) samt /home/username/.ssh/id_rsa.pub (den offentlige nøgle).

[hosting:/etc]ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
The key fingerprint is:
32-digit_hexadecimal_fingerprint username@hostname

(2) Dernæst på hver maskine hvor til du vil kunne logge ind kopierer du /home/username/.ssh/id_rsa.pub ind i /home/username/.ssh/authorized_keys. Denne fil kan indeholde flere end en nøgle - det er smart at konkatenere nøglerne.

[hosting:/etc]cat /home/username/.ssh/id_rsa >> /home/username/.ssh/authorized_keys

(3) På hver maskine hvor fra du vil kunne logge ind fra placerer du /home/username/.ssh/id_rsa i kataloget /home/username/.ssh/.

(4) Slutteligt sætter du PasswordAuthentication no (nu bruger vi jo ikke længere passwords)i /etc/ssh/sshd_config, og genstarter sshd demonen /etc/init.d/sshd restart