mboost-dp1
unknown
Ja, jeg blev også opmærksom på at disse angreb var startet ret aggressesivt igen efter disse nyheder begyndte at poppe frem på internettet.
Men det er vel ikke sådan en rigtig nyhed da jeg regelmæssigt siden 2001 er blevet mødt med lign. angreb. Nu har jeg helt slået SSH fra for alle udenfor mit netværk da jeg sådan set ikke bruger det udefra. Skal jeg tilgå mine maskiner udefra igen bliver det med nøgler og låse :-).
Men det er vel ikke sådan en rigtig nyhed da jeg regelmæssigt siden 2001 er blevet mødt med lign. angreb. Nu har jeg helt slået SSH fra for alle udenfor mit netværk da jeg sådan set ikke bruger det udefra. Skal jeg tilgå mine maskiner udefra igen bliver det med nøgler og låse :-).
Efter jeg flyttede ssh servicen til en anden port, har der ikke været et eneste "attack". Det er en 4-5 måneder siden.
Vi ser det generelt overalt i virksomheden hvor jeg er. De fleste maskiner er udsat for disse "angreb".
Jeg faldt tilfældigvis over:
http://www.linux-support.dk/index.php?id=8
- De har oprettet et script, der tjekker log filen for disse "angreb" og laver en liste med ip-adresser. Ud fra disse adresse er de så igang med, at lave en liste over ip'er som er blevet brugt til disse "angreb". Man kan så ved hjælp af et script hente denne liste ned, og blokere adgang for kendte ip adresser som er blevet brugt.
Og er man yderligere selv angrebet, har man mulighed for enten at indsende sine logs til [email protected] osv.
Just a notice.
Jeg faldt tilfældigvis over:
http://www.linux-support.dk/index.php?id=8
- De har oprettet et script, der tjekker log filen for disse "angreb" og laver en liste med ip-adresser. Ud fra disse adresse er de så igang med, at lave en liste over ip'er som er blevet brugt til disse "angreb". Man kan så ved hjælp af et script hente denne liste ned, og blokere adgang for kendte ip adresser som er blevet brugt.
Og er man yderligere selv angrebet, har man mulighed for enten at indsende sine logs til [email protected] osv.
Just a notice.
#4 næh det er lige præcis det der er problemet.
At bruteforce med dictionary attacts betyder jo netop at man forsøger sig med en ordliste til brugernavn/password indtil man rammer noget der virker.
Hvis du har et delvist random password på 16+ tegn med upper/lowercase samt flere ciffer er du rimelig godt sikret, medmindre angriberen vælger også at bruteforce på sammensatte bogstaver samt tal, dog kan det godt tage et par dage/uger/måneder/år.. :D
At bruteforce med dictionary attacts betyder jo netop at man forsøger sig med en ordliste til brugernavn/password indtil man rammer noget der virker.
Hvis du har et delvist random password på 16+ tegn med upper/lowercase samt flere ciffer er du rimelig godt sikret, medmindre angriberen vælger også at bruteforce på sammensatte bogstaver samt tal, dog kan det godt tage et par dage/uger/måneder/år.. :D
Jeg har lign. problem på min box. Men eftersom man ikke kan logge ind direkte med root og man skal bruge en privatekey samt en ganske mærkværdig adgangskode så sover jeg trygt om natten :-) Det kan klart anbefales at bruge nøgler/keys istedetfor rene adgangskoder.
Tilret også altid /etc/sshd/sshd.conf således at tyveknægtene bliver overaskede. :-)
Tilret også altid /etc/sshd/sshd.conf således at tyveknægtene bliver overaskede. :-)
#5: 16 tegn giver kun 128 bit... hvilket så bliver hvad krypteringen er.
Mere end 16 tegn er det nok de færeste der kan huske (hvis man vel og mærke ikke må bruge directory-ord o.l.).
Den rigtigste måde at få en god kryptering, må være at tage de 256 tegn (aka 2048 bit kryptering som eksempel) og få dem printet på sin negl. Derved er man relativt sikker på at være til stede når nogen logger ind på 'puteren :)
Men som sagt, kryptering er ubrugeligt hvis nøglen er et kodeord brugeren skal kunne huske.
Mere end 16 tegn er det nok de færeste der kan huske (hvis man vel og mærke ikke må bruge directory-ord o.l.).
Den rigtigste måde at få en god kryptering, må være at tage de 256 tegn (aka 2048 bit kryptering som eksempel) og få dem printet på sin negl. Derved er man relativt sikker på at være til stede når nogen logger ind på 'puteren :)
Men som sagt, kryptering er ubrugeligt hvis nøglen er et kodeord brugeren skal kunne huske.
På arbejdet bruger vi token validering, med personligt brugernavn + personlig kode + 6-cifret talkode der skifter hvert minut.
Mon ikke man også kan købe noget lignende som privatperson?
Vores system er RSA SecurID
Mon ikke man også kan købe noget lignende som privatperson?
Vores system er RSA SecurID
Lås for SSH tilgang fra den IP i 5 minutter, hvis der er mere end 3 forkerte logins i træk - Så er de fleste scripts vidst hægtet af.
Enig med #11. Det eneste der er interessant ved disse angreb er performance. Hvis de med en lille forespørgsel kan få ens server til at bruge mange resourcer på at validere den, kan man blokke på IP adresse eller andet.
Mht til sikkerheden synes jeg ikke man skal blokke. Her gælder det bare om at have et sikkert nok password. SSH burde være lavet sådan at den ikke siger den eksisterer, før den får et login der er rigtigt. Hvis SSH ikke virker på denne måde, bør man skifte protokol, istedet for at prøve at lave billige lappeløsninger, såsom at skifte port.
Mht til sikkerheden synes jeg ikke man skal blokke. Her gælder det bare om at have et sikkert nok password. SSH burde være lavet sådan at den ikke siger den eksisterer, før den får et login der er rigtigt. Hvis SSH ikke virker på denne måde, bør man skifte protokol, istedet for at prøve at lave billige lappeløsninger, såsom at skifte port.
Der er mange måder man kan begrænse tingene på.
. Source Ip'er i ens Firewall
. Begræns antal connections ( f.eks. 5 førsøg på 24 timer )
. Sæt SSH op, så kun bestemte brugere må connect.
. DSA/RSA key kun
. Vælge et ordenligt Passwd
. Ændre ssh port
Så det op til hver person og vælge hvor meget man vil begrænse det, men idag er et ordenlig passwd faktisk nok.
Men og ændre ssh porten mener jeg er en lappe løsning, efter min mening er DSA/RSA keys helt klart den bedste løsning.
Men kræver også man passe på sin key :)
Men er som regel heller ikke "nørder" der blir ramt af scripts, snarere folk der ikke har forstand på hvad de laver som hurtig sætter noget op og glemmer alt om sikkerhed :(
. Source Ip'er i ens Firewall
. Begræns antal connections ( f.eks. 5 førsøg på 24 timer )
. Sæt SSH op, så kun bestemte brugere må connect.
. DSA/RSA key kun
. Vælge et ordenligt Passwd
. Ændre ssh port
Så det op til hver person og vælge hvor meget man vil begrænse det, men idag er et ordenlig passwd faktisk nok.
Men og ændre ssh porten mener jeg er en lappe løsning, efter min mening er DSA/RSA keys helt klart den bedste løsning.
Men kræver også man passe på sin key :)
Men er som regel heller ikke "nørder" der blir ramt af scripts, snarere folk der ikke har forstand på hvad de laver som hurtig sætter noget op og glemmer alt om sikkerhed :(
#16: ". Begræns antal connections ( f.eks. 5 førsøg på 24 timer )"
... hvilket gør DOS angreb ekstremt nemt.
Personen skal bare lave 5 mislykkede forsøg på at connecte til din server om dagen, og han har effektivt sørget for at du aldrig mere kan komme ind på din server.
... hvilket gør DOS angreb ekstremt nemt.
Personen skal bare lave 5 mislykkede forsøg på at connecte til din server om dagen, og han har effektivt sørget for at du aldrig mere kan komme ind på din server.
Det er vel rimeligt nemt at tage nogle gode forholds regler. Jeg så selv nogle suspekte login-forsøg på min gateway, og så flyttede jeg servicen til en anden port... har ikke haft nogle siden...
De andre som er nævnt her i tråden er da bestemt også værd at tage med, det bliver det i hvert falde ikke ringer af.
De andre som er nævnt her i tråden er da bestemt også værd at tage med, det bliver det i hvert falde ikke ringer af.
jeg har 32characters password - good luck bruteforcing det :) ihvertfald før jeg er død :)
jeg opdagede det også, så jeg nmappede ip'en det kom fra, og så han kørte en ftpd, så jeg prøvede at logge ind med brugernavn som truende beskedder, om at jeg ville gå til angreb på ham :) ca 1 minut efter stoppede det :) jeg går ud fra han havde en tail på ftp'en log :D
jeg opdagede det også, så jeg nmappede ip'en det kom fra, og så han kørte en ftpd, så jeg prøvede at logge ind med brugernavn som truende beskedder, om at jeg ville gå til angreb på ham :) ca 1 minut efter stoppede det :) jeg går ud fra han havde en tail på ftp'en log :D
Jer der nu fangler nogle syndere, der bruteforcer. Kunne i ikke tænke jer, at smide jeres logs videre til folket bag [email protected]. De prøver nemlig på, at samle en liste over de ip adresser som bliver brugt til disse bruteforce attemps.
#22 Når jeg bruteforcer. Så bruger jeg som regl en anden linie. Fx en wireless linie som jeg har fundet ved at wardrive. Eller også bruger jeg en dynamisk IP eller proxy/zombier.
Så alt i alt kan jeg ikke se hvad det skulle hjælpe? Men fair nok. Hvis de har lyst til at gøre det må det da være op til dem :)
Så alt i alt kan jeg ikke se hvad det skulle hjælpe? Men fair nok. Hvis de har lyst til at gøre det må det da være op til dem :)
Hmm
Hvad med bare at sætte dit firewall script op så du ikke modtager ssh forbindelser fra MAC addresser som du ikke kender.
Det trick brugte jeg selv da jeg var administrator på en skole, smatidig med at jeg lukkede total ned for alle rundt 22 tiden via et automatisk setup i Et Iptables script alle på nær mig selv, jeg kan ikke lige huske hvordan det var men der er en af parameterne som tillader dig at sætte en timeing på.
Hvad med bare at sætte dit firewall script op så du ikke modtager ssh forbindelser fra MAC addresser som du ikke kender.
Det trick brugte jeg selv da jeg var administrator på en skole, smatidig med at jeg lukkede total ned for alle rundt 22 tiden via et automatisk setup i Et Iptables script alle på nær mig selv, jeg kan ikke lige huske hvordan det var men der er en af parameterne som tillader dig at sætte en timeing på.
#12:
Det kan bare ikke lade sig gøre, hvis man vil have en sikker protokol der understøtter kryptering. Man bliver nødt til at have en form for indledende handshake, når server og klient skal udveksle public keys til brug ved kryptering.
SSH burde være lavet sådan at den ikke siger den eksisterer, før den får et login der er rigtigt. Hvis SSH ikke virker på denne måde, bør man skifte protokol, istedet for at prøve at lave billige lappeløsninger, såsom at skifte port.
Det kan bare ikke lade sig gøre, hvis man vil have en sikker protokol der understøtter kryptering. Man bliver nødt til at have en form for indledende handshake, når server og klient skal udveksle public keys til brug ved kryptering.
#25
Tror ikke du læste hele min besked.
Udvekslingen af keys ville så i dette tilfælde først ske efter at man har sendt sit password.
Det kunne gøres ved at man krypterer en streng + plus noget random data med sit password, det sender man til serveren sammen med sit brugernavn, serveren dekrypterer med passwordet, hvis der er den rigtige streng og noget random der ikke har været brugt før, ved man at brugeren har et rigtigt password der ikke er et replay attack. Herefter udveksler man nøgler i normal ssh manér.
Tror ikke du læste hele min besked.
stedet for at prøve at lave billige lappeløsninger, såsom at skifte port.
Udvekslingen af keys ville så i dette tilfælde først ske efter at man har sendt sit password.
Det kunne gøres ved at man krypterer en streng + plus noget random data med sit password, det sender man til serveren sammen med sit brugernavn, serveren dekrypterer med passwordet, hvis der er den rigtige streng og noget random der ikke har været brugt før, ved man at brugeren har et rigtigt password der ikke er et replay attack. Herefter udveksler man nøgler i normal ssh manér.
En lille forsinket besked: Brug "portsentry". Det findes til linux i hvert fald, ved ikke om noget lignende findes til windows. Men "portsentry" blokerer i hvert fald FULDSTÆNDIG for adgang til din maskine fra en IP hvis denne IP scanner dig eller DoS'er dig, ell. lign. Jeg er sikker på den kan konfigureres til at blokkere en IP hvis denne forsøger at logge på SSHd 5-6 gange indenfor 10-20 sekunder.
Måden portsentry blokkerer IPer på er via /etc/hosts.deny .. Altså de bliver nægtet adgang helt og aldeles til systemet.
Måden portsentry blokkerer IPer på er via /etc/hosts.deny .. Altså de bliver nægtet adgang helt og aldeles til systemet.
En anden løsning, som jeg selv finder mere elegant end portsentry og diverse log greppere, er recent modulet til iptables.
Google: ssh iptables "-m recent"
Med recent kan du f.eks. bestemme at tre ssh connections indenfor et minut er for meget, og derefter blokere al traffik fra den pågældende ip i f.eks. 10 minutter. Det er ret effektivt, og jeg har endnu ikke haft problemer med det. Kommer man til at lave for mange "lovlige" connections, så venter man bare 10 minutter, og så kan man prøve igen.
Google: ssh iptables "-m recent"
Med recent kan du f.eks. bestemme at tre ssh connections indenfor et minut er for meget, og derefter blokere al traffik fra den pågældende ip i f.eks. 10 minutter. Det er ret effektivt, og jeg har endnu ikke haft problemer med det. Kommer man til at lave for mange "lovlige" connections, så venter man bare 10 minutter, og så kan man prøve igen.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund