Inlägg taggade "säkerhetsnätet"

Tshark Challenge - Uber-nörd Svar

Oktober 13, 2009

I mitt förra inlägg lämnade jag dig med en fråga: Med tanke på vad vi har sett i avkoda filen med tshark, vilken inverkan (om någon) skulle det vara om vi placerar en Stateful Inspection brandvägg mellan angriparen och webbservern? Med andra ord, om angriparen är igång ett paket sniffer, skulle de fortfarande se webbservern läcker ut 404 fel?

Och svaret är ...

Kanske. :)

Inte alla stateful inspection brandväggar är lika. Vissa handtag paket lite annorlunda än andra. Till exempel en del (som Checkpoint, Netscreen m.fl.) lät icke-SYN paket att tillåta regler generera nya tabellposter statliga. Några (Cisco, Netfilter och andra) kommer bara generera en tillståndstabell med ordentlig session etablering (måste se TCP tre paket handskakning).

Den NIPS skickade en giltig återställningspaket till angriparen på Internet. Var och en av de ovanstående brandväggar skulle se återställningspaketet och ta bort det är posten från staten bordet. När den webbservern fortsatte att kommunicera skulle dock endast den första uppsättningen av brandväggar låt paketen läcka ut till angriparen. Den andra uppsättningen av brandväggar skulle helt enkelt släppa trafiken. Faktum är att om vi sätter upp dem med en förnekar regel istället för en droppe regel, skulle de döda sessionen på webbservern vilket åtgärdar problemet skapas av NIPS.

Varför har vissa leverantörer låter bekräftelsepaket generera nya tabellposter statliga? Detta verkar lite bakvända som en legitim session kommer alltid att börja med ett SYN paket. Det finns två skäl till detta gör bra funktionell mening:

  • Uppdatering av brandväggsregler dödar inte aktiva sessioner
  • Aktiv-aktiv inställning passerar trafiken före tillståndstabell sync

Naturligtvis har vi utökad funktionalitet på bekostnad av säkerheten. Tyvärr det är den typiska avvägning.

Hoppas ni hade kul med denna utmaning. Om det finns intresse kommer jag att lägga upp mer i framtiden.

Hur att granska en brandvägg Logga in 15 min eller mindre - Del 2

29 sep 2009

I mitt förra inlägg presenterade jag idén om att använda vit notering i syfte att se över brandväggsloggar. Jag diskuterade hur denna process både kan förenkla och påskynda log granskningsprocessen, genom att automatisera mycket av det up front arbete. I detta inlägg kommer vi att titta på några konkreta exempel, och börja skapa en brandväggslogg pars manus.

Grunderna i grep

För att visa processen för vita lista dina brandväggsloggar, kommer jag att använda grep. Grep är en standard Linux / UNIX-verktyg, med fria versioner tillgängliga för Windows (greppa både Binaries samt beroenden). Grep är verkligen inte det mest effektiva verktyget för jobbet, men det är den absolut enklaste att lära sig. Om du är en Perl, PHP, AWK & SED, SQL, etc. guru, med alla medel hålla fast vid din bästa sättet. Helt enkelt efterlikna den process som jag har definierat här med Ditt lämplig kommandouppsättning.

Grep är ett mönstermatchningsverktyg. Det gör att du kan söka en eller flera filer som letar efter ett visst mönster. När mönstret hittas, tas hela raden skrivs ut. Så till exempel kommandot:

grep 192.168.1.10 firewall.log

skulle producera alla rader i filen "firewall.log" som innehåller IP-adress "192.168.1.10". Grep har ett antal växlar som stöds, men det enda vi behöver för brandväggslogg är ett "-v" omkopplare. Denna knapp talar grep matcha alla rader som inte innehåller det angivna mönstret. Så till exempel:

grep-v 192.168.1.10 firewall.log

skulle endast skriva ut linjer som inte innehåller den specificerade IP-adressen.

Med grep, är en period faktiskt ett jokertecken. Så när jag sa det första grep kommandot skulle matcha på IP-adressen 192.168.1.10, kan det faktiskt stämmer på mer än så. Grep tolkar strängen för att läsa:

Matchen på: 192 <Ej enda character> 168 <Ej enda character> 1 <Ej singel character> 10

Om vi ​​vill grep matcha perioder som den tid, vi måste föregå dem med ett omvänt snedstreck. Så rätt syntax skulle faktiskt vara:

grep 192 \ 0,168 \ 0,1 \ 0,10 firewall.log

Slutligen, ibland vi vill matcha på flera mönster som är uppträdda tillsammans. Till exempel vad händer om vi är bara intresserade av 192.168.1.10 trafik när det är destinationens IP-adress? Beroende på din brandvägg loggformat, kan kommandot se ut så här på en Linux-eller Unix-system:

grep 'dst 192 \ 0,168 \ 0,1 \ 0,10' firewall.log

I Windows, skulle kommandot se ut så här:

grep "dst 192 \ .168 \ .1 \ .10" firewall.log

Notera den enda skillnaden är att Linux och UNIX använder enkla citationstecken, medan Windows använder citationstecken.

Logiskt OCH talet och ELLER s

Ibland måste vi matcha på flera mönster i samma linje. Till exempel vad händer om vi bara vill se TCP/80 trafik till vår webbserver? I detta fall finns det faktiskt två mönster som vi önskar att matcha på samma linje. Problemet är att det kan finnas andra saker i mitten som vi inte bryr oss om.

För att utföra en logisk AND, helt enkelt använda kommandot grep två gånger på samma linje. Till exempel:

grep "dst 192 \ .168 \ .1 \ .10" firewall.log | grep "dst_port 80"

Röret symbolen låter dig helt enkelt köra den andra grep kommandot före avrättningen slutar. Så den första grep kommandot kommer att fånga all trafik som går till 192.168.1.10 och sedan vidarebefordra den till den andra grep kommandot. Den andra grep kommandot söker då denna utgång för all trafik på väg till port 80. Titta noga efter portnummer och du kommer att se att jag ingår ett mellanslag. Utan ett mellanslag, kunde vi potentiellt matcha på port 800, 8080, etc.

Ibland kanske vi vill passa på endera av två värden. Till exempel vad händer om vi ville se både HTTP-och HTTPS-trafik till vår webbserver? I så fall skulle vi behöva göra en logisk och kombineras med en logisk ELLER. Här är hur man gör det med grep:

grep 'dst 192 \ .168 \ .1 \ .10' firewall.log | grep "dst_port \ (80 \ | 443 \) '

Den första halvan av kommandot ska se bekanta, men den andra hälften behöver lite förklaring. Vi måste berätta grep att parentesen tecknen är faktiska kommandon och inte en del av strängen som vi vill matcha. Vi gör detta genom att före dem med ett omvänt snedstreck. Röret karaktär är det som säger grep för att utföra kommandot som en logisk ELLER. Notera röret måste också föregås av ett omvänt snedstreck.

Sortering stockar med grep

