Alvorlig hull i Debian

[t_k]

Wow. Dette har jo endt opp til å bli en kjempetråd! Jeg er en student nå. Viste faktisk ikke om all logginga og slike ting. Kjempegreier!

[t_k]

Ble litt paranoid og kjørte chkrootkit. Like greit og lære seg det med en gang tenkte jeg. Fikk ikke opp noen infected eller lignende, men helt på slutten av testen kommer det opp: wlan0: PACKET SNIFFER(/sbin/wpa_supplicant[5986], /sbin/dhclient3[5999])

 

Prøvde og google dette, men fant ikke noe. Hva betyr dette?

[Gjest Slettet+6132]

Ble litt paranoid og kjørte chkrootkit. Like greit og lære seg det med en gang tenkte jeg. Fikk ikke opp noen infected eller lignende, men helt på slutten av testen kommer det opp: wlan0: PACKET SNIFFER(/sbin/wpa_supplicant[5986], /sbin/dhclient3[5999])

 

Prøvde og google dette, men fant ikke noe. Hva betyr dette?

 

Du kan umulig ha googlet på dette, eller kanskje du trenger en FAQ (Google).

 

Regner med at du har trådløst kort/hardware i din PC som din *nix støtter.

 

Ett av *mange* treff i Google.

 

Kan se ut som om chkrootkit anser dette som ett sikkerhetshull (hvilket det faktisk er, gitt default oppsett).

 

Regner med at en av *nix-guruene på forumet kan avklare dette.

[t_k]

Prøvde og google hele "advarselen" eller hva man kan kalle det, for noen lignende, men fant ikke noe. Skal sjekke litt mere. Greit og lære seg sikkerhet skikkelig så man har litt kontroll på ting. Dette er på laptoppen min ja, som er på Wlan.

 

Edit: Ser ut som om dette er ting som skal være slik: http://ubuntuforums.org/showthread.php?t=556517

http://ubuntuforums.org/showthread.php?t=270340

Endret 18. mai 2008 av t_k

[Depressure]

denne artikkelen gjorde meg bare kvalm, det finnes mer i verden enn ubuntu, kubuntu og xubuntu.

 

skulle btw sett ms gjøre noe liknende i samme hastighet =)

Endret 19. mai 2008 av Depressure

[pcp160]

Jeg lurer på en liten ting ang DenyHosts, har installert og lest diverse manualer, FAQ, og HowTos. Det meste jeg fant var gammelt (2006) og jeg slet litt med å komme igang fordi jeg rett og slett ikke fant ting der guidene sa (feks eksempelfilen /usr/share/denyhosts/denyhosts.cfg-dist, som skal bli /usr/share/denyhosts/denyhosts.cfg finner jeg ikke, men derimot /etc/denyhosts.conf) Jeg tror jeg nå har forstått at installasjon/oppsett må ha blitt vesentlig automatisert siden 2006, og ser at den IP som prøvde seg 500 ganger 17/5 nå ligger i hosts.deny uten at jeg har gjort noe mer enn å installere.

 

Det eneste jeg lurer litt på er om DenyHosts også kjører automatisk nå uten at jeg har satt opp noe med cron eller andre ting. Ser at det står DAEMON_SLEEP = 30s i denyhosts.conf og får intrykk av at det betyr at den vil sjekke hvert 30. sekund såfremt jeg kjører i daemon mode (--daemon flag) noe jeg da ikke vet om jeg gjør...

 

@Depressure,

jeg skjønner ikke helt hva du mener, ble du kvalm fordi det viser seg å være et allvorlig sikkerhetshull i Debian, eller var det noe med artikkelen du reagerte på?

[8086]

Fikk mail om dette for mange dager siden fra sys-admen på skolen. Alle som hadde sårbare nøkler fikk ikke lenger automatisk login. Det som overrasket meg var hvor lenge det tok før Ubuntu fikk oppdateringen. Jeg kjørte apt-get update i to dager uten å få en ssh-keygen som genererte usårbare nøkler. Endte med at jeg måtte generere nøklen på en oppdatert Debian server ...

[Deezire]

Det er fordi du må kjøre apt-get dist-upgrade. Vanlig update og upgrade fungerer ikke.

[Del]

Dette var virkelig ikke bra. Håper det blir en oppvask med endring av rutinger i etterkant. Alle mine nøkler var kompromitterte, heldigvis går det fort å generere nye. Howto'en er oppdatert med advarsel og fix.

Er ganske hard for mange å se at det også dukker opp alvorlige sikkerhetshull i Linux-baserte systemer.

 

Selv om dette er patchet nå så er det fremdeles mange systemer som enda ikke er oppdatert. Dette er ett meget stygt sikkerhetshull.

Hvor var du når forrige stygge hull i kjerna ble oppdaget? Du må følge litt bedre med så skal du se at det stadig vekk er noe du kan slenge dritt om, som attpåtil rammer standardoppsett. Oppløftende å se at småligheten stoppet med deg.

