Hvem hacker min maskine?

Jeg foretrækker port knocking frem for security by obscurity - hvis nogen egentlig er interesseret i din box, så nmap'er de den nok også og skal nok finde din SSH port. Har du i stedet set et par regler op til port knocking kan du lade SSH blive på 22 uden at bekymre dig videre om requests til den port.

Mht check af webservere har jeg faktisk ikke fået sat det store op endnu men vil klart kigge på logwatch, det lyder meget interessant.

At verden er fuld af onde mennesker og virusinficerede maskiner, er ingen nyhed. At nogen forsøger sig med indbrud, finder jeg ikke så interessant, så længe forsøgene ender med en 404-fejl (som i dit eksempel). I givet fald var der jo netop ingen grund til alarm. Selvfølgelig kan det fungere som en reminder om, at man skal huske at holde sin phpMyAdmin-installation opdateret eller gemt godt væk, men det skal man jo under alle omstændigheder.

Hvis der er nogen særligt ihærdige gengangere, kan man selvfølgelig prøve at blokere dem, men generelt er manuel firewalling et sysifosarbejde, og man får næppe nogensinde blokeret nogen nævneværdig procentdel af alle potentielle indbrudstyve (især ikke hvis man indberegner inficerede maskiner, der indgår i et botnet). Jeg har tidligere forsøgt mig, hvor jeg så spærrede for et helt C-net ad gangen, men i løbet af ingen tid havde jeg jo nærmest spærret for det halve internet.

Jeg holdt op med at bruge LogWatch, fordi der var for meget støj i rapporterne. For at overvågningssystemer skal være rigtig nyttige, skal de hverken larme for meget eller for lidt. Larmer de for meget, overser man let det vigtige.

I tillæg til automatiseret logovervågning finder jeg det meget givtigt indimellem bare at bladre i diverse logfiler eller helt manuelt eller studere grafer baseret på logfilerne. For en travl server falder jeg hyppigt over “spøjse” ting og sager, der kræver en nærmere efterforskning – ikke kun indbrudsforsøg men også fejl/uhensigsmæssigheder i min egen applikation/konfiguration og hos eventuelle samarbejdspartnere. Faktisk sker det tit, at jeg er i logfilerne for at lede efter én ting og så falder over noget andet.

På trods af al den tid du har spildt på de logs har vi sådan set ikke fået noget ordentligt svar på spørgsmålet i overskriften. Det kan selvfølgelig på et eller andet plan være interessant at se hvad der egentlig foregår, men rent sikkerhedsmæssigt forekommer det mig at være spild af tid.

Udover ovenstående. kører vi bl.a. denyhostst, rkhunter og integrit.

denyhosts sørger for at finde gentagne SSH-Login forsøg, og blokerer derefter hosten helt fra maskinen, det virker ret godt og fjerner meget af støj trafikken :)

Integrit, kigger vigtige filer igennem, efter din specifikation, og giver en melding hvis der bliver oprettet nye filer, eller der sker ændringer med de eksisterende.

RKHunter, checker efter rootkits, kontrollerer at du ikke har "dårlige" version af forskellige programmer, f.eks. ssh :)

Alt i alt fungerer det ret godt, jeg har tidligere brugt logwatch, men som andre nævner kom der meget unødigt, jeg føler at vi med ovenstående er på et tåleligt niveau, hvor man ikke bare ignorerer tingene.

Har selv brugt Fail2ban [1][2], som scanner log filer og opsætter firewall regler for at banne IP adresser som gentagne gange har forsøgt at logge/trænge ind. Det kan bl.a. checke web, ftp, ssh, mail m.v.

[1] http://www.fail2ban.org/ [2] http://en.wikipedia.org/wiki/Fail2ban

Jeg mener det er ørkenvandring at finde ud af, hvem der [b]prøver[/b] at hacke min maskine. Svaret er, at det gør en stor procentdel af verdens maskinpark. Som nævnt før kan man klage over portscans, brute-force angreb eller spam til afsenderens ISP, men har nogen her overhovedet erfaring med, at det hjælper? Jeg har i hvert fald ikke tid til at melde de ca 500 IP-numre, der dagligt er forbi min port 22.

Jeg synes det er mere interessant at finde ud af, hvem der [b]har[/b] hacket min maskine. Rootkit scannere, tripwire, gennemgang af logs for lokale brugere osv. kan hjælpe, ud over naturligvis at begrænse, hvad lokale brugere har adgang til at gøre, når de først er inde (via chroot, jails, ACL osv.). På FreeBSD bruger jeg desuden portaudit til at fortælle mig, om jeg har programversioner med kendte sårbarheder installeret.

Det kan bare være besværligt, hvis dem som bryder ind rydder op efter sig selv.

Har selv siddet med en Debian maskine nogen havde brudt ind i. Der var smidt et par rootkits ind, flere eksekverbare filer var ændret til højest sandsynligt at udføre alternative kommandoer, og alle log filer m.v. var slettet godt og grundigt. Jeg fandt aldrig indgangsvinklen til angrebet, men serveren kørte kun http, ftps og ssh, så vidt jeg husker. Godt det bare var en lege maskine, uden noget vigtigt på.

Er der nogen der har overvejet at bruge Snort som IPS eller IDS i det her tilfælde?

Personligt "grep'er" (grep "UNION" access.log, osv.) jeg access.logs'ne igennem fra tid til anden, men hvis en hacker har haft "root" adgang på din server, så har han eller hun nok slettet logs'ne hvis denne person bare ved en smule om ondsindet brug af hacking hvilket jeg selvfølgelig er stærkt imod.

Den bruger jeg også, før fik jeg faktisk så mange requests på min mailserver at load steg på grund af det. Nu er det på et minimumsniveau...er super glad for fail2ban og den kommer til at følge mig fast fremover :)

/Anders

Der er forskel på om dr. Evil kigger på langs eller på tværs :) Søger han en maskine med en defekt ssh server. Eller forsøger han at ramme netop en maskine.

Men du skal have rigtig god tid...

Vi ser bort fra SSH attacks, som jo også har eksisteret i mange mange år, og kigger på HTTP 'attacks'.

Her vil du observere at der overordnet findes 3 typer af 'udbredelse'.

1) Referrer. Her angiver man en 'interessant' URL som referrer, hvor man ved klik bliver om/redirigeret til 'malware'.

2) Blog/Comment spam. Det handler om at få placeret nogle 'interessante' URL'er, som også leder til 'malware' (incl 'viagra').

3) Remote execution af PHP kode. Der snakker vi om opdatering/placering af decideret skadelig kode, som igen leder til 'malware'.

Ja ja - så er der 4) SQL injection, men der er mest udbredt på 'capable' databaser.

Men som du selv er inde på, så: Ad SSH: Brug key-auth only, og flyt til en anden port. (ikke security by obscurity, men for at undgå disse 'trælse logfiler').

Ad 1): Lad være med at klikke på 'interessante besøgende'.

Ad 2): Sørg for at bot'er ikke autoposter skramlet.

Ad 3): Lad være med at eksponere 'usikker kode'.

Ad 4): Brug altid parameterized queries/prepared statements.

• så kan du sove trygt og roligt 'happily ever after'.

NB: XSS er ikke nævnt, men der skal man blot sørge for alt er 'XML'-encoded.

Det kan bare være besværligt, hvis dem som bryder ind rydder op efter sig selv.

Det jer mener er, at så længe man har opdateret sit OS og de services man kører, og konfigureret dem korrekt, så giver det ikke så meget mening at læse logs over dem, som ikke har held med at bryde ind. Med mindre man vil melde dem, altså. Eller lære noget om, hvilke angreb, der er populære i denne uge.

Det giver mere mening at få en advarsel, hvis nogen rent faktisk kommer ind.

Så derfor har jeg sat swatch (special udgave der gemmer sin sidste position) op - den har et dejligt config sprog og så har jeg en simpel wrapper der kigger i en config folder - og for hver fil - kigger i logs for alle hosts for den facility.

Det kører hvert 5. minut og sender en samlet mail med uventede beskeder (dem der ikke er blevet ignoreret af min swatch config) - se detaljerne her: http://blog.klavsen.info/content/1-way-do-proper-log-monitoring

Det sikrer ihvertfald at man får af vide når der kommer en besked man ikke havde forventet - og det er egentlig det jeg vil vide.

Man er aldrig sikker. Pointen er vel at gøre det så besværligt at få fat i det man har at det ikke er umagen værd. Hvis du hoster CPR-registeret eller NemID nøgler er dem der vil ind rimeligt motiverede. Ikke helt så meget hvis du har mail, mormors kageopskrifter og et gentoo mirror fra '98.

Det gør jeg - på forhånd undskyld.

Med en fredags nyhed:

I dag har Ubuntu frigivet beta versionen af 10.10. Det var ellers planen at alpha 4 skulle komme.

http://www.phoronix.com/scan.php?page=news_item&px=ODU2NA

Har iøvrigt med interesse fulgt tråden.

Tak for logwatch og denyhost informationen, som jeg straks installerede. Rkhunter kendte jeg, men kørte den straks og fandt at min ssh havde åben for login som root! Pinligt ( men det er Ubuntu standard :-( ).

Der er flere der spørger om det hjælper at anmelde til abuse@ postkasserne, og det kan jeg sige det gør.

Ihvertfald "lokalt" så jeg anmelder gerne hvis det er i eksempelvis Tyskland eller andre lande i EU, men sjældnere til USA og Asien.

Jeg vil ligesom andre anbefale at PHPMyAdmin, hvis den overhovedet bruges lukkes med et password i Apache - som minimum.

Jeg er lidt old-skool og bruger derfor også Swatch og centraliseret log er noget jeg bruger, så er det nemmere at søge og finde :-)

Når du aligevel skal ændre din SSH config, så vil jeg straks anbefale min egen template: http://www.kramse.dk/projects/unix/opensshtemplate_en.html

Der er flere ting som UseDNS og husk også at hvis man skal slå password fra, og kun bruge nøgler - så skal BÅDE PasswordAuthentication og ChallengeResponseAuthentication sættes til no!

Jeg anbefaler også at man ændrer SSH porten, medmindre man har rigtig mange brugere - det er security by obscurity, og det er fint SAMMEN MED rigtig sikkerhed (brug af template ovenfor).

Rkhunter kendte jeg, men kørte den straks og fandt at min ssh havde åben for login som root! Pinligt ( men det er Ubuntu standard :-( ).

Ubuntu standard er at root slet ikke kan logge ind [1], medmindre du sætter et password. Men det skader naturligvis ikke at ændret i sshd_config.

[1] Dvs man skal køre "sudo su -" fra en sudoer for at blive root, medmindre der sættes et password for root.

Kære Internet.

Hvis ovenstående indlæg og tilhørende kommentarer har forvirret dig, kan du nøjes med at læse inputtet fra Erik Cederstrand og se bort fra resten.

Det der med sikkerhed er tydeligvis svært.

Alex Holst

Spøjst - det var slet ikke faldet mig ind lige at inspicere serverens log på lige fod med routerens.

Men nu har jeg da fået et par henvisninger til lidt værktøj - det skal nok blive interessant.