OK, så vi har grunderna, nu ska vi börja tillämpa dem att granska en brandvägg loggfil. Det första du behöver göra är att få loggfilen i ASCII-format. Detta är det ursprungliga formatet för många brandväggar, så ingen konvertering kan behövas. Om loggen använder ett eget format, säljaren levererar vanligtvis ett verktyg för att göra konverteringen. Själv skickar jag bara loggarna till ett SIM (http://www.chrisbrenton.org/2009/08/setting-up-a-security-information-management-system-sim-%E2%80%93-part-1/). Därifrån kan du helt enkelt kopiera dem till en arbetskatalog.

Nästa måste vi öppna en textredigerare. Samtidigt som vi kan köra våra grep kommandon på kommandoraden för att testa deras exakthet, vi vill placera kommandona i ett shell-skript eller batch-fil, så att de lätt kan köras senare. För resten av detta inlägg kommer jag att använda enkla citattecken, vilket är syntaxen för både Linux och UNIX. Kom ihåg att din Windows-version av grep kanske vill se citationstecken istället.

Nästa steg är att se över loggfilen söker trafikmönster som du känner igen. Låt oss ta ett lätt som HTTP-trafik till din webbserver. Titta noga på en loggpost och identifiera vilka unika egenskaper det har som talar om sin HTTP-trafik till din webbserver. Troligtvis kommer detta att vara målet IP-adressen för din webbserver, samt ett mål hamn TCP/80. Nu helt enkelt skapa en grep kommando för att kopiera dessa poster till en ny fil:

grep 'dst 192 \ .168 \ .1 \ .10' firewall.log | grep "dst_port 80 '> web_server_http.txt

Observera att i stället skriva utdata till skärmen, vi omdirigeras den till en fil med ett beskrivande namn. På så sätt loggposter finns tillgängliga för senare granskning.

Om vår webbserver är endast erbjuda HTTP, ska vi bara se trafiken på väg till hamn TCP/80. All annan port ansluta försök kan anses misstänkt trafik, och kan vara en del av en skanning eller sond. Med hamn TCP/80 trafiken i sin egen fil, som vi nu helt enkelt omdirigera allt annat till en annan fil:

grep 'dst 192 \ .168 \ .1 \ .10' firewall.log | grep-v "dst_port 80 '> web_server_scan.txt

Detta bör stå för all trafik på väg till vår webbserver. Nu gäller det att få allt detta sparade trafiken ur vägen så att det blir lättare att upptäcka andra poster. Samtidigt som vi kan försöka ta bort dem, skulle det vara klokt att hålla en omodifierad version av brandväggsloggen i fall vi behöver gå tillbaka till den. Det enklaste sättet att hantera denna konflikt är att helt enkelt skapa en ny temporär fil.

grep-v "dst 192 \ .168 \ .1 \ .10 'firewall.log> temp1.txt

Nu öppnar vi helt enkelt "temp1.txt" och leta efter nästa mönster vi känner igen. Låt oss säga att det är inkommande och utgående SMTP. Den del av vårt skript kan se ut så här:

grep 'dst 192 \ .168 \ .1 \ .12' temp1.txt | grep "dst_port 25 '> smtp_inbound.txt

grep 'dst 192 \ .168 \ .1 \ .12' temp1.txt | grep-v "dst_port 25 '> smtp_server_scan.txt

grep-v "dst 192 \ .168 \ .1 \ .12 'temp1.txt> temp2.txt

grep "src 192 \ .168 \ .1 \ .12 'temp2.txt | grep" dst_port 25'> smtp_outbound.txt

grep "src 192 \ .168 \ .1 \ .12 'temp2.txt | grep-v" dst_port 25'> smtp_server_compromise.txt

grep-v 'src 192 \ 0,168 \ 0,1 \ 0,12' temp2.txt> temp3.txt

SMTP är en dubbelriktad tjänst, så de tre första raderna tar hand om inkommande trafik, medan de tre sista titt på utgående. Observera att vi i linje fem räknar med att se servern endast kommunicera på TCP/25. Alla andra försök hamn kan tyda på att systemet har äventyrats och nu kallar hem. Det skulle naturligtvis vara en bra idé att göra samma sak för webbservern:

grep "src 192 \ 0,168 \ 0,1 \ 0,10 'temp3.txt> web_server_compromise.txt

grep-v 'src 192 \ 0,168 \ 0,1 \ 0,10' temp3.txt> temp4.txt

Utgående ut ditt manus

Nu helt enkelt upprepa processen tills du är kvar med en temp-fil som har loggposter du förväntar dig inte att se. Det är nu dags att börja stänga titt manus. Först, byta namn på din sista temporär fil till något som kommer att fånga din uppmärksamhet. På Windows-kommandot skulle vara:

Ren temp23.txt interesting_stuff.txt

På Linux-eller Unix-kommandot skulle vara:

mv temp23.txt interesting_stuff.txt

Denna intressanta filen kommer troligen att bli den första filen som du kommer att vilja att se över, eftersom det kommer att innehålla alla de oväntade mönster. Nu när alla normala trafikflödet är ur vägen, ska det ta betydligt kortare tid att upptäcka vad du verkligen behöver oroa dig.

En trevlig sak om temp-filer är att de kan hjälpa till vid felsökning. Till exempel om grep flyttar 1,5 MB loggposter i en ny fil, kan jag förvänta mig att se nästa temp fil krympa med 1,5 MB också. Om inte, är det något fel i mitt manus. Dessutom, om du märker att alla dina temporära filer efter "temp12.txt" har en noll-fil längd, är chansen att du har ett syntaxfel precis efter att du skapat "temp12.txt".

När skriptet har granskats och arbetar men kanske du inte vill ha de temporära filer i din arbetskatalog. På så sätt är det lättare att fokusera på de sorterade filerna under en översyn. När du når denna punkt, helt enkelt ha den sista raden i ditt manus radera temporära filer. I Windows syntaxen skulle vara:

del / q temp *. txt

och på UNIX eller Linux kommandot skulle vara:

rm-f Temp *. txt

Automatisera processen

När du har en fungerande manus, är det nu dags att automatisera processen. Om du kör Linux eller Unix, helt enkelt ställa in skriptet att köras via cron. Om du behöver hjälp med att konfigurera ett cron-jobb finns det några utmärkta hjälpsidor . Motsvarande i Windows kallas en schemalagd aktivitet, och Microsoft har några utmärkta hjälp i kunskapsdatabasen .

Avslutande tankar

Jag nämnde i mitt förra inlägg att jag gillar att leta efter fel paket. Jag kommer oftast göra det rätt i början av mitt manus. Dessutom är det inte ovanligt för system att ringa hem, för att kontrollera om det finns fläckar. Jag brukar sätta dessa undantag i början av mitt manus också. Något i stil med:

grep 'dst 1 \ 0,2 \ 0,3 \. [60-61] "firewall.log> server_patching.txt

grep 'dst 10 \ 0,20 \ 0,30 \. [1-8]' firewall.log >> server_patching.txt

Det första kommandot griper all trafik leds till 1.2.3.60 eller 1.2.3.61. Den andra ser ut för trafik på väg till 10.20.30.1 - 10.20.30.8. Var mycket försiktig i att ange flera system! Detta är ett bra sätt att missa något intressant i dina loggfiler. Du bör endast använda den här syntaxen för att beskriva kända patch-server. Ange aldrig alla subnät för ett visst företag. Till exempel om du filtrera bort alla Microsoft IP-adresser på detta sätt, än en enda ägd systemet på deras nät kunde styra robotar i ditt nätverk och du skulle aldrig veta det.

Denna syntax är också praktiskt när man skriver filter för utgående loggposter. Till exempel anta att vi använder 192.168.1.0 - 192.168.1.24 för intern adressering. För att ta alla utgående HTTP-trafik skulle vi kunna säga:

grep "src 192 \ .168 \ [1-24] \ [0-255].". temp15.txt | grep "dst_port 80 '> outbound_http.txt

Som nämndes i förra inlägget, kanske vi vill kontrollera utgående HTTP under icke-kontorstid för att se om vi har någon skadlig kod ringer hem.

Glöm inte att du kan använda grep som en del av granskningsprocessen också. Till exempel låt oss säga att vi ser över interesting_stuff.txt och upptäcka en källa IP (1.2.3.4) vi vet är fientlig. Vi vill kontrollera filen för att se om det finns några andra IP-adresser som vi behöver vara oroliga med. Samtidigt som vi kunde hålla bläddrar igenom filen, skulle en enklare lösning vara att använda grep:

grep-v 1 \ 0,2 \ 0,3 \ 0,4 interesting_stuff.txt

Du granska manus har potential att fungera som en mini-IDS-system. Med detta menar jag om du hittar ett misstänkt mönster men räkna ut vad som händer, var inte rädd för att utnyttja ditt manus för att kategorisera detta mönster i framtiden.

Till exempel, låt oss säga att vi märker ett antal system på Internet som försöker komma åt port 5060, men vi har inte den här porten öppnas genom vår brandvägg. En snabb Google-sökning kommer att tala om för oss att detta är SIP (http://en.wikipedia.org/wiki/Session_Initiation_Protocol) trafik. Varför bry sig om att slå upp det varje gång vi ser det men om vårt skript kan identifiera det för oss? Nu när vi vet att 5060 är SIP, helt enkelt lägga till följande rader i vårt manus:

grep 'dst_port 5060' temp.txt> sip_traffic.txt

Vi kan göra samma sak för alla portar som ofta som sonderas .

Exec Sammanfattning

Vad gör brandväggslogg översyn så tidskrävande är att du måste gå igenom alla de vanliga trafikmönster för att hitta de loggposter som identifierar en sann säkerhetsproblem. Av vit lista alla förväntade trafikmönster, blir det mycket enklare att hitta och granska eventuella oväntade poster i dina loggar. Genom att ytterligare automatisera processen för sortering stockarna kan loggen reduceras till en snabb aktivitet som lätt kan utföras på en daglig basis.

Hur att granska en brandvägg Logga in 15 min eller mindre - Del 1

25 September 2009

En av de svåraste och mest tidskrävande delarna av upprätthållande av en omkrets granskar brandväggsloggar. Det är inte ovanligt att en organisation för att generera 50, 100, 500 MB eller mer värde av brandväggsloggposter på en daglig basis. Uppgiften är så skrämmande faktiskt, att många administratörer väljer att ignorera sina loggar. I den här serien jag ska visa dig hur att påskynda brandväggsloggen granskningsprocessen så att du kan fylla i det snabbare än den där morgonen kopp kaffe.

Varför brandväggslogg översyn är viktig

Jag tog en gång en del i en paneldiskussion där en av mina kolleger SANS instruktörer meddelade till folket "omkretsen är död och bara brist på värdelösa". Jag minns att jag tänkte att jag var glad att jag inte var en av hans elever. Jag ibland ta på sig nya kunder och tycker att 7/10 gånger jag kan identifiera åtminstone ett äventyras system som de inte visste om. I varje fall har det varit kundens egna brandväggsloggar som pekade mig till det infekterade systemet.

Förr brandväggslogg recension handlade om att kontrollera dina inkommande drop poster för att leta efter portsökningar. Idag ligger fokus på utgående trafik. Specifikt bör du kolla tillåtna mönster. Med den uppsjö av icke-signatur Malware idag har det blivit alldeles för lätt för en angripare att få skadlig kod på en dator. En korrekt konfigurerad omkrets visar dig när ett äventyras systemet försöker ringa hem. Detta är oftast din bästa chans att identifiera när ett system har blivit nedsatt.

Vad behöver vara inloggad?

Tappade trafiken behöver inte vara inloggad förutsatt att du inte är blind för DoS översvämning attacker. Till exempel om du kör ett verktyg som NTOP på din omkrets, samla RMON eller Netflow uppgifter, än det är OK att inte logga ignorerade paket som du kan samla in denna information på annat sätt.

När trafiken är tillåten i hela omkretsen dock måste du logga den. Detta inkluderar all tillåten trafik, oavsett riktning (avstigning samt inträngande). Vid minst vill vi se huvudinformation för det första paketet i en session. Något bortom som kan anses vara en bonus.

Vissa kernel nivå rootkits gör ett utmärkt jobb med att dölja sig i den infekterade systemet. Faktum är att många är så smygande att de inte kan upptäckas genom kontroll av systemet direkt. Ett möjligt alternativ är att dra ut hårddisken och kolla upp det från en känd för att vara rent system. Detta är givetvis mycket opraktiskt när du har mer än bara ett par system.

Ett bättre alternativ är att kolla på nätet för att berätta tale tecken på skadlig kod som kallar hem. Malware skapar vanligtvis utgående sessioner antingen överföra en verktygslåda eller checka in för marschorder. Brandväggen är i en optimal position för att potentiellt blockera, eller åtminstone log båda dessa aktivitetsmönster. Så genom att se över våra brandväggsloggar, kan vi snabbt kontrollera alla system på vårt nätverk för tecken på en kompromiss.

Malware kan utnyttja varje uttag för att ringa hem, men de flesta använder TCP/80 (HTTP) eller TCP/443 (HTTPS). Detta beror på att Malware författare vet de flesta brandväggsadministratörer logga inte dessa utgående sessioner eftersom de är ansvariga för den största delen av omkretsen trafik. Så återigen, om vi ska tillåta trafiken att passera vår omkrets, måste vi försäkra att vi loggar det.

Log recension som en process

Misstaget jag ser de flesta administratörer gör är att de utför en tids linjär analys av deras loggposter söker "det intressanta saker". Problemet är misstänkt trafik kan vara mycket svårt att upptäcka detta sätt eftersom det kommer att blandas in med normala trafikflödet. Så det första vi måste göra är att få den normala trafiken ur vägen.

Tänk på rektangeln i figur # 1 som representerar din brandväggslogg. Antag att den innehåller en blandning av normala och misstänkta trafikmönster. I stället för att genast leta efter de misstänkta mönster, låt oss först få de normala mönster ur vägen. Till exempel HTTP-headed till vår webbserver från Internet är ett förväntat mönster. Om vi ​​drar alla dessa poster ur loggfilen blir loggfilen lite mindre. Inkommande och utgående SMTP till vår e-postserver är ett annat förväntat mönster. Återigen, om vi kan ta bort dessa poster samt brandväggsloggfilen blir ännu mindre.

firewall-log-review-process

Nu har vi helt enkelt fortsätta den här processen för varje trafikmönster som vi förväntar oss att se att korsa vår omkrets. Ju fler trafikmönster som vi känner igen och flytta ur vägen, blir det mindre slut loggfil. Vad som finns kvar är bara de oväntade trafikmönster som kräver översyn tid från en brandvägg administratör. Jag har sett platser som vanligtvis genererar 250-300 MB värde av stockar dagligen sluta med en sista fil mindre än 100 KB i storlek. Naturligtvis 100 KB tar mycket mindre tid att granska att 300 MB.

Automatisera, automatisera automatisera

Om detta verkar vara en hel del arbete, bara det att vara en början. Vad jag gör är att skapa en batch-fil, skalskript, eller uppsättning av databasfrågor för att automatisera processen med att analysera den brandväggsloggen. Vi kan sedan köra denna process som ett cron-jobb eller schemalagd aktivitet. Det innebär att allt det hårda arbete (bryta upp huvudloggfilen i mindre filer) kan göras av timmar. När du kliver in genom dörren på morgonen, kommer loggfilen redan segregerade. Du kan sedan omedelbart fokusera på de misstänkta mönster.

Nyttiga tips

Här är några tips som jag har utvecklats under åren:

  • Det finns ingen "enda rätta sättet" att segregera loggposter. Det handlar om hur du själv upptäcka oanade mönster. Du kan sortera efter IP-adress, portnummer, eller vad info du har att arbeta med i dina loggar.
  • Detta handlar inte om att tvångsmässigt sätta en loggpost i varje slags fil. Processen handlar om att skapa lättare att upptäcka mönster. Till exempel en TCP-reset i en HTTP-ström kan gå i både ett "fel" fil och en "HTTP" filen. Varje skulle göra det lättare att upptäcka olika typer av mönster.
  • Börja med att dra våra fel paket (TCP återställer, ICMP typ 3: s och 11 s). De visar alltid något är sönder eller någon gjorde något oväntat.
  • En smart angripare kommer aldrig att göra din "topp 5 kommunikatörer" listan. Jag har sett infekterade system gör så få som fyra utgående anslutningar i en dag.
  • Anteckna den genomsnittliga storleken på alla dina sorteringsfiler. En kraftig stegring i trafiken kan motivera ytterligare utredning.
  • Ibland är det till hjälp att tolka samma mönster i två olika filer. Exempelvis skapar jag en "outbound HTTP" filen, och sedan extrahera all trafik genererar under icke-kontorstid. Detta gör det mycket lättare att hitta infekterade system ringer hem.
  • Vitlista vet lapp webbplatser. Till exempel system kan ringa hem hela natten till Microsoft och Adobe att kolla efter uppdaterade patchar. Om du kan tolka in dessa poster, kommer du att sluta med betydligt mindre brus i din slutliga filen.
  • Vissa webbplatser vara till hjälp att tolka ut användare som checkar deras personliga e-post. Detta kan vara användbar information om dataläckage inträffar.
  • Jag gillar att segregera trafik baserat på säkerhetszonen. Till exempel skulle jag vara mycket mindre bekymrade över SSH från det interna nätverket till DMZ, än jag skulle om SSH leds till Internet. Om du inte är säker på varför, läs det här .
  • I en perfekt värld, kommer någonsin trafikmönster som du hittar beskrivas i organisationens nätverk användningspolicy. Om det inte, då ytterligare utredning erfordras.
  • Räkna med att justera din manus med tiden, eftersom näten är en framväxande enhet.

Exec Sammanfattning

Vita notering förväntade trafikmönster i brandväggsloggen kan hjälpa till att påskynda log granskningsprocessen. Liknande trafiken blir grupperas tillsammans, och kan lättare kontrolleras för misstänkta mönster. I del 2 i denna serie kommer jag att gå igenom processen att skapa dina egna skript med ett antal olika brandväggsprodukter.

Skoja din IP-adress under en Port Scan - Del 2

31 aug 2009

I mitt förra inlägg jag diskuterade en inaktiv skanning och hur den kan tillåta en angripare att dölja sin IP-adress under en port scan. I den här delen ska vi titta på några spår, samt diskutera hur man identifierar när en inaktiv skanning har använts mot ditt nätverk.

Övervakning IP-ID ökningen

Låt oss börja med att titta på de paket som övervakar IP-ID-fältet i Windows-systemet. Här är vad vår sond paket såg ut:

07:22:15.367140 IP (tos 0 × 0, ttl 64, ID 63897, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.1.2203> 192.168.100.2.0:., Cksum 0xeca2 (korrekt), vinner 512

Några av dessa områden är ganska intressant. TTL-värdet är satt till "64", vilket tyder på en Linux-eller Unix-system. Eftersom vi är rå skriva paketet direkt till tråden detta värde styrts av hping. 64 bara råkar vara program standard, men vi kan ändra värdet till något vi vill med den "-t" switch.

Målet adress skrivs ut som "192.168.100.2.0", vilket betyder att paketet skickades till TCP-port 0 på IP-adressen 192.168.100.2. Windows erbjuder inte tjänster på TCP-port 0 men det är OK. Vi är faktiskt inte försöker ansluta till Windows-systemet. Vi behöver bara den för att skicka oss ett IP-paket så att vi kan kontrollera IP-ID-värde. Om vi ​​ville träffa en annan port, kan vi använda hping s "-p" switch.

Den ".," Efter målspecifikation innebär att inga TCP-flaggor sattes i paketet. Detta hänvisas till som en null packet och skulle aldrig inträffa under normala IP-kommunikation. Därför kan NIDS, NIPS och brandväggar flaggar den. Vi skapade en noll paket eftersom vi inte berätta hping att skickade någon av TCP-flaggor. Till exempel att lägga till "-S" switch skulle ha vänt på SYN flaggan, "A" skulle slå på kvittering flaggan, och så vidare.

Alla våra probpaket till Windows-system skulle se ut ungefär så här. De enda värden som skulle förändra är tidsstämpeln (uppenbarligen), TCP källport och CRC kontrollsumma värdet.

Här är vad svaren ser ut att komma tillbaka från Windows-systemet:

07:22:15.367296 IP (tos 0 × 0, ttl 128, ID 108, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (korrekt), 00:00 (0) ack 918.250.228 vinna 0



07:22:16.367453 IP (tos 0 × 0, ttl 128, ID 109, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2204: R, cksum 0xfa78 (korrekt), 00:00 (0) ack 2127488152 vinner 0



07:22:17.367763 IP (tos 0 × 0, ttl 128, ID 110, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (korrekt), 00:00 (0) ack 1611256374 vinner 0

Det viktiga värde här är IP-ID, som identifierats som "id". I det första paketet den är inställd på 108, och sedan ökar värdet med 1 för varje efterföljande paket (109 sedan 110). Så länge vi fortsätter att se en oavbruten sekvens i IP-ID, vi vet att Windows-systemet inte sänder några andra paket utom de som ingår i denna session.

Probing en stängd port

Kom ihåg att som en del av vår scan, kommer vi att skoja källan IP-adressen för Windows-systemet när mål-portar på ett fjärrsystem. En förändring av IP-ID ökningen är det som säger att vi hittade en öppen port.

Låt oss ta en titt på en av dessa kan paket:

10:30:28.852602 IP (tos 0 × 0, ttl 64, ID 41256, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.1266> 192.168.100.3.79: S, cksum 0x97a6 (korrekt), 1704542340:1704542340 (0) vinner 512

Notera källan IP-adressen är att Windows-systemet (192.168.100.2). Vi vet att detta inte kunde ha kommit från Windows-systemet men eftersom TTL är satt till 64. Så det här är ett paket som vi genererat från 192.168.100.1 använder en andra instans av hping.

Observera också att vi har riktat TCP-port 79 och har aktiverat SYN flaggan. Här är den respons vi fått från den avlägsna mål:

10:30:28.852839 IP (tos 0 × 0, ttl 64, id 0, offset 0, flaggor [DF], proto TCP (6), längd 40) 192.168.100.3.79> 192.168.100.2.1266: R, cksum 0xbb1a (korrekt), 00:00 (0) ack 1704542341 vinner 0

Notera värdet "R" som berättar återställnings flaggan var aktiverat i TCP-huvudet. Vi ser också "ack", som berättar bekräftelsen flaggan var påslagen också. Detta är ett felpaket informera källan att TCP-porten befinner sig i ett stängt tillstånd. Notera även paketet sänds till Windows-systemet eftersom det var källan IP-adress i sonden paketet.

Så hur kommer det Windows-systemet reagera? Du kanske minns från mitt förra inlägg att RFC staten ska du aldrig svara på ett fel paket. Även om Windows-systemet inte har någon aning om vad målet talar om, kommer det tyst kasta detta fel paket. Med andra ord kommer Windows-systemet inte skicka ett svar. Detta innebär att vi bör se någon förändring i IP-ID steg.

Probing en öppen port

Nu ska vi ta en titt på vad som händer när vi riktar en port som faktiskt är i ett öppet tillstånd. Här är sonden paketet. Observera att det är ganska lik den förra, utom nu vi kontrollerar TCP-port 80.

10:29:46.947964 IP (tos 0 × 0, ttl 64, ID 15249, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (korrekt), 947341260:947341260 (0) vinner 512

Här är responsen från målet. Observera att vi se ett "S" i stället för ett "R", som betyder att de SYN flaggan är påslagen snarare än återställningsflaggan. Detta är det mål sättet att informera källan som TCP-port 80 är öppen och har ett program som sitter bakom den service anslutningar.

10:29:46.953333 IP (tos 0 × 0, ttl 64, id 0, offset 0, flaggor [DF], proto TCP (6), längd 44) ​​192.168.100.3.80> 192.168.100.2.1984: S, cksum 0x0de6 (korrekt), 262246932:262246932 (0) ack 947.341.261 vinner 5840 <mss 1460>

Så den här gången Windows-systemet tar emot ett paket som säger "Visst, kan du ansluta till TCP-port 80". Detta är ett problem för Windows-systemet eftersom det har något samband posten som säger att det faktiskt försökte ansluta till port 80 på målet. Utan anslutnings posten, har Windows ingen möjlighet att veta vilket program som begärt mötet. Med detta i åtanke, gör det det enda den kan göra; sända ett återställningspaket till målet att döda sessionen. Här är vad paketet såg ut:

10:29:46.953439 IP (tos 0 × 0, ttl 128, ID 176, offset 0, flaggor [ingen], proto TCP (6), längd 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (korrekt), 947341261:947341261 (0) vinner 0

Observera att Windows stämplat nästa tillgängliga IP-ID i IP-huvudet (176). Så hade vi övervaka IP-ID ökningen i Windows-systemet i en annan session, skulle vi se: 173, 174, 175, 177, 178, 179 med andra ord, skulle vi ha sett att 176 saknades (två från. det föregående paketet). Detta skulle vara vår indikation på att TCP/80 sonden skickas till målet slog en öppen port.

Identifiera en inaktiv skanning

Så en inaktiv skanning gör ett utmärkt jobb med att maskera den verkliga källan IP-adressen för en port scan. Det betyder att utan tillgång till logginformation på Windows värd (något som inte kommer att finnas om attacken har gjort sin hemläxa), kommer vi aldrig att kunna upptäcka den verkliga källan IP-adressen för attacken.

Finns det ett sätt att berätta en inaktiv skanning utfördes snarare än en rättfram port scan så vi vet om det är värt att undersöka källan IP-adress? Det finns faktiskt ett par ledtrådar som vi kan leta efter.

Probe omförsök

Om den riktade systemet sitter bakom en brandvägg, kommer du att märka en skillnad i antalet sondförsök mot en vanlig port scanner. När någon kör en vanlig port scanner, kommer skannern vanligtvis slog öppna portar bara en gång utan brandvägg hamnar flera gånger. Detta beror på att firewalled portar återgå inget svar. The scanner will make multiple attempts to ensure the packets are not just getting lost. Since the open port will actually respond, only one probe packet is required.

When an idle scan is performed, the opposite is true. If a firewalled port is probed there will be no IP ID increment change on the Windows system. So only one check is required to confirm this is not an active listening port. When an open port is probed however, we'll detect a change in the Windows system's IP ID increment. While we think this is due to us finding an open port, it could just as likely be because the Windows system sent a broadcast. So we will want to perform multiple probes against the open port to ensure the Windows IP ID data remains constant.

So:

  • Probe firewalled ports more often than open ports = normal port scanner
  • Probe open ports more often that firewalled ports = idle scan

Timing

Normal port scans be extremely fast. It is not uncommon to see hundreds of probe packets per second. With an idle scan however, we have to take things a bit slower. This is because we must check the IP ID of the spoofed address, send the probe packet, permit enough time for the probe to elicit a response, give the spoofed system enough time to respond with a reset if required (thus using up an IP ID), and then check the IP ID again to see if the increment has changed.

Try to perform all of these steps too quickly, and you will pay the price in accuracy. For example nmap supports idle scans with the “-sI” switch. The default extremely fast scanning speed works fine if all of the systems are on the same switched network. If the hosts are 15 hops away from each other on the Internet however, my experience has been the accuracy rating drops off considerably unless you slow down the scanning speed.

So:

  • Hundreds of packets per second = normal port scanner
  • A dozen or less packets per second = possible idle scan, could just be a slow scan

TTL field

Let's look again at the spoofed probe packet as well as the legitimate reset response sent by the Windows system:

10:29:46.947964 IP (tos 0×0, ttl 64, id 15249, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: S, cksum 0x476b (correct), 947341260:947341260(0) win 512



10:29:46.953439 IP (tos 0×0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), length 40) 192.168.100.2.1984 > 192.168.100.3.80: R, cksum 0x5df1 (correct), 947341261:947341261(0) win 0

You may have noticed the TTLs are way off from each other. If both of these packets had in fact originated from 192.168.200.2 then they would both have the same starting TTL value. The fact that they are different tells us that one of them is spoofed.

If you are monitoring the perimeter of the target system and notice that the SYN and reset packets have different TTL values, that's a clue that you may be experiencing an idle scan. Now, as mentioned earlier, it is entirely possible to set the TTL to what ever we wish in our spoofed packet. So a smart attacker is simply going to set their starting TTL to 128 to better mimic the Windows system. If they do this, your only hope is that the attacker and the Windows system are a different number of hops away. In other words, if you consistently see the SYN packets with a TTL of 115, but the resets consistently have a TTL of 113, you are most likely looking at an idle scan.

If the TTLs do match, we can't entirely rule out an idle scan. The attacker may just be that good.

So:

  • TTLs of SYNs and RSTs are consistent but do not match = idle scan
  • TTLS of SYNs and RSTs match = normal port scanner or smart idle scanner

IP ID value

The best way to tag an idle scan is leverage the same thing the attacker uses, namely the IP ID value. Take another look at those last two decoded packets. Note that the IP ID in the first one is 15249 but in the second it is 176. If you are seeing an idle scan, you will notice the rest packets consistently have an IP ID of +2 (same thing the attacker sees), but the SYN packets will have some completely unrelated value. The IP ID increment in the SYN packets might be predictable or it might be random. Quite honestly it does not matter. What does matter is that you can spot some pattern in IP ID of the rest packets that does not jive with the IP IDs in the SYN packets.

So:

  • IP ID of SYN and RST packets appear related = normal port scanner
  • IP ID increment of RST does not match SYNs = idle scan

Exec Sammanfattning

Hopefully you now have a better understanding of what is happening on the wire when an attacker performs an idle scan. If we are targeted with an idle scan, we cannot determine the true source IP address of the attacker. The best we can hope to accomplish is to determine that the scan is an idle scan vs. a normal port scan. There are a number of tell tale clues in packets, the best of which is the IP ID value.

Spoofing Your IP Address During A Port Scan – Part 1

August 28th, 2009

I love debunking myths, one of my favorites is “a port scanner must reveal his true source IP address”. In this series I'll show you how to perform a port scan while hiding your source IP address from the host being scanned. I'll also tell you how you can detect the technique when it is used against you.

Nmap's decoy mode

An alternative to the technique I will describe is nmap's decoy mode. With decoy mode you identify a number of bogus source IP addresses. From the target host, it looks like all of the bogus IP addresses, as well as the true source IP address, are all performing a port scan at the same time. The concept is the administrator under attack will have no way of knowing which IP address is in fact the true IP performing the scan.

This technique really does not mask the true source, as the source IP address is one of the IPs performing the scan. If you know what to look for, you can easily figure out which source IP is actually scanning you. So while this technique will work, it is not completely effective at hiding the source IP address.

What is an idle scan?

When we perform an idle scan, we do not actually directly detect open ports. Rather, we detect the effect an open port would have on a third party system. The technique is similar to how many viruses are detected in the human body. Rather than detecting the actual virus, we look for antibodies that get produced when the virus is present in the system. An idle scan detects open ports in much the same fashion.

Before we can dig too deeply into an idle scan, we need to look at some of the intricacies of IP.

Predictable header values

While the RFCs are designed to be specific enough that dissimilar operating systems will still be able to communicate via IP, they still leave quite a bit open to interpretation. For example, the RFCs specify that the maximum Time To Live (TTL) value that can be used is 255. They do not however specify what initial TTL value must be used; so different operating systems use different starting TTLs. The RFCs describe how Ping should work, but do not specify what should be in the payload of Echo-Request packets. Again, different vendors use different values. These nuances can permit you to identify the source operating system based variations in the packet contents. The technique is referred to as passive fingerprinting .

The IP identifier (IP ID) field in the IP header (bytes 4 and 5) is a similar situation. RFC 791 specifies that the number must be unique on a per host, per session basis. For example let's say I connect to a remote SSH server. Each IP ID in that session must be unique. If I close the session and then connect back later, it is RFC compliant if one or more IP ID values get used again. They don't have to be, but if it does happen it is not a problem.

So the RFCs say the IP ID needs to be unique, but it does not really tie down how to go about generating the value. This has lead to different operating systems deploying different methodologies. For example Windows starts at an IP ID value of 1 and simply increments the value by +1 for every packet leaving the system. When the maximum value of 65,535 is reached, it starts back over at 1. BSD puts a random value into the IP ID field of each packet leaving the system. Linux is random for TCP packet (except initial responses which are always zero), +1 incremental for ICMP, and time based for UDP. Whew!

The one that is interesting for our purposes is Windows. The fact that each packet leaving the system gets a +1 IP ID makes the value extremely predictable. For example, consider the following output:

[root@fubar ~]# hping -r 192.168.100.2

HPING 192.168.100.2 (eth0 192.168.100.2): NO FLAGS are set, 40 headers + 0 data bytes

len=46 ip=192.168.100.2 ttl=128 id=108 sport=0 flags=RA seq=0 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=1 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=2 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+2 sport=0 flags=RA seq=3 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=4 win=0 rtt=0.4 ms

len=46 ip=192.168.100.2 ttl=128 id=+1 sport=0 flags=RA seq=5 win=0 rtt=0.4 ms

hping is a packet crafting tool which allows you create your own IP packets. In the above output we are using the “-r” switch to have hping monitoring the IP ID increment of a remote system. We know it is a Windows system, because Windows always uses a starting TTL of 128. Now look at the “id=” values. In the first line of output hping always prints out the absolute IP ID value used by the system. In this case here the value is 108. Each subsequent line then prints out the delta change from the previous packet. So in the second line the actual IP ID was 109, which is “+1” from the previous value of 108. The next packet had an IP ID of 110, which is “+1” from the previous IP ID value of 109.

Look closely at the fourth line of output. Note the delta change was “+2”. Since Windows uses sequential IP IDs, this tells us a packet we didn't get to see just left the Windows system. We don't know where it was going, but that's OK. What's important is that we can identify when the Windows system transmits and how many packets it sends out. For example had that line read “+5”, we would know that the Windows system transmitted four other packets since responding to our last probe.

Detecting open ports

So how can we leverage the predictable IP ID value of Windows for evil? One possibility is to turn the Windows system into an open port sensor. Here's how we do it:

  1. Monitor the current IP ID being used by a Windows system. We should check the value at regular intervals over a relatively short period of time. Say once second.
  2. Find a target system we wish to port scan.
  3. While spoofing the source IP address of the Windows system, send a SYN packet to the TCP port we wish to probe on the target.

The target system will send a response packet back to the Windows system. This response will either be:

The RFCs state you should never respond to error packets, regardless of whether you consider them to be legitimate or not. So when the Windows box receives the TCP reset error packet from the target host, it quietly ignores and discards the packet.

Things get a bit more interesting when a SYN/ACK is received however. From the Windows system's perspective, it is just hanging out minding it's own business when some unknown system sends it a SYN/ACK packet (remember we spoofed the Windows system's IP address in the probe packet). A SYN/ACK effectively means “Sure, you can connect to me on that TCP port, no problem”. Of course since the Windows system didn't actually send the SYN packet, it has no idea what the remote target is talking about.

With this in mind the Windows system sends a TCP reset error packet back to the target host. When the reset packet is transmitted, the next available IP ID is used within the IP header. This missing IP ID would be detected if we are still monitoring the IP ID increment once per second. So to review:

  • Closed port on target = No packets leaving Windows system
  • Open port on target = Windows sends a TCP reset using up an IP ID

So by monitoring the IP ID increment, we can identify when an open port is discovered as only probes to open ports will cause the IP ID increment to change.

Caveats

You can't use just any Windows system for this attack. The box must meet certain criteria:

  • Relatively quite system generating little traffic (like a home system)
  • No stateful filtering of TCP traffic

Of course go to any cable or DSL network at 2:00 AM local time and you can find hundreds of thousands of systems that meet these criteria. Remember that Windows systems love to arbitrarily broadcast, so you may wish to perform multiple check of each open port just to ensure the IP ID increment change was in fact due to an open port being probed.

Exec Sammanfattning

An idle scan lets you probe open ports on a remote target, while fooling the target into believing that some third party system is performing the scan. Open ports are detected by monitoring for irregularities in the IP ID increment of the Windows box.

In the next installment we'll actually see what these packets look like on the wire as well as discuss how to detect an idle attack when it is used against you.

Network Mapping Through A Firewall – Part 3

August 26th, 2009

In my last two posts I talked about two different methods that can be used to map a network through a firewall. The first leveraged ICMP time exceeded in transit errors, while the second used the IP record route option. In both posts I also gave possible solutions for preventing an attacker from using these techniques against your network.

In both cases however, supported features available in commercial grade firewalls limited our security options. In this third and final part of the series, I will cover how to properly prevent these attacks if you are using an open source firewall. I will specifically be using Netfilter , but many of the techniques are applicable to pf as well.

What is Netfilter?

Netfilter is the stateful inspection firewall that is included in every modern distribution of Linux. If you have a copy of Linux, you also have a copy of Netfilter. Netfilter is sometimes referred to as iptables , but this is because iptables is the name of the binary you use to manipulate the Netfilter rulebase. Netfilter is an extremely capable firewall with too many features to cover in this post. I highly recommend you check out some of the FAQs and tutorials as they do an excellent job of describing many of the features.

Controlling tcptraceroute

In the first post I described how tools like tcptraceroute could punch through an open firewall rule to map the network sitting behind it. With commercial firewalls, we were limited to controlling the flow of outbound ICMP time exceeded in transit errors.

With Netfilter, we have the ability to control traffic based on the TTL value. We can look for a specific value, or a value above or below a certain threshold. The supported switches are:

  • -m ttl –ttl-eq = Match packets with a TTL of a specified value
  • -m ttl –ttl-gt = Math packets with a TTL higher than a specified value
  • -m ttl –ttl-lt = Match packets with a TTL below a specified value

Here is a possible Netfilter rule we can use:

iptables -A FORWARD -m ttl –ttl-lt 5 -j DROP

This rule would be processed prior to any permit rules in the rulebase. The rule simply checks the TTL value to see if it is less than 5. If so, the packet is dropped. Since the lowest TTL used by a modern OS is 64, and most systems are about 15 hops away from each other on the Internet, we should never inadvertently filter out legitimate traffic.

Here's tcptraceroute running though a regular firewall:

[root@fubar ~]# tcptraceroute -n -f 1 -m 5 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 39142 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 5 hops max
1 10.1.2.2 0.353 ms
2 10.1.4.1 0.450 ms
3 10.1.4.10 [open] 0.586 ms

And here is what tcptraceroute sees once we implement the above Netfilter rule:

[root@fubar ~]# tcptraceroute -n -f 1 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 54531 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 30 hops max
1 10.1.2.2 10.175 ms
2 10.1.4.1 0.464 ms
3 *
4 *
5 *
6 *
7 10.1.4.10 [open] 1.007 ms

Note that once we start filtering on TTL value, the appearance of our perimeter changes. Without the rule an attacker could enumerate or IP addressing scheme. Even if we filtered outbound TimeX packets, they would still know the proper hop count. The Netfilter rule makes it much more difficult to accurately identify our network layout.

Adding in some deception

One of the more powerful features of Netfilter is the ability to customize reject messages. While most firewalls reject packets by returning an administratively prohibited error message, Netfilter lets you choose from a number of different unreachable error codes. This makes for some interesting possibilities. For example, consider the following rule:

iptables -A FORWARD -m ttl –ttl-lt 5 -j REJECT –reject-with icmp-host-unreachable

This rule tells Netfilter that whenever it sees a packet with a TTL less than 5, it should return an ICMP destination host unreachable packet. In other words, Netfilter will impersonate a router and tell the transmitting system that the target host is off-line. Here's an example of tcptraceroute output once this rule has been implemented:

[root@fubar ~]# tcptraceroute -n -f 1 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 47555 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 30 hops max
1 10.1.2.2 0.299 ms
2 10.1.4.1 0.450 ms
3 10.1.4.1 0.403 ms !H

Compare this output to the first tcptraceroute output shown above. Note that line 3 is now different. With a regular firewall, hop three was a response from the target host. In this output however, it appears the upstream router is returning an ICMP host unreachable (designated as “!H”) signifying the host is off-line. Since tcptraceroute thinks the host is off-line, it gives up trying and never actually reaches the target host.

So while this technique is a bit of security through obscurity, it is effective at disabling a tool that would normally punch right through a firewall. Since regular traffic would not have an abnormally low TTL value, it does not match this rule and is unaffected.

Controlling record route

In my second post in this series I talked about record route and how it can be leveraged to map through a firewall. I discussed that the range of the tool is limited (max 8 hops, 3 if you want hop info in both directions), but that there are ways for an attacker to get around this restriction. I also mentioned that commercial firewalls typically do not give you the ability to control record route traffic.

With Netfilter, there is support for controlling IP options via the ipv4options module (http://netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html). The supported switches are:

  • -m ipv4options –ssrr = Match packets with strict source routing set
  • -m ipv4options –lsrr = Match packets with loose source routing set
  • -m ipv4options –rr = Match packets with record route set
  • -m ipv4options –ts = Match packets with timestamp set
  • -m ipv4options –ra = Match packets with router-alert set
  • -m ipv4options –any-opt = Match packets with at least one IP option set

Here's an example of a rule that would block packets with the source route option set:

iptables -A FORWARD -m ipv4options –rr -j REJECT –reject-with icmp-host-unreachable

Note we are sending back an ICMP host unreachable in response. This is in order to shutdown the tool mapping our network.

Exec Sammanfattning

While commercial firewall excel at centralized management and selecting pleasing colors for their graphical interface, they usually pale in comparison to open source firewalls with regards to controlling traffic on the wire. In order to protect their networks, firewall administrators need greater control of the IP header than simply scrutinizing the source and destination IP address.

Network Mapping Through A Firewall – Part 2

August 25th, 2009

In my last post I discussed how to use ICMP time exceeded in transit errors to map a network perimeter. I also discussed how to prevent attackers from using this technique against your network. In this post I'll discuss another network mapping technique using the record route IP header options.

Ipv4 header options

The IP header is normally 20 bytes in size but can grow larger if one or more options are enabled. IP options get added to the end of the IP header, as shown in Figure #1. There are a number of registered IP options . The ones most frequently implemented however are the ones defined in RFC 791 . Most operating systems and hardware devices have implemented the IP option record route (option 7), which is a part of the RFC 791 specification.

IP-Header-options

Record Route

The record route option can produce similar data to traceroute, but has a completely different methodology for identifying intermediary hops. As I discussed in my last post, traceroute uses the receipt of ICMP time exceeded in transit errors to map all of the network hops between two points. This requires multiple packets to be transmitted, as the tool needs to increment the TTL value.

Record route does not vary the TTL, and only requires a single packet to record hops along a link. Since the option exists within the IP header, it can be leverage with any IP transport or application.

Here is example output of a record route session using Ping under Linux:

[root@fubar ~]# ping -c 1 -R 192.168.204.10

PING 192.168.204.10 (192.168.204.10) 56(124) bytes of data.

From 192.168.201.1: icmp_seq=1 Redirect Host(New nexthop: 192.168.202.2)

64 bytes from 192.168.204.10: icmp_seq=1 ttl=125 time=6.56 ms

NOP

RR: 192.168.201.10

192.168.201.1

192.168.202.1

192.168.203.1

192.168.204.10

192.168.204.1

192.168.203.2

192.168.202.2

192.168.201.10

— 192.168.204.10 ping statistics —

1 packets transmitted, 1 received, 0% packet loss, time 6ms

rtt min/avg/max/mdev = 6.564/6.564/6.564/0.000 ms

Note that by setting the record route option in Ping (the “-R” switch) we've recorded all the router hops out to the target system at 192.168.204.10, and back again. So we've effectively generated a map of the network between the two points.

Record route decode

Here is an example decode of a record route packet:

07:04:32.934999 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 124, options (NOP,RR 192.168.201.10, 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0)) 192.168.201.10 > 192.168.204.10: ICMP echo request, id 43604, seq 1, length 64

0×0000: 4f00 007c 0000 4000 4001 6858 c0a8 c90a O..|..@.@.hX….

0×0010: c0a8 cc0a 0107 2708 c0a8 c90a 0000 0000 ……'………

0×0020: 0000 0000 0000 0000 0000 0000 0000 0000 …………….

0×0030: 0000 0000 0000 0000 0000 0000 0800 5df6 …………..].

0×0040: aa54 0001 4022 914a 2544 0e00 0809 0a0b .T..@”.J%D……

0×0050: 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b …………….

0×0060: 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b …..!”#$%&'()*+

0×0070: 2c2d 2e2f 3031 3233 3435 3637 ,-./01234567

A couple of points in the above decode are worth noting. Normally the beginning of the IP header starts with a Hex value of 4500. This means:

  • 4 = IP version
  • 5 = 5 32-bit words, or (32/8) x 5 = 20 bytes, the size of the IP header
  • 00 = Type Of Service (TOS) field, no values set

The decode above starts with the Hex value “4f00”, which means the IP header is larger than a regular IP header. This is our first clue that at least one IP option is set. How big is the IP header? If we convert “f” in Hex to decimal we get 15. 15 32-bit words converts to 60 bytes, which is the largest possible size for an IP header.

Also, note the series of zeros at the end of the header. When a record route packet is transmitted, the sending system needs to reserve space for all of the IP addresses that must be included. Windows will ask you to identify this value up front. Linux and UNIX simply go for the maximum. It does not cause a problem if reserved space goes unused. The rest of the packet carries a normal Echo-Request payload.

Record route limitations

You may have noticed that the above decode only reserved space for 8 IP addresses. Since most systems on the Internet are about 15 hops away from each other, what happens when 8 is not enough? Remember we said 60 bytes is the maximum size for an IP header. If we remove the rest of the IP header fields, that leaves us enough room to store 9 IP addresses. The transmitting system always stores it's IP address in the option field, since technically it is the first IP address to forward the packet. This leaves us enough room for 8 more IP addresses maximum. If the packet travels over more than 8 hops, the remaining routers will simply ignore the record route option.

Here's an example of what I mean. This output was generated with the Ping utility under Windows. The “-r” switch identifies that the record route option should be set. The numeric value identifies how many hops to record.

C:\test>ping -r 8 -n 1 www.wikipedia.org

Pinging rr.pmtpa.wikimedia.org [208.80.152.2] with 32 bytes of data:

Reply from 208.80.152.2: bytes=32 time=702ms TTL=50

Route: 98.232.117.112 ->

68.88.131.63 ->

68.87.145.246 ->

68.87.145.245 ->

68.85.162.70 ->

68.86.90.65 ->

4.68.185.30 ->

4.69.132.90

Ping statistics for 208.80.152.2:

Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 702ms, Maximum = 702ms, Average = 702ms

The Wikipedia Web site is actually 19 hops away from my current location. Record route is only capable of recording the first 8 hops along the way.

Do I need to be concerned with record route?

Since record route is only capable of recording 8 hops, and most of us are 15 hops away from each other, is it truly a valid security concern? The 15 hop rule is only true a majority of the time. If I attempt to record route to a network that uses the same ISP that I do, I'll probably generate a full network map. Further, if an internal system becomes compromised, record route can easily be leveraged to map the network from the compromised host's location.

So record route is not a common attack vector, but its certainly going to be one of the tools a smart attacker will leverage when possible.

Protecting against record route

Record route is one of those communication parameters that gets ignored by most commercial firewall vendors. By that I mean they include support for record route in their RFC compliant IP stack, but give you little ability to control it via policy enforcement. Open source firewalls tend to do a better job controlling record route, but I'll get into that in part 3 of this series.

If your firewall, HIPS or HIDS gives you access to the signature language, you can usually write a signature to flag all packets with an IP header size larger than 20 bytes. This does not guarantee the packet is using record route, as it could also mean that some other IP option is being used. To be frank however, all of the IP options can be leveraged for evil. Every one of them should be blocked, or at the very least detected, at the perimeter. I'll cover more about IP options in a later post.

Exec Sammanfattning

Record route can produce a network map similar to the traceroute tool, but is limited to only recording 8 hops. While this limits its usefulness to an attacker, its entirely possible to run a record route session close enough to the target network to enumerate valuable data. Most firewalls do not give you the ability to control record route traffic, but you may be able to control/detect it with a signature based device.

Network Mapping Through A Firewall – Part 1

August 24th, 2009

When we create a set of firewall rules, one of our objectives is usually to stop attackers on the Internet from being able to map the internal network sitting behind the firewall. In this write up I'll discuss two different techniques which will let an attacker punch right though most firewall setups, and what additional steps must be taken to prevent them.

The two techniques we will cover are:

  • Eliciting time exceeded in transit errors
  • IP header record route options

Understanding Time exceeded in transit errors

When a router receives a packet traveling from one network to another, it is required to decrement the TTL value by one. So if the packet currently has a TTL of 120, the router would change the value to 119 as it passes the packet along the network. The TTL field is byte 8 within the IP header and is shown in Figure #1.

IP-Header

If a router receives a packet with a TTL value of 1, it is not allowed to decrement the value to 0. Rather, the router generates an ICMP type 11, code 0 packet; referred to as an ICMP time exceeded in transit (TimeX) error. The TimeX error is then sent to the source IP address listed in the packet that had a TTL value of 1. Here's an example TimeX packet. Note that 28 bytes of the original packet that caused the TimeX to be generated is embedded in the payload. The TTL value of this embedded header is 1.

10:14:19.947925 IP (tos 0xc0, ttl 63, id 26344, offset 0, flags [none], proto ICMP (1), length 88) 192.168.202.2 > 192.168.201.10: ICMP time exceeded in-transit, length 68
IP (tos 0×0, ttl 1, id 34730, offset 0, flags [none], proto ICMP (1), length 60) 192.168.201.10 > 192.168.204.10: ICMP echo request, id 18212, seq 1, length 40

One interesting point here is that RFC 792 defines that packets should be dropped when the TTL reaches 0, not 1. I'm unaware of any router or system that actually follows the RFCs. Every device I've seen drops the packet when the TTL is 1. You will however find many incorrect documents that describe this process quoting the RFCs rather than reality.

Network mapping with TimeX

Most network administrators are familiar with the traceroute and LFT tools under Linux and UNIX, and tracert and pathping under Windows. Each tool will identify all of the router hops from a source system to a specified target. This is accomplished by transmitting multiple packets and incrementing the TTL value.

Each of the above mentioned tools use TimeX errors to map all of the routers between two hosts. An example is shown in Figure #2. The tool would start by transmitted packets with an initial TTL value of 1. This causes the first router to return a TimeX error. The tool then looks at the source IP address of the TimeX error, and records this as the first hop along the link.

tracing

Packets with a TTL of 2 are then transmitted. When they pass through the first router, the TTL is decremented to 1. This causes the second router to generate a TimeX error. Again, we simply record the source IP address of the TimeX error as the second hop along the link. When an initial TTL value of 3 is transmitted, the third router generates the TimeX error. This continues until we eventually reach the target system. We've now efficiently mapped the IP addresses of all of the routers between the source and target system.

Here's an example of what the output might look like:

[root@fubar ~]# traceroute -I -q 1 -N 1 10.1.4.10
traceroute to 10.1.4.10 (10.1.4.10), 30 hops max, 60 byte packets
1 10.1.1.1 (10.1.1.1) 0.270 ms
2 10.1.2.1 (10.1.2.1) 0.395 ms
3 10.1.3.1 (10.1.3.1) 0.589 ms
4 10.1.4.10 (10.1.4.10) 0.707 ms

Mapping through a firewall with time exceeded packets

The tools tracert and traceroute are easily defeated by a firewall. This is because tracert transmits Echo-Request packets which most environments block at the border. traceroute will also transmit Echo-Requests if the “-I” switch is used, but by default it targets UDP ports above 33,000. Again, most firewalls block this by default so the tool is easily defeated.

But what if an attacker targets an open port on the firewall? In other words, what if they transmit TCP/80 packets to your Web server, but vary the TTL values in a similar fashion to traceroute? This is exactly how the tool tcptraceroute operates. There is even a version available for Windows . Usually, tools like this can map right though a firewall.

For example, we have a Web server at 192.168.204.10 with a firewall sitting in front of it. The firewall has the standard “only let in TCP/80 to the Web server” policy set. Here is what traceroute reports:

[root@fubar ~]# traceroute -q 1 -N 1 -m 5 10.1.4.10
traceroute to 10.1.4.10 (10.1.4.10), 5 hops max, 60 byte packets
1 10.1.1.1 (10.1.2.2) 0.279 ms
2 10.1.2.1 (10.1.4.1) 0.521 ms
3 *
4 *
5 *

And here is the same networks mapped with tcptraceroute:

[root@fubar ~]# tcptraceroute -n -f 1 -m 5 -q 1 -S 10.1.4.10 80
Selected device eth0, address 10.1.1.10, port 39142 for outgoing packets
Tracing the path to 10.1.4.10 on TCP port 80 (http), 5 hops max
1 10.1.1.1 0.353 ms
2 10.1.2.1 0.450 ms
3 10.1.3.1 0.586 ms
4 10.1.4.10 [open] 0.701 ms

Because traceroute is sending UDP packets, our firewall policy drops them at the border. tcptraceroute however is sending TCP/80 packets to the Web server's IP address. Since this is permitted by the policy, the packets make it through. We now know 10.1.3.1 is acting as a firewall. We also know that it is sitting directly in front of the Web server.

Here's a copy of one of the packets generated by tcptraceroute. To the untrained eye, it looks like a perfectly normal TCP/80 SYN packet, except the TTL value is very low (there are other clues that this packet is not normal, but I'll save that for another post):

18:33:21.531117 IP (tos 0×0, ttl 3, id 41587, offset 0, flags [none], proto TCP (6), length 40) 10.1.1.10.37496 > 10.1.4.10.80: S, cksum 0x7eaa (correct), 1793661553:1793661553(0) win 0

Protection against TimeX mapping

Most stateful inspection based firewalls are horrible at stopping TimeX mapping. In part 3 of this post, I'll get into the proper way to control TimeX if you are running an open source firewall. For now however, I want to limit the advice I give to solutions that will work for every product.

There are two parts to every conversation, the stimulus and the response. When it comes to network mapping we can effectively nullify a scan if we can control either portion of the conversation. In this case here we have:

  • Stimulus = IP packet with an abnormally low TTL value
  • Response = TimeX from routers, port response from target

Since most commercial firewalls do not permit you to filter traffic based on TTL, we can't control the stimulus in this situation. Nor can we control the port response, because it will be identical to a normal conversation. This leaves us with the outbound TimeX packets.

As close as possible to the edge of your perimeter, install a filter preventing ICMP type 11, code 0 (Time Exceeded in transit) packets from being sent to the Internet. For example if you have a border router outside of your firewall, install the filter on the router. Note that if you are running Cisco IOS, the router will partially ignore the filter and still transmit TimeX packets generated by it's own interface. Running the “no ip unreachables” command can prevent this, but this command disables all ICMP error reporting and can cause communication problems . Make sure you understand the full impact of this command before using it.

By filtering outbound TimeX packets, we will prevent the attacker from seeing the IP address of all routers and firewalls between the filter installation point and the target host. The attacker will still be able to enumerate how many hops are on the link; they just will not be able to determine the IP address of each.

Exec Sammanfattning

Tools that perform traceroute type activity through open ports on a firewall are effective at mapping the links along a target network. Further, these tools are usually effective as enumeration of network address translation (NAT) settings. Since most firewalls cannot filter traffic based on TTL, we are usually left with trying to control the transmission of TimeX packets headed out towards the Internet.

Test your network security skills

July 15th, 2009

As mentioned on the About page, I spend a bit of time teaching computer security via SANS as well as directly to clients. When people ask me if they would get anything out of taking my SANS course , I point them to this quick test. If you can score 12/15, you are in good shape. Less than that, and you need to cut the knowledge curve. I'll put the answers in a different post so its less tempting to cheat. ;)

Note: I've messed with the submission dates so the answers do not appear before the questions on the main page.

1) How many different techniques are available to sniff in a switched environment:

  • A) None. Switches block unicast traffic to all ports.
  • B) 2
  • C) 4
  • D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

  • A) Ping run on a Windows system.
  • B) Ping run on a Linux system.
  • C) hping using the “-C 8” option.
  • D) nmap using the “-sP” option.

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

  • A) Quietly drop all inbound SYN/ACK packets that are unsolicited.
  • B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.
  • C) Advertise all portions (even unused) of your IP address space via BGP.
  • D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

  • A) Check Point
  • B) Cisco
  • C) Netscreen
  • D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

  • A) ip = frag and evil bit = enable
  • B) ip[12:2] = ip[16:2]
  • C) ip[2:2]<0x1F4 and ip[6]&32!=0
  • D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

  • A) nmap “stealth” (-sS) scan.
  • B) nmap “idle” (-sI) scan.
  • C) nmap “decoy” (-D) scan.
  • D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

  • A) All data to and from the Web server is at least authenticated.
  • B) All data to and from the Web server is at least encrypted.
  • C) All data to and from the Web server is encrypted and the digital certificate is fully verified.
  • D) All data to and from the Web server is authenticated and encrypted.
  • E) All data to and from the Web server is authenticated, encrypted and the digital certificate is fully verified.

