Linux-rootkit udnytter stjålne SSH-nøgler

US-CERT angiver ligeledes, hvordan man kan opdage rootkittet ved at biblioteket /etc/khubd.p2 ikke bliver vist med kommandoen ls, men kan tilgås med cd-kommandoen.

Der er vel tale om et skjult bibliotek, så det er da ikke nødvendigt at lave cd, men bare benytte ls -a.

/Christian

Nej, der er tale om en version af ls der er patchet til ikke at vise kataloger der hedder khubd.p2.

Rootkittet skal vel installeres som root - altså en almindelig bruger kan da ikke installere et rootkit, med mindre der er noget helt galt?

Og en linux administrator med lidt sikkerhed i mente ved jo, at man ikke tillader root adgang via SSH.

Så for at installere rootkittet skal der logges ind via SSH og derefter opnås root adgang?

For at teste mod rootkit bruger jeg selv chkrootkit og rkhunter på min Debian server og laptop..

Har man først adgang som en alm. bruger er det jo nok nemmere at finde et local exploit som maskinen er sårbar overfor. - og så er du root.

Helt korrekt, men det er da temmeligt besværligt først at skal knække en usikker SSH nøgle for derefter at skal til at rode et system igennem efter en root sårbarhed.

SSH breaket er temmeligt sikkert nemt at automatisere, mens det andet er mere besværligt..

Nej, der er tale om en version af ls der er patchet til ikke at vise kataloger der hedder khubd.p2.

Hvordan fremkommer at ls er patchet, er det rootkittet der har sørget for det?

Og så en anden lille generel sikkerhedsbetragtning, undlad selvfølgelig at benytte port 22 til ssh adgang udefra.

/Christian

Hvordan fremkommer at ls er patchet, er det rootkittet der har sørget for det?

Ja, at installere sin egen version af ls er en ret primitiv, men normal, måde at rootkits holder sig skjulte.

Det er et gammelt flamewar-emne, og det er fordi, der er ulemper ved begge dele.

I en supersikker server, der er det slet ikke muligt at logge ind som root ved andet end konsollen. Man ikke lave su, sudo el.lign. Der er ingen kommandoer, der kører suid, og enhver forbindelse fra uprivilegerede brugere til root.

Men sådan er virkeligheden bare ikke. Enhver systemadministrator nægter at sidde i et serverrum mere end en halv time af gangen. Så kravet er der jo om, at man skal kunne komme fra en uprivilegerede konto til root.

Argumentet for, at man ikke må kunne logge ind gennem SSH direkte som root, er følgende: Alle ved, at root login hedder "root", så det har vi. Nu skal vi bare gætte password. Hvis man først skal logge ind som "ole" med Oles password, og man derefter kan bruge su til at blive root, så er der tre ting man skal vide: Oles loginnavn, Oles password og roots password.

Fint nok, men er det mere sikkert? Lidt... loginnavn og password er multiplikativt forbundne, sådan at man ikke kan vide, om man har valgt et eksistende loginnavn, hvis man ikke også har det rigtige password. Har man det, skal man additivt gætte root-password for at få root-adgang. Men i det regnestykke skal man huske, at der er flere uprivilegerede konti, som summerer reciprokt. Det forbedrer altså kvaliteten af sikkerheden, men kun additivt. (Sagt på en anden måde: Det svarer til at øge sikkerheden til en garage ved at sætte to hængelåse på porten i stedet for en.)

Desværre bliver sikkerhed lavere, hvis man bruger sudo. Hvis man skal logge ind som "ole" og Oles password er ringere end root-password, og blot derefter kan få root-adgang med sudo, så er sikkerheden blevet dårligere end hvis der kun var adgang til root-kontoen fra SSH med root-password.

Nu er der jo i SSH facilitet til, at man ikke skal bruge passwords men kan anvende kryptografiske nøgler. Artiklen handler om stjålne nøgler, men den er ikke så klar på, hvor de stjålne nøgler er taget fra. Hvis der er tale om brudte nøgler på grund af fejlen i Debian, så er løsningen jo først og fremmest at få genererede nogle nye nøgler i en fart.

