Intrusion Detection
Weten wanneer er iemand op je deur klopt.
Lance E. Spitzner
Wat is intrusion detection: Intrusion detection is het detecteren van verkeer dat bij jouw naar binnen probeert te komen. Ook kan je netwerk gescanned worden op programmeerfouten in applicaties die je hebt draaien. Dat kan EEN keer per maand gebeuren maar ook twee keer per dag dat varieert van systeem tot systeem. Er zijn mensen die je netwerk trachten binnen te komen door naar programmeerfouten in je applicaties te zoeken. Dit kan ik met zekerheid zeggen omdat ik nog nooit een netwerk dat aan internet hangt tegen gekomen ben dat niet op programmeerfouten onderzocht is. Mijn persoonlijke netwerkje bestaat uit zes systemen. Deze zitten op een vaste ISDN lijn. Dit netwerk bevat geen belangrijke data, noch is het in bezit van een organisatie/bedrijf. Toch probeert men twee tot vier keer per week om op mijn netwerk in te breken. Zodra je een systeem of netwerk aan internet hebt hangen wordt je ongetwijfeld een doel. Dit artikel zal laten zien hoe je jezelf kan verdedigen door het zien van inbreek pogingen. Hierna zal ik uitleg geven over wat je zoal kunt doen als deze pogingen gezien worden.
Het opzetten van een Intrusion Detection systeem
De methodes die ik ga uitleggen zijn simpel in het gebruik en makkelijk te installeren. Voor grotere of meer op security gerichte bedrijven is het misschien handig om een externe partij te gebruiken voor Intrusion Detection systemen, zoals Network Flight Recorder (http://www.nfr.net/nfr). Deze uitgebreidere IDS systemen onderzoeken verkeer en gebruiken geavanceerde algoritmes om te kijken of er een inbraak poging geweest is. Onze aanpak zal wat simpeler zijn.
Er zijn verschillende dingen die een hacker zal proberen uit te voeren. Het eerste ding is EEN van de meest voorkomende: portscans. Portscans zijn programma’s die gestart worden door individuelen waarbij gekeken wordt welke poorten op je systeem open staan. Deze scans kunnen plaatsvinden op een enkel systeem maar ook op een heel netwerk. Dit wordt vaak gemixed. Dit is de meest populaire methode gebruikt door hackers om te zien wat er open staat aan poorten en services.
Om deze scans te zien, bouwen we een systeem dat ons emailt wanneer iemand verbinding maakt op een vooraf bepaalde poort. Allereerst, identificeren we drie tot vijf van de meest gescande poorten. Als een potentiele indringer ons netwerk onderzoekt op fouten in applicaties, zal hij waarschijnlijk de systemen treffen die open poorten hebben. Als deze poorten gescanned worden, zal de poging gelogged worden, en wordt er een actie gestart die we van te voren bepaald hebben. Hierna kan er een email verstuurd worden naar een contactpersoon.
Het eindresultaat is dat je een email krijgt voor elke poort die gescanned is. Als je 3 systemen hebt, elk luisterend op vier poorten, dan kan je 12 emails krijgen van een enkele netwerk portscan. Echter dit normaal is dit niet het geval. Als hackers een compleet netwerk scant zoeken ze meestal op een enkele fout in de applicatie, zoals imap(port 143). In dit geval zouden we maar drie emails krijgen, EEN van elk systeem. Als een enkel systeem gescanned wordt, gebruiken ze meestal een range van poorten, zoals 1-1024. In dat geval zouden we maar vier emails krijgen, EEN voor elke poort op het systeem. Gebaseerd op de emailtjes die je ontvangt kan je snel achterhalen waar de indringer op uit is. Zie Figuur 1.
Om deze methode te implementeren moeten we eerst twee tot drie systemen aanwijzen die gaan monitoren. Meestal kies ik DNS servers omdat deze veelal het primaire doel zijn. Veel scan programma’s scannen eerst DNS servers om een database van IP adressen te maken. Selecteer hierna drie tot vijf van de meest gescande poorten. Zoek wel uit of je deze poorten niet reeds gebruikt. Elke keer als iemand verbinding maakt met de poorten zal je gealarmeerd worden. Om te weten welke poorten het meest gescanned worden kan je beginnen met zoeken bij CERT. Je kan deze alarms vinden op http://www.cert.org. De poorten die wij gaan gebruiken zijn:
imap (port 143)
SMB (port 139)
login (port 513)
http (port 80)
Ik vind deze poorten handig omdat hackers meestal naar deze poorten zoeken. Maar de meeste systemen van jouw zullen deze niet gebruiken. Zorg ervoor dat de poorten niet reeds geblokkeerd worden door een filterende router of een firewall. We zullen verschillende systemen laten luisteren op deze poorten, ons een alarm gevend wanneer er een connectie plaatsvind.
Onze implementatie gebruikt TCP Wrappers. TCP Wrappers is gebouwd door Wietse Venema. De applicatie TCP Wrappers staat ons toe om controle uit te voeren, te loggen, en de meest belangrijke, te reageren op elke gewrapte service. Als iemand verbinding maakt met de services die we hierboven gedefineerd hebben zal TCP Wrappers de connectie loggen (via syslog) en daarna ons alarm systeem activeren.
Voor diegenen die nog geen TCP Wrappers hebben geinstalleerd, zou ik dit aanbevelen te installeren. Het is extreem makkelijk om te compileren, configureren en implementeren. Je kan het vinden bij veel tool sites zoals ftp://ftp.cerias.purdeu.edu/pub/tools/unix. Voor je het compileert, zet je de language extensions aan in de Makefile (Dit geeft verbeterde configuratie mogelijkheden. We zullen deze mogelijkheid gebruiken voor Instrusion Detection doeleinden. Voor meer informatie over hoe je TCP Wrappers installeert, raad ik je aan mijn artikel “Armoring Solaris” te lezen.
Wanneer we TCP Wrappers hebben gecompileerd en geinstalleerd, willen we onze vier poorten wrappen. De poorten moeten eerst gedefineerd worden in /etc/services en daarna toegevoegd in /etc/inetd.conf.
imap stream tcp nowait root /usr/local/bin/tcpd imap.trap
Wanneer iemand een poging doet om op poort 143 verbinding te maken, accepteerd tcpd de verbinding van inetd. Daarna kijkt het in /etc/hosts.allow of de verbinding geaccepteerd is. Deze file geeft aan welke verbindingen ons alarm systeem mogen starten. Hierna zal het imap.trap starten. Je zal imap.trap moeten hernoemen voor elke aparte service, zoals http.trap voor http, smb.trap voor smb. Hieronder volgt een voorbeeld van een regel in /etc/hosts.allow, Dit is de regel die ons alarmeerd van een mogelijk onderzoek op onze applicaties.
imap.trap: ALL: spawn (/var/adm/ids.sh %d %h %H)
Dit vertelt tcpd om alle verbindingen te accepteren op poort 143 ongeacht het IP, daarna starten we ons intrusion detection script, het script dat ons alarmeert. We willen dit lokaal starten ipv met ‘twist’. Deze gebruikt de externe client voor alle standaard output en standaard error output. De drie uitbreidingen volgend op de ids.sh file (gedefineerd door TCP Wrappers) worden inline variabelen.
Het script (/var/adm/ids.sh) is waar alle actie zal plaats vinden. Deze kan je aanpassen aan je eigen persoonlijke smaak. Ik heb een voorbeeld bijgevoegd dat de data verwerkt, een safe_finger uitvoert op de client, onze contactpersoon emailt, en optioneel wordt snoop(tcpdump) gestart om verdere acties uit te voeren. zie figuur 2.
Wanneer nu iemand met onze vooraf gedefineerde poorten connectie maakt, krijgen we een vooraf gedefineerde email met alle kritische data erin. Bijvoorbeeld, een gebruiker scanned ons netwerk op poort 143 op imap zwakheden. Drie van onze systemen luisteren op die poort. De verbinding wordt gemaakt en tcpd wordt gestart. Het programma kijkt in /etc/hosts.allow, en vind een regel met imap.trap erin. Het start ons Intrusion Detection script (/var/adm/ids.sh), welke de data verwerkt, de client fingered en een alarm naar ons emailt. We hebben ook de optie om extra tools te starten, in dit voorbeeld snoop(tcpdump). Wat als laatste gebeurd is dat tcpd probeert /usr/sbin/imap.trap te starten, welke hij niet kan vinden. Tcpd stopt er dan mee een error die in syslog terug te vinden is. Om dit te voorkomen kunnen we een shell script maken /usr/sbin/imap.trap, welke niets doet maar gewoon exit.
EEN ding waar we rekening mee moeten houden is Denial of Service(DoS) attacks. Des te meer scripts je activeert, des te meer systeemresources je gebruikt. Een aanvaller kan je systeem buiten werking stellen door meerdere verbindingen te maken met de vooraf gedefineerde poorten, en daardoor meerdere processen starten van je scripts. Ik raad je aan als je een variateit aan acties defineert in je scripts dat je het aantal processen per afkomst ip limiteert. Een simpele manier om dit te doen is greppen op de afkomst in je tcpdlog. Als je de bron niet vindt is het de eerste keer dat het systeem je onderzoekt en start je het profiling script. Als hij het ip adres wel vind heeft het systeem een eerdere poging gedaan, geef dan alleen een log melding.
Als alternatief voor het gebruik van TCP Wrappers heb je router logs. Veel van ons hebben niet de luxe om drie systemen in te zetten als Intrusion Detection systemen. Echter we kunnen de hierboven geschreven methode gebruiken op bijvoorbeeld je internet router. Weer selecteren we twee / drie systemen en drie tot vijf poorten die we monitoren. Bouw een ACL (Acces Control List) op je router die de gespecificeerde poorten en systemen tegenhoudt. Laat deze ACL alle verbindingen loggen naar een syslog server. Nu kan je geweigerd verkeer monitoren en snel zien of je netwerk gescanned wordt. Ik heb hier veel success mee gehad door dit in combinatie met Swatch te doen. Swatch automatiseert het filtering en alarm systeem.
De gegeven oplossingen zijn niet honderd procent zeker. Veel portscanners vandaag de dag bouwen geen volledige TCP verbinding op . Eigenlijk gebruiken veel scanprogramma’s foutieve pakketjes zoals FIN en Xmax scans. De methode die ik heb uitgelegd zal deze type verbindingen niet zien. Voor een meer robuust Instrusion Detection systeem heb je een geavanceerdere tool nodig, zoals tcplogd. Deze kan deze scans wel zien.
Er zijn andere manieren om Intrusion Detection te implementeren op je systeem. Nogmaals, eerst moet je de intrusion methode identificeren, daarna een volg en alarm procedure implementeren. Een voorbeeld zou zijn om een login te brute forcen. Vijf consequent mislukte pogingen om in te loggen worden gelogged in de file /var/adm/loginlog. Dit gebeurt als een cracker het systeem aan het onderzoeken is op zwakke login/password combinaties. Al mijn systemen draaien een dagelijkse cronjob die eventueel de inhoud van die file naar mij toemailt. Als die er zijn, heeft of: iemand zijn password vergeten en geprobeerd die te gokken het is een potentiele cracker die geprobeerd heeft brute forced in te loggen. De cronjob mailt mij de inhoud van de file, maakt een kopie en leegt vervolgens de logfile. Een ander voorbeeld is de standaard /cgi-bin/test-cgi aanval op webservers. In plaats van het uitzetten van dit cgi script, veranderd ik het zo dat het gelogt en naar mij gemailt wordt wanneer iemand dit uitprobeerd. Dit houdt meestal niets meer in dan het script aan te passen (wees er zeker van dat je dit test voor je het implementeert op je systeem!).
Zoals we behandeld hebben zijn er meerdere simpele manieren om simpele Intrusion Detection systemen te implementeren. Echter deze zijn niet voor de volle 100% veilig. De aangeleverde methodes helpen je om potentiele scans te identificeren en om je netwerk te verdedigen. Wel nu, wat doen we als we Intrusion Detection systemen geimplementeerd zijn en je erachter komt dat men je systemen onderzoekt?
Reageren op een mogelijke inbraak.
De eerste stap is bevestigen of je systeem echt onderzocht wordt. Ook al ontvang je een enkele email van je TCP Wrapper setup wil dat niet zeggen dat je gescanned wordt. Een verwarde gebruiker kan per ongeluk verbinding maken het met verkeerde systeem, of iemand heeft per ongeluk een typfoutje gemaakt. Niets is beschamender dan iemand beschuldigen terwijl die persoon het niet gedaan heeft. Echter als drie systemen consequent worden gescanned op dezelfde poort op dezelfde tijd zou dat kunnen aangeven dat je onderzocht bent. En nu?
Het laatste wat je wilt doen is een tegenaanval uitvoeren op het systeem om het uit de lucht te halen. Wanneer je netwerk gescanned wordt voel je je misschien gefrustreerd en wil je je frustratie uiten op het systeem dat je gescanned heeft. Omdat iemand aan het voorbereiden is om je te cracken zou je dan niet reageren? Echter wees voorzichtig met de manier waarop je reageert
- Je systemen kunnen inderdaad gescanned zijn maar het kan per ongeluk zijn. Vaak scannen grote organisaties hun interne netwerken en kantoren. Misschien heeft iemand het verkeerde netwerk gescanned (Persoonlijk weet ik dat dit gebeurd is bij een organisatie).
- Vaak hebben de verantwoordelijken voor het systeem geen idee wat er gebeurd is. Grote systemen met honderden gebruikers kan een gebruiker hebben die illegaal zijn of haar account gebruikt om andere netwerken te scannen. Of het systeem is gecracked en wordt gebruikt als scanhost. Wat het ook is, de admin van het systeem wilt graag weten wat er aan de hand is zodat het probleem opgelost kan worden.
- Het afkomst IP adres dat verschijnt in je logging kan een niet echt systeem zijn, misschien is het een “afleid” afkomst adres. Veel scantools staan de gebruiker toe om het afkomst IP adres te veranderen naar wat de gebruiker wilt. Je logging zegt misshien dat de scan van vijf verschillende systemen komt, terwijl het allemaal misschien wel van dezelfde machine komt. De gebruiker probeert zijn ware afkomst te verbergen door valse IP adressen te gebruiken. Het is daardoor extreem moeilijk om te achterhalen of de scans het doel hadden om zwakke services te vinden of niet. Ook kan de gebruiker zijn afkomst IP adres veranderd hebben om iemand anders de schuld in de schoenen te schuiven.
Zelfs met de beste bedoelingen kan je meer schade aanrichten dan goed is. Bijvoorbeeld, laten we zeggen dat je netwerk gescanned wordt en je komt erachter welke machine het is. Dat deze machine gecracked is gebruikt wordt als scanhost. Je identificeert welke backdoor de cracker heeft gebruikt om toegang te krijgen en gebruikt deze om toegang te verkrijgen. Je haalt alle tools en logging op van de persoon en gebruikt deze om de eigenaar te informeren en andere organisaties (CERT). Ook al denk je nu dat je goed gedaan hebt, heb je meer schade aangericht dan goed was.
- Heel waarschijnlijk heeft de hacker verschillende monitoring tools en logs vervangen. Hij kan ontdekken dat jij er was en maakt daarna het systeem schoon om zichzelf veilig te stellen (daardoor vernietigd hij het systeem en eventueel resterend bewijsmateriaal).
- Misschien wist de systeembeheerder er vanaf en was hij bezig met de autoriteiten. Je hebt nu net het onderzoek verstoord.
- Men kan je verantwoordelijk houden voor het crack incident. De systeem eigenaren kennen je niet en kunnen je beschuldigen van het inbreken in het systeem, en om jezelf te beschermen geef je de schuld aan iemand anders.
Feitelijk is er een hoop dat je mis kan doen, en er is weinig dat je goed kan doen als je op eigen houtje handeld. Het beste wat je kan doen is eerst zoveel mogelijk informatie verzamelen als mogelijk is. Bestudeer elke log die laat zien dat er scans waren van het afkomst IP adres. Probeer daarna de personen en/of organisatie te identificeren die verantwoordelijk zijn voor het incident. De whois database, dig, nslookup zijn perfecte methode’s om erachter te komen wie er verantwoordelijk is voor het systeem. Email de personen met details van wat er is gebeurd inclusief logging ter verificatie. Misschien wil je ook wel een cc sturen naar de provider van de organisatie om hen te informeren. Als de inbraken erg genoeg zijn, neem dan contact op met een professionele organizatie zoals CERT http:/www.cert.org of CIAC op http://www.ciac.org. Als de inbraak pogingen doorgaan zonder antwoord van de systeem eigenaren bel dan het bedrijf zelf. De telefoon kan een sterk middel zijn.
Conclusie
Vroeg of laat zullen jouw systemen en netwerken gescanned worden op zwakheden. Door wat voorzorgsmaatregelen te nemen kun je de acties loggen en identificeren. Wanneer ze geidentificeerd zijn, kan je de scans in de gaten houden en beter begrijpen wat voor risico’s je systemen en netwerken lopen. Hierdoor kan je ook beter reageren op de risico’s en bijvoorbeeld vroegtijdig patchen. Wanneer je iets identificeert, is het het beste om zoveel mogelijk informatie te krijgen, neem daarna contact op met de personen en het bedrijf dat verantwoordelijk is voor het systeem. Op eigen houtje reageren maakt het vaak erger en daardoor richt je meer schade aan dan goed is. Door samen te werken met anderen kom je tot een betere oplossing.
Figuur 1
Subject: ### Intrusion Detection Alarm ###
Je hebt dit alarm gehad omdat het netwerk
mogelijk gescanned wordt. Onderstaande informatie
is het pakket dat werd gelogt en gedropt.
Date: Sat Jan 24
Time: 18:47:46
Source: ICARUS.CC.UIC.EDU
Destination: lisa
Service: imap
— Finger Results —
[ICARUS.CC.UIC.EDU]
Login Name TTY Idle When Where
Spitzner Lance Everett Spitzn pts/72 Sun 18:42 lspitz-4.soho.entera
Figuur 2
#!/bin/ksh
#
# Script gestart door tcpd voor Intrusion Detection doeleinden
#
USER=lance@honeynet.org
SRV=`echo $1 | cut -f1 -d.`
DATE=`date “+%a %b %e”`
TIME=`date “+%T”`
FINGER=`/usr/local/bin/safe_finger @$2`
MAIL=/usr/bin/mail
$MAIL $USER <<EOF
Subject: ### Intrusion Detection Alarm ###
Je hebt dit alarm gehad omdat het netwerk
mogelijk gescanned wordt. Onderstaande informatie
is het pakket dat werd gelogged en gedropt.
Date: $DATE
Time: $TIME
Source: $2
Destination: $3
Service: $SRV
— Finger Results —
$FINGER
EOF
##### Als de service Imap is, laten we dan doorgaan en de sessie snoopen
if [ $SRV=imap ]; then
snoop -v -c 5000 -o /var/adm/$2_snoop.$$ $2 &
fi
Origineel document: Lance Spitzner
Vertaald document: Remko Lodder (Juni 2003)
Author’s bio
Lance Spitzner enjoys learning by blowing up his Unix systems at home. Before this, he was an Officer in the Rapid Deployment Force, where he blew up things of a different nature. You can reach him at lance@honeynet.org .
Continue reading »
written by Remko
#####################################################################case "$1" in start) case "$2" in rules) firewall_start_rules echo "Starting firewall script rules" logger "Loaded firewall rules" ;; nat) firewall_start_nat echo "Starting firewall script nat rules" logger "Loaded firewall nat rules" ;; *) firewall_start_complete echo "Starting firewall script" logger "Starting firewall/nat script" ;; esac ;; stop) case "$2" in firewall) firewall_stop_complete echo "The firewall stopped completely" logger "Stopped the firewall/nat script totally" ;; nat) firewall_stop_nat echo "Flushed the nat rules" logger "The firewall nat rules were flushed!" ;; rules) firewall_stop_rules echo "Flushed the rules" logger "Firewall rules are flushed!"
;; help) echo "The following options can be given during startup" echo "rules -> stops the rule firewall" echo "nat -> stops the nat firewall" echo "nothing -> stops the entire firewall" echo "firewall -> stops the entire firewall" ;; *) firewall_stop_complete echo "The firewall stopped completely" logger "Stopped the firewall/nat script totally" ;; esac ;; list) case "$2" in nat) echo "Listing nat" firewall_list_nat ;; rules) echo "Listing rules" firewall_list_rules ;; *) firewall_list_complete ;; ;; *) echo "Usage (start|stop|list)" exit 1; ;;esacexit 0###################################################################### End of script#####################################################################