8 ) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

  • A) Problem with the firewall state table time-out being set too low.
  • B) Automatic update checking for new patches.
  • C) Attacker retrieving a toolkit.
  • D) A secure HTTPS session.

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

  • A) TCP transmission from a Windows system.
  • B) SMTP transmission from a Windows system.
  • C) Spam or Phishing attempt from a Windows system.
  • D) SMTP transmission from a Linux or UNIX system.

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

10) Given the following netstat output, which of the answers best describes the situation:

  • A) The system has potentially been compromised.
  • B) The system needs a restart to install updated software.
  • C) The system is configured as a typical Windows desktop.
  • D) The system is configured as a typical Windows server.

Proto Local Address Foreign Address State PID
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2648
TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2292
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1204
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

11) Which of the following systems can potentially be taken over by a remote attacker?

  • A) A Web server exposed to Internet access.
  • B) A desktop with Internet access.
  • C) A firewall or Network Based Intrusion Prevention (NIPS) system.
  • D) All of the above.
  • E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

  • A) Proxy based firewall.
  • B) Stateful inspection based firewall.
  • C) Neither, it is its own unique technology.
  • D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

  • A) Someone is fingerprinting which firewall product we are using.
  • B) A remote site is having connectivity issues connecting to our Web server.
  • C) The state table time-out value on our firewall is set too low.
  • D) This is normal and expected traffic to our servers.