Fordelen ved nøglerne er, at man kan give andre folk root-adgang (konsulenter etc.) uden at de skal kende root-password. Hvis en ekstern person genererer en nøgle og denne nøgle tilføjes roots authorized_keys af en systemadministrator, så har man ikke root-passwords ud i det fri.

Hvis man har mange servere, og der laves automatisering af opgaver, der indvolverer flere maskiner, så er man nødt til at have root-adgang, der ikke baserer sig på passwords. Alternativet er, at en administrator logger ind på hver maskine, bliver root og derefter starter rutinen op.

I praksis ser jeg også en række andre ting i det virkelige liv: Jo flere krumspring man skal i gennem for at få en root-shell, desto mere tilbøjelige er folk til at gå fra en desktop med et gabende shell-vindue.

Det bedste, man kan gøre, er at forhindre SSH-adgang fra andre IP-adresser end dem, der eksplicit skal have adgang. Det er bare et par linier i et iptables-script

Thomas

Ja, at installere sin egen version af ls er en ret primitiv, men normal, måde at rootkits holder sig skjulte

Tak, så giver det mere mening, og længe leve forummet for at bidrage med den forståelse man ikke får fra artiklerne.

/Christian

Når man er i gang med iptables så kan man tilføje følgende:
iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set

iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 -j DROP

Det vil maksimalt tillade tre nye forbindelser fra en bruger hvert minut. På den måde bliver det svært at teste store mængder passwords, men normale brugere kan logge på normalt uden diverese krumspring.

Det vil maksimalt tillade tre nye forbindelser fra en bruger hvert minut. På den måde bliver det svært at teste store mængder passwords, men normale brugere kan logge på normalt uden diverese krumspring.

Det gør dig naturligvis sårbar for DoS angreb. Du skal kunne acceptere at blive lukket ude af din server, hvis en hacker havde besluttet sig for at bryde koden. Jeg tror ikke det ville være et problem for de fleste, og det vil nok ske meget sjældent, men man skal nok lige overveje det, hvis det er meget kritisk at man altid har adgang til maskinen. En simpel løsning kunne være, kun at tillade 3 forsøg fra den samme ip adresse. Desværre vil det nok betyde, at man er sårbar for et distribueret angreb fra fx et botnet. Jeg er sikker på at der findes masser af bedre løsninger, hvis man tænker lidt over det.

Jeg bruger programmet denyhosts til automatisk at udelukke gentagne forsøg på at få adgang: http://denyhosts.sourceforge.net

Det nytter selvfølgelig ikke noget hvis indtrængeren har en stjålen nøgle, men det er så ikke nødvendigvis en usikkerhed ved systemet selv. Lidt ligesom at bilens startspærrer ikke hjælper et hak hvis tyven har din nøgle.

Efter at jeg skiftede min SSH server væk fra port 22 til et meget højt port-nummer er mængden af forsøg røget helt i bund.

Den primære fordel ved at skifte port er nok at det er nemmere at ikke at skulle se efter mistænkelige ting i loggen, hvis den ikke er fyldt med robotter, der forsøger at logge ind som "mysql" og lign. via SSH.

Selve sikkerheden er vist begrænset. Hvis man endelig vil skjule sin SSH-port, så skal man nok kigge på fwknop og single-packet-authorization.

kunne være mulighed man også kan bruge automatiseret

http://www.portknocking.org/

http://en.wikipedia.org/wiki/Port_knocking

Jeg har også flyttet mine ssh porte og det er ren dovenskab (gider ikke lave et firewallscript der udelukker bestemte ipnumre), før var der altid en eller anden knold der brugte min båndbrede på at bryde ind, og da jeg kun bruger nøglefiler og de vist endnu ikke er hugget fra mig, spildte de deres tid, så for nu ikke at spilde andres tid, flyttede jeg porte og vupti siden har jeg ikke set en eneste der brugte deres oppetid på at forsøge at besøge mig, men ja det er rigtigt der er ingen sikkerhedsforbedringer i portskift, blot viser praktisk erfaring at man slipper for forsøg på besøg.