SSh en Beveiligen

Overigens, als je server op afstand staat, en je maakt een foutje met je firewall of je ssh-daemon, dan kan je jezelf buitensluiten... Ook iets om voor op te passen...

Buiten sluiten omdat je een foutje maakt met je firewall is eenvoudig te voorkomen. Ik heb zelf wel eens in die situatie gezeten en daar leer je snel van . Dit script gebruik ik tegenwoordig als ik een nieuw firewall script laad of m'n huidige script heb geupdate:

#!/bin/bash

# A simple script which calls an iptables config script (given in $1) and then
# sleeps for 30, and then resets iptables config, so you never lock
# yourself out. The firewall is completly open after those 30 seconds.

IPTABLES='/sbin/iptables'

./$1
sleep 30s
$IPTABLES --flush
$IPTABLES --delete-chain
$IPTABLES -P INPUT ACCEPT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P FORWARD ACCEPT

Ik heb dat script opgeslagen in het bestand iptables_test en heb ik execute rechten gegeven. Mijn iptables config zet ik altijd in iptables_setup. Om het te testen kom je dus op dit commando uit:

./iptables_test iptables_setup

Als je jezelf dan buiten sluit hoef je alleen maar 30 seconden te wachten en je komt er weer bij. Ik ben al een paar keer erg blij geweest met dit simpele script .
Misschien is er een kans dat je de variabele IPTABLES moet bijwerken met de lokatie van jouw iptables commando, maar dat verwacht ik niet eigenlijk.

Ennuh, Pascal: ik ben het toch niet helemaal eens met je statement dat een firewall overbodig is. Ik zet op m'n servers altijd een zeer stricte firewall op m'n doos. Ik zet niet alleen verkeer naar binnen 100% dicht, maar ook verkeer naar buiten is 100% geblokkeerd. Daarna ga ik wat gaatjes erin schoppen. TCP80 inkomend moet vaak open. TCP25 inkomend vaak ook. Uitgaand zet ik TCP80 naar ftp.nl.debian.org open en UDP53 naar de DNS server. Op die manier reguleer ik dus, tot in het extreme, wat voor verkeer er komt en gaat vanaf de server. Als er dan eens een veiligheidslek in een PHP app zit die erop draait en een of andere deus probeert allerlei troep te downloaden dan lukt dat gewoon niet. De firewall blokkeert. Uiteraard is dit een van de vele schakels in de security maatregelen. Dingen als fail2ban zijn ook leuk op Apache. Snort kan ook wel wat uitmaken. En uiteraard zinnige permissies op directories en files die binnen de webroot staan.

Thanks voor jullie tips en adviezen en natuurlijk de handig links, alleen als ik zoveel text ziet dan lijkt het allemaal erg ingewikkeld
ik kan inderdaad de server alleen via ssh bereiken, het is een linux server met centos5 bestuuringsysteem, het is voor mij ook mogelijk om in te loggen in solusvm en directadmin die al erop zit, overigens de server is alleen bedoeld voor 2 site van mij..

Ieder geval ik ga maar eens wat tijd vrij maken voor beveiligen van mijn server, ik laat jullie nog weten hoe het gegaan is
Tess

De root user zou ik niet verwijderen. Dan gaat er toch wel het een en ander mis in je machine (als je je machine boot start alles als root bijv. Als je geen root meer hebt, dan kan er niets meer starten tijdens de boot. Een situatie waar je niet zo vrolijk van wordt ). Wat je kan doen is ervoor zorgen dat je met SSH standaard niet als root in kan loggen. Hij bestaat dan nog wel gewoon, maar de SSH Deamon vind bij de user "root" dan gewoon dat er altijd een fout wachtwoord wordt ingevuld.
Verder zie ik dat je de user "tess" maar gewoon root rechten wil geven. Dan ga je dus met je daily user beheers rechten geven. Dat is nergens voor nodig en alleen maar gevaarlijk. Als je ff wat aan wil passen aan je website, waarom zou je dat dan moeten gaan doen met een gebruiker die de rechten heeft om je disken te formateren? Nergens voor nodig. Al je dagelijkse werk doe je met een user die nergens recht toe heeft. Pas als het beheerswerk wordt (dus Apache configgen, backups instellen, controleren of terugzetten, enz.) dan ga je met een gebruiker werken die beheers rechten (dus root) nodig heeft.

Centos5 is een prima systeem m.i. Firewall en de open poorten kun je tegelijk regelen via het interactieve commando setup (ideaal). Sterker.... doe je dat daar niet tegelijk dan kun je jezelf buitensluiten. Altijd minimaal poort 22 open houden!!!!

En die lading tips.... tja... de hoeveelheid moet je met een korreltje zout nemen... echter de intentie erachter niet

heel simpel, als je niet precies weet wat je doet en je bent bang dat je jezelf buitensluit (alleen van toepassing voor systemen waar je niet naast zit, want anders kan je altijd inloggen) dan installeer je virtualbox. en daarin installeer je een testlinux om op te prtutsen.

ssh gebruikt poort 22 standaard. Als jij deze loszet naar buiten (dat is, in je router forward. zijn beide systemen op je lokale LAN dan hoef je je geen zorgen te maken) dan kan je deze poort veranderen naar een ander nummer. Anders heb je een grote kans dat je honderden/duizenden inlog pogingen per dag krijgt.

De allerbelangrijkste tips zijn: hou je systeem up2date, gebruik de standaard beveiliging netjes en maak backups. Alle tips daarna zijn voor extra drempels.

Niet direct als root in ssh is wel slim... de hacker moet nu ook de usernaam raden waarmee hij kan inloggen (en dan nog eens root zien te worden). Poort 22 verzetten.... tja... een beetje hacker heeft de juiste poort zo gevonden bij je (drempelje van 2 minuten hoogstens dan).... m.i. een minder effectieve drempel. Je kunt dit doen om scriptkiddies minder aan je deur te hebben en de logs wat schoner te houden.

Zo moet je stapje voor stapje bepalen wat je wel en wat je niet aan extra maatregelen neemt.