Jun 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN
Jun 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK
Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5
Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53
Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53
Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN
Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

  • A) 192.168.1.22 is performing normal Web browsing.
  • B) 192.168.1.22 is downloading patches.
  • C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.
  • D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”
192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

15) Analyze the following network drawing. How many potential paths does an attacker have available in order to gain access to the internal network?

  • A) 1
  • B) 2
  • C) 3
  • D) 4

network-paths

Answers will be posted tomorrow!

C

1) How many different techniques are available to sniff in a switched environment:

A) None. Switches block unicast traffic to all ports.

B) 2

C) 4

D) 6

2) You receive the ICMP packet shown below from a remote host. Which of the following is the most likely source of the packet?

15:52:50.129178 IP (tos 0×0, ttl 47, id 51389, offset 0, flags [none], proto: ICMP (1), length: 28) 1.2.3.4 > 172.30.2.10: ICMP echo request, id 18492, seq 21446

A) Ping run on a Windows system.

B) Ping run on a Linux system.

C) hping using the “-C 8” option.

D) nmap using the “-sP” option.

3) Which is the best way to discourage attackers from using your address space as part of a SYN flood attack?

A) Quietly drop all inbound SYN/ACK packets that are unsolicited.

B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.

C) Advertise all portions (even unused) of your IP address space via BGP.

