Hvem hacker min maskine?

En af de ting, jeg rigtig gerne vil høre kommentarer på er hvordan I håndterer logfiler på jeres Internet-servere. Jeg har en Fit-PC2 Linux-box stående på internettet som server.
Den er firewallet, så der er mail (port 25), imaps-server, web-server og ssh. Ikke mere. SSH er flyttet væk fra port 22 da den ellers får unødigt mange "tilbud" udefra.
Jeg mener ikke, man skal have en maskine direkte på internettet uden at man læser logfiler på en eller anden måde. Jeg bliver fra tid til anden ringet op af folk der har et aktivt indbrud i gang. Altid "underholdende" - især stemmelejet på de personer, der ringer til mig.
Jeg må indrømme at jeg ikke får læst logfiler direkte, men er blevet glad for LogWatch, som er script-løsning der parser logfiler og præsenterer, hvad der er sket det sidste døgn. Dette får jeg på email hver morgen.

En meget enkel beskrivelse af opsætning af Logwatch kan findes på denne URL.
Jeg har ladet Logwatch vise mig de websider, der ikke kunne serviceres af min Apache, men ikke alle de sider, der gik godt. Det har den ulempe, at man ikke finder indbrud via websider, der kan udnyttes - men alene ser jeg på de forsøg som oftest anvendes mod web-servere generelt. Det er ofte "sjov" læsning. Her er et eksempel fra LogWatch mailen i morges:


––––––––––- httpd Begin ––––––––––––

A total of 6 sites probed the server
209.188.89.23
64.165.76.9
69.162.116.93
93-116-162-69.static.reverse.nodesdirect.net
acs-lx2.acs-digital.com
host2.fiestyfinder.com

A total of 2 possible successful probes were detected (the following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit):

//index2.php?option=com_myblog&Itemid=12&task=../../../../
../../../../../../../../../../../proc/self/environ%00 HTTP Response 302
/index2.php?option=com_myblog&Itemid=12&task=../../../../../../../../../../
../../../../../proc/self/environ%00 HTTP Response 200

Det er ikke et uheld - klart indbrudsforsøg.

En af de skud jeg oftest ser er forsøg på at ramme en phpMyAdmin opsætning som har haft en del "lækager" (for mange til min smag).
Jeg skal ikke køre phpMyAdmin.

404 Not Found //mysql//scripts/setup.php: 1 Time(s)
//phpAdmin//scripts/setup.php: 1 Time(s) //phpMyAdmin//scripts/setup.php:
1 Time(s) //phpadmin//scripts/setup.php: 1 Time(s)
//phpmyadmin//scripts/setup.php: 1 Time(s)

En morgen var det gået helt amok, som det kan ses her.... SUK Internettet er ondt :-(

Hvis jeg gentagne "underlige" forsøg, så kigger jeg direkte i /var/log/apache2/error filerne

F.eks. ser jeg jævnligt PHP forespørgsler ala

[Thu Sep 02 06:13:59 2010] [error] [client 85.236.50.166] script
'/home/pto/www/contact.php' not found or unable to stat

Herefter kan jeg finde på at se hvor de kommer fra - i dette tilfælde er IP-adresse 85.236.50.166, som jeg f.eks. kan mappe tilbage på http://en.utrace.de/'query=85.236.50.166. Ved gentagelser så bliver de IP-adresser firewallet. Jeg ved godt det er meget svært at lave reel opdæmning mod dette.

Ud over at LogWatch giver en ret kort sammenfatning af HTTPD (webserver-fejl), så får man en lille blok tekst med status for mailserver og SSHD. Den øjer jeg også igennem for at se om der er noget "underligt".

I øvrigt er min server sat op til ofte at checke for sikkerhedsopdateringer, nye uventede port-services og jeg bliver mailet konstant hvis jeg ikke reagerer på dem.

Jeg sover stadig godt om natten, men der er hele tiden nogen der udfordrer min maskine.

Jeg vil gerne høre om hvad I andre sysadminer gør for at checke hvad der sker på jeres maskiner. Del løs...

/pto

Kommentarer (22)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Peter Lind

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.

  • 0
  • 0
#2 Christian Schmidt Blogger

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.

  • 0
  • 0
#5 Deleted User

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.

  • 0
  • 0
#7 Mads N. Vestergaard

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.

  • 0
  • 0
#9 Erik Cederstrand

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.

  • 0
  • 0
#10 Ove Andersen

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å.

  • 0
  • 0
#11 Hans-Michael Varbæk

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.

  • 0
  • 0
#12 Anders Kvist

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

  • 0
  • 0
#14 Anonym

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.

  • 0
  • 0
#15 Erik Cederstrand

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.

  • 0
  • 0
#16 Klavs Klavsen

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.

  • 0
  • 0
#18 Bo Normann Jensen

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 :-( ).

  • 0
  • 0
#19 Henrik Kramselund Jereminsen Blogger

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 :-)

  • 0
  • 0
#20 Henrik Kramselund Jereminsen Blogger

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).

  • 0
  • 0
#21 Jesper Lund

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.

  • 0
  • 0
#22 Alex Holst

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

  • 0
  • 0
#23 Peter Jespersen

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.

  • 0
  • 0
Log ind eller Opret konto for at kommentere