[CAT0]

Hvor var du når forrige stygge hull i kjerna ble oppdaget? Du må følge litt bedre med så skal du se at det stadig vekk er noe du kan slenge dritt om, som attpåtil rammer standardoppsett. Oppløftende å se at småligheten stoppet med deg.

Forskjellen er jo at dette er et hull som man kan utnytte utenfra, mens de vanlige sikkerhetshullene går ut på at lokale brukere kan utnytte feil til å få utfyllende rettigheter.

[Del]

Forskjellen er jo at dette er et hull som man kan utnytte utenfra, mens de vanlige sikkerhetshullene går ut på at lokale brukere kan utnytte feil til å få utfyllende rettigheter.

Det er da vel ikke noe nytt i det heller. Du finner sikkert plenty exploits som har rammet LAMP hvis du leter. Ssh har alltid vært utsatt for brute-force ved bruk av dårlige passord for rot.

[CAT0]

Forskjellen er jo at dette er et hull som man kan utnytte utenfra, mens de vanlige sikkerhetshullene går ut på at lokale brukere kan utnytte feil til å få utfyllende rettigheter.

Det er da vel ikke noe nytt i det heller. Du finner sikkert plenty exploits som har rammet LAMP hvis du leter. Ssh har alltid vært utsatt for brute-force ved bruk av dårlige passord for rot.

 

Nei, men da er det dårlig kode i prosjektet som gjør det. Her er det debians pakkehåndterer som har driti på draget, det skjer relativt sjelden.

[Prognatus]

Faktum er at slike sikkerhetsfeil blir fortere rettet i Open Source-miljøet enn hvis det skjer i et proprietært system. Vi har flere eksempler på at f.eks. sikkerhetsfeil i kjente proprietære systemer tar måneder å fikse, og noen ganger sitter også innrømmelsen fra selskapet som lager programvaren langt inne. Vi har også opplevd at folk som finner sikkerhetsfeil i proprietære systemer får kjeft fordi de går ut med det offentlig. Argumentet er da at det er bedre å holde det skjult, så ikke hackere utnytter feilen før den er fikset - hvilket altså ofte tar måneder. Slike selskaper må også tenke på at profitten kan svekkes hvis de får negativ omtale og dårlig rykte.

 

I Open Source-miljøet er det umulig å skjule sannheten på denne måten. Er feilen først oppdaget, vil alle snart vite om det, og man kan endog sjekke koden og se selv hvor feilen er. Da må OS-miljøet fikse den fort!

 

Så synlighet og åpenhet er en bedre modell for å oppdage og fikse slike feil fort.

[Del]

Nei, men da er det dårlig kode i prosjektet som gjør det. Her er det debians pakkehåndterer som har driti på draget, det skjer relativt sjelden.

For all del, men det var ikke poenget mitt. Poenget er at alle OS vil være utsatt for sikkerhetshull, så det blir tullete å hovere bare fordi et blir oppdaget.

[Deezire]

La oss få dette klart; selv om nøklene var komromitterte så må de vite brukernavnet de skal koble opp til, så et automatisert angrep blir så og si umulig i et slik tilfelle, da også et lite pool av keys var kompromitterte, ikke alle nøkler som var generert.

 

Men sett at du har hatt noen uvenner på Internett som visste om infrastrukturen din så er det ikke umulig at de har vært inne og rotet på boksen din; men kun på brukeren som kunne autentisere seg med den nøkkelen.

 

Feilen var farlig, men kun i et konstruert miljø. Det er så mange faktorer som spiller inn før dette hullet skulle bli farlig for den generelle brukeren skulle kunne bli angrepet.

 

Enkle triks som minimerer angrepene:

 

1) Sett apache til production-mode, dvs. angriperen må ta fingerprint av serveren din for å finne ut hvilket OS etc. du kjører.

2) La SSH kun lytte på en IP. Har du 14 IP-er så vil du mest sannsynlig merke 14 ganger så mange angrep.

3) Installer DenyHosts, fail2ban eller lignende.

 

Eier du en større farm med debian-baserte servere så anbefaler jeg deg å ta kontakt med forfatteren av denyhosts, da du kan sette opp en egen sentrailisert server som pusher ut IPen til angripere til alle andre servere. Det gjør det ganske umulig å angripe deg.

[Prognatus]

Gode råd det der, Deezire. Et annet tips for dem som har hovedkort med to nettverksporter, og det er jo mange HK som kommer med det innebygget i dag, kan man sette opp en enkel brannvegg og Gateway mellom de to i tillegg til andre sikkerhetstiltak.

 

Se denne artikkelen på linux.com for mer info: http://www.linux.com/feature/133849

 

Der står også flere andre måter å utnytte de to portene på.

[Gjest Slettet+6132]

Gode poeng av Deezire her.

 

Problemet var nok noe mindre enn noen vil ha det til.

Fint å se at det ble tatt alvorlig og raskt rettet.