D) Report all suspicious inbound traffic to the listed administrative contact of the source IP.

4) Which firewall product is susceptible to loose source route attacks?

A) Check Point

B) Cisco

C) Netscreen

D) None of the above

5) Which Libpcap filter would permit you to see potentially malicious IP fragments which could not have been generated by a normal topology MTU?

A) ip = frag and evil bit = enable

B) ip[12:2] = ip[16:2]

C) ip[2:2]<0x1F4 and ip[6]&32!=0

D) ip[8]<0x2A or ip[0]&0x0F>5

6) Which of the following techniques would permit an attacker to port scan your network without giving any indication of their true source IP address?

A) nmap “stealth” (-sS) scan.

B) nmap “idle” (-sI) scan.

C) nmap “decoy” (-D) scan.

D) Port scans require responses to stimulus so the true source IP cannot be completely hidden.

7) Which of the following best describes what happens when you surf to a Web site, see “HTTPS” in the URL, and the little lock icon on your Web browser is activated?

A) All data to and from the Web server is at least authenticated.

B) All data to and from the Web server is at least encrypted.

C) All data to and from the Web server is encrypted and the digital certificate is fully verified.

D) All data to and from the Web server is authenticated and encrypted.

8) You see the following packet leaving your Web server and headed to an IP address on the Internet. What is the most likely cause?

