Date: Tue, 2 Nov 2004 13:49:17 +0100 From: Flemming Frøkjær <none@flemmingf--gmail.com.lh.bsd-dk.dk> To: bsd-dk@bsd-dk.dk Subject: Re: Securing sshd against unwanted login attempts
On Sun, 31 Oct 2004 16:53:37 +0100, Erik Norgaard <none@norgaard--locolomo.org.lh.bsd-dk.dk> wrote:
> Flemming Frøkjær wrote:
> >>Denne løsning løser intet. Nu vil du så se en masse forsøg på at gætte
> >>port-knocking sekvensen. Det har jo sådan set ikke rigtig løst dit
> >>problem, det har bare erstattet det med et andet.
> >
> > Forkert. De skal jo foerst vide at der er en port knocking daemon som
> > lytter, og hvilke porte der monitoreres.
>
> Ligesom at man først skal vide at der er en ssh daemon og gætte den
> rigtige sekvens af tegn i kodeordet.
Du kan scanne et firewall og se at der køre en ssh daemon, også selv
om den ikke kører på port 22. nmap -p 0-65535 host
Når du kender de åbne porte er det trivielt at finde ud af hvilke
services der kører på hvilke porte. Med port knocking har du en stelth
server som aldrig returnerer noget.
> > Hvorfor skulle jeg ikke kunne kryptere port knocking koden?
>
> Port-knocking fungerer ved at du sender pakker til bestemte porte i en
> bestemt rækkefølge. Det svarer til at indtaste en pin-kode, og enhver
> kan kigge dig over skulderen. Det er port-numrene der er koden. Og der
> er ikke noget brugernavn.
Ide'en her var at du skulle læse på medsendte link før du farer i blæk
huses og kretiserer noget du helt åbentlyst ikke har fatte en lyd af,
men da du åbenbart har for travlt med at gentage batmules iøvrigt
gangske udemærkede råd om sikring af en ssh daemon, så vil jeg for en
gang skyld lede dig lidt på vej.
Hvis vi antager at banke sekvensen er din IP addresse's 4 okteter,
antal minutter du vil have mulighed for at logge ind, time of day i
hele minutter og endelig et crc check. Derefter kan data krypteres med
eks blowfish.
Port knocking daemonnen prøver derefter at dekryptere alle port
knocking sekvenser. Hvis der lykkedes og crc verdien passer har du en
valid port knocking sekvens.
> Port-knocking er ikke state-full som en ssh-forbindelse. Man sender bare
> et antal udp (eller tcp?) pakker til bestemte porte i en bestemt række-
> følge. Du får ingen pakker igen, men serveren åbner for adgang til
> service fra dit ip.
Du sender kun en syn pakke.
> Dermed bliver firewall eller serveren usynlig for standard port-scan-
> ninger.
Hvilket var hele pointen!
> Du kan opnå det samme og bedre ved i stedet at sende en udp-pakke (der
> jo heller ikke er state-full) med en krypteret payload - du har jo 1500
> bytes til rådighed. Data er krypteret med på forhånd delte nøgler og kan
> indeholde identifikation og anden data så den ikke kan spoofes.
Det samme kan opnåes ja. Om det er bedre kan diskuteres.
> Medmindre du har store resourcer til at forfølge alle der forsøger at
> logge ind, så er det normalt først seriøst når login lykkedes. Der er
> rimelig nemt at sortere de mislykkede forsøg fra.
Hvilken planet kommer du fra? Kalder du dig sikkerheds konsulent? Det
er ikke seriøst før folk er kommet ind? Der findes mange script
kiddies der ude, og en port scanning er normal, men hvis du er bare
lidt seriøs med din sikkerhed undersøger du alt der ikke ser normalt
ud.
> port-knocking software er ikke særlig udbredt, så hvis du bruger dette
> kan det blive svært for dig at logge ind når du er på rejse. Men alle
> kan hente putty og logge på en anden port.
Det kommer jo and på hvad du skal bruge det til. På mine servere er
det kun administratorer der kan logge ind via ssh, og dem er der
sjældent mere end 3 af.
En port knocking klient skrevet i perl fylder ikke meget og kan
medbringes på en USB nøgle. Igen det handler om hvad der passer til
situationen.
> Alternativt, så kan Snort være reaktiv og lukke forbindelser der bryder
> reglerne ved eksempelvis at etablere mange forbindelser.
Du kan også køre en level 7 firewall. Fuldstendig lukke for ssh og så
ringe til den administrator der har vagt hvis der er problemer, samt
100 andre senarier. Det afhænger af den enkelte situation hvad der er
en passende løsning.
This archive was generated by hypermail 2b30 : Wed 15 Nov 2006 - 18:24:46 CET