iptables issues met ssh

[Verwijderd]

Ik heb een vps die CentOS 5.2 draait. Ik wil op mijn server graag alle input verkeer blocken, behalve voor SSH/SCP en HTTP. Ik heb daartoe deze regels toegevoegd:

code:

iptables -F INPUT
iptables -I INPUT -p tcp --dport 22 -j ACCEPT
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -P INPUT DROP

Het leek aanvankelijk te werken, maar ssh is nu ineens heel erg sloom. Het verbinden zelf gaat snel, maar na het invoeren van het password krijg ik vaak een timeout (of hij doet het ineens na 20sec oid). Het ligt echt aan de firewall, want als ik iptables even disable met 'service iptables stop', dan werkt ineens alles weer vlekkenloos. Wat kan het probleem zijn?

[Slackware]

Volgens mij moet je de volgorde van de regels beranderen. Eerst de drop regel, dan de rest.

[ Voor 3% gewijzigd door Slackware op 24-01-2009 20:22 ]

[Pogostokje]

Voeg nog even toe dat de eerste rule is:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Let er op dat je met -I aan het begin van de chain toevoegt, en met -A aan het einde. Zorg dat je bovenstaande rule als eerste hebt staan, of in ieder geval boven je andere.

En een belangrijke tip: zeker als je met een VPS werkt ... ik zou je willen aanraden om direkt SSH van poort 22 af te halen naar een andere (voor jou bekende en te onthouden) poort. Zeker bij VPS'en is het zo dat het vaak systemen zijn die 'erbij' genomen worden, en dan staat de beveiliging niet altijd boven aan de prioriteitenlijst. Je zult zien dat er enorm gescanned wordt op poort 22 met de ene attack na de andere, zeker bij VPS providers. Simpelweg SSH op een andere poort zetten voorkomt in ieder geval dat de standaard scriptjes een poging kunnen doen.

[Verwijderd]

wat doet die regel precies? En waarom werkt het niet zonder die regel?

Andere poort voor ssh heb ik inderdaad overwogen, maar het grootste deel van scripting attack komen sowiso via de http binnen. Ik word per dag op ongeveer 100 vulnerable php/cms system gescanned... maarja ik draai verder geen php of iets dergelijks, dus ik waan mezelf redelijk safe...

[ Voor 60% gewijzigd door Verwijderd op 25-01-2009 00:01 ]

[Verwijderd]

Pogostokje schreef op zaterdag 24 januari 2009 @ 20:25:

Je zult zien dat er enorm gescanned wordt op poort 22 met de ene attack na de andere, zeker bij VPS providers. Simpelweg SSH op een andere poort zetten voorkomt in ieder geval dat de standaard scriptjes een poging kunnen doen.

Lekker belangrijk. HTTP en SMTP en alle andere services worden ook belaagd. Zorg voor voldoende sterke authenticatie, controle etcetera. Wat kan het nou schelen als er wat mislukte inlogpogingen in de logs terechtkomen? Als je daarmee zit kun je beter het aantal connecties per tijdseenheid limiteren.

[Pogostokje]

Die regel zorgt er voor dat established en related packets van een opgebouwde tcp-sessie ook binnen mogen komen. Zie ook de man pages voor iptables als je precies de details wilt weten.

Het is redelijk standaard security om je SSH poort te verplaatsen of op een andere manier af te schermen op een server die open en bloot aan internet zit, zeker bij een VPS provider waarbij beheerders vaak denken dat het "maar" om een VPS gaat.
Brute force op poort 22 gebeurt continu, er zijn ook wel SSH exploits bekend maar belangrijk is: er kan altijd morgen een gloednieuwe ontdekt worden. Het kost je 20 seconden om het te wijzigen en je hebt er zelf nooit last van, een gehackte server en dus reinstall van je VPS betekent dat je data kwijt bent en dat je wellicht een hoop gezeur van je provider krijgt wanneer je VPS gebruikt is door iemand om heel veel data te genereren of als hij andere nare dingen heeft gedaan. Dus, je kan het "lekker belangrijk" noemen ... dat zegt alleen maar iets over jou security awareness omdat je er dan van uit gaat dat er dus nooit iets mis kan gaan.

[ Voor 8% gewijzigd door Pogostokje op 24-01-2009 21:04 ]

[Verwijderd]

Als je toch met iptables aan het stoeien bent, zou je ook de recent table kunnen gebruiken om het aantal SSH requests (of HTTP of whatvever) vanaf 1 IPadres te beperken tot bijvoorbeeld max 3 binnen 5 minuten waarna je dat IPadres kunt bannen voor een bepaalde periode.

[Verwijderd]

Pogostokje schreef op zaterdag 24 januari 2009 @ 21:01:

Dus, je kan het "lekker belangrijk" noemen ... dat zegt alleen maar iets over jou security awareness omdat je er dan van uit gaat dat er dus nooit iets mis kan gaan.

Ik vertrouw op de software en algoritmen, niet op de "kans" dat ze je SSH op poort 3951 niet kunnen vinden.

SSH op een andere poort draaien is voor mensen die bang zijn voor logbestanden. Het voegt vrijwel niets toe aan beveiliging, het is alleen dat ze je voordeur wat minder snel kunnen vinden. Dan kun je toch beter de software up to date houden en SSH alleen toestaan vanaf enkele bekende IP adressen.

Brute force aanvallen daar moet je gewoon om lachen. Met fatsoenlijke wachtwoorden is de kans groter dat de server spontaan in brand vliegt dan dat iemand toevallig op het juiste wachtwoord stuit. Servers worden eerder gehackt door gepruts met rechten, instellingen en scripts dan door exploits van bijvoorbeeld Apache of OpenSSH. Dan kun je toch beter daar je aandacht aan besteden, en realiseren dat het veranderen van een poortnummertje de kans slechts verkleint met het aantal bots gedeeld door het aantal bots dat alle poorten afgaat.

[Verwijderd]

Exploits zijn van alle dag. Nog niet heel lang geleden was er ineens een remote exploit voor openSSH op Debian (zie voor details milw0rm.com). Misbruik daarvan wordt toch vooral gedaan door grote ranges af te scannen op port 22, dus het veranderen van je poort verlaagt zeker de kans om gehacked te worden nog voordat je de security patches hebt geinstalleerd.

[ Voor 4% gewijzigd door Verwijderd op 25-01-2009 00:02 ]