17:08:08.412172 IP (tos 0×0, ttl 128, id 18210, offset 0, flags [DF], proto: UDP (17), length: 33) 172.30.2.185.32851 > 1.2.3.4.69:

A) Problem with the firewall state table time-out being set too low.

B) Automatic update checking for new patches.

C) Attacker retrieving a toolkit.

D) A secure HTTPS session.

9) You see the following packet entering your network. Which answer gives the most accurate and likely possibility of what is going on?

19:22:17.631407 IP (tos 0×0, ttl 112, id 30435, offset 0, flags [DF], proto: TCP (6), length: 48) 1.2.3.4.4110 > 192.168.1.10.25: S, cksum 0xc25c (correct), 103504428:103504428(0) win 8192 <mss 1460,nop,nop,sackOK>

A) TCP transmission from a Windows system.

B) SMTP transmission from a Windows system.

C) Spam or Phishing attempt from a Windows system.

D) SMTP transmission from a Linux or UNIX system.

10) Given the following netstat output, which of the answers best describes the situation:

Proto Local Address Foreign Address State PID

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2648

TCP 0.0.0.0:80 0.0.0.0:0 LISTENING 2292

TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1204

TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4

A) The system has potentially been compromised.

B) The system needs a restart to install updated software.

C) The system is configured as a typical Windows desktop.

D) The system is configured as a typical Windows server.

11) Which of the following systems can potentially be taken over by a remote attacker?

A) A Web server exposed to Internet access.

B) A desktop with Internet access.

C) A firewall or Network Based Intrusion Prevention (NIPS) system.

D) All of the above.

E) None of the above.

12) A Network Based Intrusion Prevention System (NIPS) is simply a relabeled:

A) Proxy based firewall.

B) Stateful inspection based firewall.

C) Neither, it is its own unique technology.

D) A combination of both.

13) You see the following pattern in your firewall log, which answer best describes what may be going on?

A) Someone is fingerprinting which firewall product we are using.

B) A remote site is having connectivity issues connecting to our Web server.

C) The state table time-out value on our firewall is set too low.

D) This is normal and expected traffic to our servers.

Juni 8 05:40:36 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=2 ID=7831 PROTO=TCP SPT=2023 DPT=80 WINDOW=1400 SYN

Juni 8 05:40:38 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7832 PROTO=TCP SPT=80 DPT=80 WINDOW=1400 SYN

Juni 8 05:40:40 SRC= 1.2.3.4 DST=our_web_server LEN=40 TTL=44 ID=7833 PROTO=TCP SPT=2024 DPT=80 WINDOW=1400 ACK

Jun 8 05:40:45 SRC= 1.2.3.4 DST=our_dns_server LEN=38 TTL=44 ID=7834 PROTO=ICMP TYPE=8 CODE=0 ID=47578 SEQ=5

Jun 8 05:40:50 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7835 PROTO=UDP SPT=2025 DPT=53

Jun 8 05:40:52 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7836 PROTO=UDP SPT=80 DPT=53

Jun 8 05:40:54 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7837 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 SYN

Jun 8 05:40:59 SRC= 1.2.3.4 DST=our_dns_server LEN=58 TTL=44 ID=7838 PROTO=TCP SPT=2026 DPT=53 WINDOW=1400 RST

14) You see the following traffic pattern in your proxy log. What is the most likely cause?

A) 192.168.1.22 is performing normal Web browsing.

B) 192.168.1.22 is downloading patches.

C) Someone on 192.168.1.22 is running an nmap version scan against 1.2.3.4.

D) 192.168.1.22 has been compromised and is calling home.

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:42:55 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:20 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “GET http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

192.168.1.22 [ 9/Jul/2009:10:43:45 +0000] “POST http:// 1.2.3.4/ HTTP/1.1″ “-” “-”

Test your network security skills – Answers

July 15th, 2009

In yesterday's post I gave you a quick network security test to try. Here are the answers:

1) D

There are six different techniques that can be used to sniff in a switched environment. ARP cache poisoning, ARP cache flooding, DHCP spoofing, Port stealing, ICMP redirect attack and ICMP route discovery attack. High end vendor switches can be configured to block all of these except the ICMP redirect attack. That must be addressed on a per host level.

2) D

Ping on both Windows and Linux encapsulate data in the payload of their Echo-Request packets. The above packet has a length of 28, which is just an IP and ICMP header. When hping generates Echo-Request packets, it uses an initial sequence number of 0 and then increments by +256. The above sequence number of 21446 is not evenly divisible by 256. This makes nmap the most likely candidate as it generates empty payload Echo-Requests with random sequence numbers.

3) B

When your address space is spoofed as part of a SYN flood attack, you will see a high number of unsolicited SYN/ACK packets being sent to your network. Quietly dropping this traffic makes your address space highly attractive to attackers spoofing packets because it maximizes the amount of time their attacking SYN packets fill up the remote connection queue. By returning an ICMP error for these packets, your IP address space becomes less desirable as you are quickly removing the attacking SYN packets from the remote connection queue.

4) C

All three products prevent source route packets (both loose and strict) from being bounced off of the firewall itself. Netscreen however will pass loose source route packets targeting a host on the other side. So to be safe from redirection attacks in a Netscreen environment, you must ensure source routing is disabled on all exposed hosts.

5) C

The first portion of the filter, “ip[2:2]<0x1F4” checks to see if the packet is less than 500 bytes in size. The second portion of the filter, “ip[6]&32!=0” checks to see if the more fragment flag is turned on. So the complete filter will catch non-last fragments smaller than 500 bytes. All non-last fragments will express the smallest topology Maximum Transmission Unit (MTU) they pass through. The smallest LAN or WAN MTU used in the Internet is 512 bytes. So fragments smaller than 500 bytes are being crafted, most likely to obfuscate an attack pattern and avoid detection.

6) B

An idle scan leverages the predictable IP ID's being used by a secondary system in order to make it appear that all the scanning packets are originating from that host. Since all the scan packets use the spoofed IP address of this secondary host, the attacker's true IP address is not revealed to the host being targeted. nmap's stealth and decoy options still transmit packets using the attacker's true source IP address.

7) A

The protocol HTTPS and the little lock icon being activated on a Web browser simply means that the SSL or TLS protocol is being used to secure the data stream. Both specifications require that every packet be authenticated. Both specifications make encryption an optional feature. So its possible to use either SSL or TLS to communicate without encrypting any of the data passing between the systems. The only way to prevent this is to disable these options in your browser. Further, digital certificates are typically checked against a locally stored public key, but the browser does not check to see if the certificate has been revoked. This can also be changed through the browser's options.

8 ) C

The traffic in question is an outbound attempt to connect to a TFTP server. Since Web servers do not use TFTP, this is not a problem with the firewall state table. Also, vendors do not make fixes available via TFTP, so this is not a check for new patches. The most likely candidate is that an attacker has compromised the system and is attempting to move their toolkit onto the box.

9) C

The TTL value in this packet is 112. Linux and UNIX use a starting TTL of 64, so this packet most likely did not come from one of these systems. Windows uses 128 as a starting TTL so this could likely be a Windows host located 16 hops away. This is a TCP packet headed to port 25, so it is most likely the start of an SMTP session. The system is using a very small window size (8192 bytes) and does not support the TCP windowing option (this would be listed in the output as “wscale” followed by a numeric value), which indicates that it is an older Windows desktop system. Since most organizations do not rely on old Windows desktops as their SMTP servers, this is most likely a compromised host transmitting spam or phishing attacks. A firewall such as pf or Netfilter would be able to filter these packets by passively identifying the source operating system.

10) A

Within a Linux or UNIX environment, ports can only be opened exclusively. This means that only one application can hold open a TCP or UDP listening port at any given time. While most Windows applications open ports exclusively as well, Windows permits applications to listen with non-exclusive access. The result is that one application will service most inbound sessions but if that port is busied out, connections are then passed to the second application. This can permit an attacker to open a back door on a system that is undetectable during port scans of the system.

11) D

The classic view is that only systems with open listening ports exposed to Internet access are susceptible to attack. The point of risk is in fact permitting unknown entities to interact with code running on the local system. All of the indicated systems permit some level of code interaction with untrusted IPs on the Internet. With this in mind, all can potentially be remotely compromised.

12) B

Network based intrusion prevention systems leverage stateful inspection technology to analyze both header and payload information, same as a stateful inspection based firewall. Sometimes NIPS provides more signatures to look for hostile patterns, but most high-end stateful inspection firewalls provide multiple signatures as well, but typically at a lower cost.

13) A

There are many suspicious patterns in these log entries. To start, the Time To Live (TTL) in the first packet is 2. Given modern OSs use a starting TTL of 64 or higher, and most systems are about 15 hops away from each other on the Internet, we should never see a TTL this low. Most likely this is someone running a TCPTraceroute variant to map our network through the firewall.

Look at the length of the first three TCP packets; its 40 bytes. This means no TCP options have been set. All modern day operating systems support some number of TCP options, so these looks like crafted packets. Also, the TTL of 44 is indicative of a Linux or UNIX variant, but the increment of the IP identification (ID) looks like a Windows system. The Echo Request recorded in log entry four is also suspicious, as a Linux/UNIX variant would use an initial Echo-Request sequence number of 0 or 1, not 5.

So what's going on? Look at the source port in the first two packets. Based on the response (if any) from these probes a smart attacker can tell what technology the firewall is based on (proxy, static filtering or stateful filtering). If you know which firewall products leverage each technology, its now just a matter of further reducing the possibilities.

The second packet would identify if the source port is being restricted, which is done by some firewall products but not others. The third packet would identify if an ACK can create a new state table entry, which again is done by some products but not others. The rest of the pattern is similar. Based on what replies come back from each of these probe packets a smart attacker may be able to identify what vendor firewall product we are running.

14) D

The log entries claim this is normal HTTP 1.1 traffic. The issue is that normal HTTP traffic would include additional fields of information such as the full URI visited (we just see the target IP address 1.2.3.4) and the host identification field (what OS is being used, name and version of the browser, etc.). Both of these pieces of information are missing, which makes the log entries very suspicious. The GET and POST nature of the traffic implies that an exchange of information is taking place. While we would want to confirm via additional investigation work, it is very likely our internal system (192.168.1.22) has been compromised and is calling home for instructions.

15) C

There are three potential paths into the internal network; through the firewall, through the VPN gateway and through the switch. The firewall may be attacked directly or via data replies from a malicious site. The VPN gateway has exposed ports with no trusted system to monitor them, so it is susceptible to direct attack. Finally, the switch is a potential path as it is VLANing across multiple security zones. Features like auto trunk negotiation may be leveraged to gain access to the internal network from the DMZ, thus bypassing the firewall's filtering capability between these two security zones.

So how did you do? The benchmark is being able to answer (meaning you knew the answer, not just a lucky guess ;) ) 12/15 questions. If you scored below that point its time to hone the old skills.