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 avkodnings fil 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 något 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).

Nypen 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 den är posten från staten bordet. När den webbservern fortsatte att kommunicera skulle emellertid 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. I själva verket om vi sätter upp dem med en förnekar regel i stället för en droppe regel, skulle de döda session på webbservern vilket åtgärdar problemet skapas av nypen.

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

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

Givetvis har vi ökad funktionalitet på bekostnad av säkerheten. Det är tyvärr den typiska avvägning.

Hoppas du 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 med att använda vit lista för att granska brandväggsloggar. Jag diskuterade hur denna process både kan förenkla och påskynda registreringsprocessen loggen genom att automatisera mycket av det upp framför arbetet. I detta inlägg kommer vi att titta på några verkliga exempel, samt 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 binärer 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. Bara härma den process som jag har definierat här med Ditt lämpliga kommandon.

Grep är ett mönster-matchningsverktyg. Det gör att du kan söka en eller flera filer som letar efter ett specifikt mönster. När mönstret hittas 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-adressen "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" switch. Denna omkopplare talar grep för att matcha alla rader som inte innehåller det angivna mönstret. Så till exempel:

grep -v 192.168.1.10 firewall.log

skulle bara skriva ut rader som inte innehåller den angivna IP-adressen.

Med grep, är en period faktiskt ett jokertecken. Så medan 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 att läsa:

Matchen på: 192 <enskilt tecken> 168 <enskilt tecken> 1 <enskilt tecken> 10

Om vi ​​vill grep matcha perioder som perioder måste vi preced 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 vill vi passa på flera mönster som en följd. Till exempel vad händer om vi bara är 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.

Logiska OCH talet och OR: s

Ibland behöver 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 vill passa 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 rad. 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 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 ser jag inkluderat 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 OR. 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 halvan behöver lite förklaring. Vi måste tala om 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 OR. Notera röret måste också föregås av ett omvänt snedstreck.

Sorterings stockar med grep

OK, så vi har grunderna, nu ska vi börja tillämpa dem på 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 krävas. Om loggen använder ett eget format, säljaren levererar vanligtvis ett verktyg för att göra konverteringen. Personligen 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 riktighet, vi vill placera kommandona i ett skalskript 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 ditt Windows-versionen av grep kanske vill se citationstecken istället.

Nästa steg är att granska loggfilen efter trafikmönster som du känner igen. Låt oss ta en 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 bli 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 ut utdata till skärmen, vi omdirigeras till en fil med ett beskrivande namn. På så sätt loggposter finns tillgängliga för senare granskning.

Om vår webbserver endast erbjuda HTTP bör vi bara se trafiken på väg till port TCP / 80. Varje annan port ansluter försök kan anses misstänkt trafik, och kan vara en del av en skanning eller sond. Med port TCP / 80 trafik i egen fil, 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 redovisa all trafik på väg till vår webbserver. Nu måste vi få allt detta sparade trafiken ur vägen så 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 tillfällig fil.

grep -v 'dst 192 \ 0,168 \ 0,1 \ 0,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. Denna 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 \ 0,168 \ 0,1 \ 0,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 förväntar sig att se servern endast kommunicera på TCP / 25. Alla andra försök hamn kan indikera 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

Stänga 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 in vår manus. Först döpa 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 förmodligen att vara den första filen som du kommer att vilja att granska, eftersom det kommer att innehålla alla de oväntade mönster. Nu när alla normala trafikflödet är ur vägen, skulle 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, ska jag räkna med att se nästa temp fil krymper med 1,5 MB också. Om inte, är 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 skapade "temp12.txt".

När ditt manus är 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, har helt enkelt den sista raden i ditt manus radera temporära filer. På Windows syntaxen skulle vara:

del / q temp * txt

och på UNIX eller Linux kommandot skulle vara:

rm-f temp * txt

Automatiserad process

När du har en fungerande manus, är det nu dags att automatisera processen. Om du kör Linux eller UNIX, att helt enkelt ställa in skriptet körs 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 som jag tycker om att leta efter fel paket. Jag kommer oftast göra det alldeles i början av mitt manus. Dessutom är det inte ovanligt för system att ringa hem, för att kontrollera för plåster. 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 \ .20 \ .30 \. [1-8]' firewall.log >> server_patching.txt

De första kommandot grabs all trafik på väg 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 IPs detta sätt än en enda ägs systemet på deras nät kunde styra robotar på ditt nätverk och du skulle aldrig veta det.

Denna syntax är också praktiskt när du 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 Malware 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äll-IP (1.2.3.4) som vi vet är fientlig. Vi vill kontrollera filen för att se om det finns några andra IP-adresser som vi behöver bli berörda. Medan vi kunde hålla bläddra 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 det menar jag om du hittar en 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 öppen 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 leta upp det varje gång vi ser det men om vårt skript kan identifiera det för oss? Nu när vi vet 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 vanligtvis håller sonde .

Exec Sammanfattning

Vad gör brandväggslogg recension så tidskrävande är att du måste gå igenom alla de normala trafikmönster för att hitta de loggposter som identifierar en riktig säkerhetsproblem. Genom vita notering 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 att sortera stockarna, logga översyn kan 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 tidskrävande delarna av att upprätthålla en omkrets ser över 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 loggböcker. I denna serie ska jag visa dig hur man påskynda registreringsprocessen brandväggslogg så att du kan fylla i det snabbare än den där morgonen kopp kaffe.

Varför brandväggslogg är viktigt

Jag tog en gång en del i en paneldiskussion där en av mina kolleger SANS instruktörer meddelade till publiken "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 finner att 7/10 gånger jag kan identifiera minst ett äventyras systemet att de inte visste om. I varje fall har det varit kundens egna brandväggsloggar som pekade mig till det infekterade systemet.

I gamla dagar brandväggslogg recension handlade om att kontrollera dina inkommande drop poster för att leta efter portsökningar. I dag ligger fokus på utgående trafik. Specifikt bör du kontrollera 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 vanligtvis din bästa chans att identifiera när ett system har blivit komprometterad.

Vad behöver vara inloggad?

Tappade trafiken behöver inte vara inloggad förutsatt att du inte är blind för DoS översvämningsattacker. 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 ni 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 alla tillåten trafik, oavsett riktning (avstigning samt inträngande). På ett minimum vill vi se rubrikinformation för det första paketet i en session. Något bortom som kan betraktas som en bonus.

Vissa kernel level 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 kontrollera nätet för berätta tale tecken på skadlig kod som kallar hem. Malware skapar vanligtvis utgående sessioner antingen att överföra en verktygslåda eller checka in för marschorder. Brandväggen är på ett optimalt läge 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åra 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 att de flesta brandväggsadministratörer logga inte dessa utgående sessioner eftersom de är ansvariga för den största delen av omkretsen trafiken. Så återigen, om vi ska tillåta trafiken att passera vår omkrets, måste vi försäkra att vi loggar det.

Logga översyn som en process

Misstaget jag ser de flesta administratörer gör är att de gö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 det här sättet eftersom det kommer att blandas in med normal 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 det innehåller en blandning av normala liksom suspekta trafikmönster. I stället för att omedelbart efter de misstänkta mönster, låt oss först få de normala mönster ur vägen. Till exempel HTTP leds till vår webbserver från Internet är en förväntad 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 en annan förväntade mönster. Återigen, om vi kan ta bort dessa poster samt brandväggsloggfilen blir ännu mindre.

firewall-log-review-process

Nu är 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 mindre slut loggfil. Vad är kvar är bara de oväntade trafikmönster som kräver översyn tiden från en brandvägg administratör. Jag har sett platser som normalt genererar 250-300 MB värde av stockar per dag 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 blir en början. Vad jag gör är att skapa en batch-fil, shell script, eller en uppsättning databasfrågor att automatisera processen att analysera brandväggsloggen. Vi kan då köra den här processen som ett cron-jobb eller schemalagd aktivitet. Det innebär att allt det hårda arbetet (bryta upp huvud loggfil i mindre filer) kan göras off timmar. När du kliver in genom dörren på morgonen, kommer loggfilen redan segregerad. Du kan sedan omedelbart fokusera på de misstänkta mönster.

Användbara tips

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

  • Det finns ingen "enda rätta vägen" 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 tvångsmässigt sätta en loggpost i varje sorteringsfilen. Denna process handlar om att skapa lättare att upptäcka mönster. Till exempel ett TCP återställning i en HTTP ström kan gå in både en "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älls, ICMP typ 3: s och 11 s). De visar alltid något är pank eller någon gjorde något oväntat.
  • En smart angripare kommer aldrig att göra din "topp 5 kommunikatörer" lista. Jag har sett infekterade system gör så få som fyra utgående anslutningar på en dag.
  • Anteckna den genomsnittliga storleken på alla dina sorteringsfiler. En kraftig stegring i trafiken kan motivera ytterligare undersökning.
  • Det kan hjälpa att tolka samma mönster i två olika filer. Exempelvis skapar jag en "utgående HTTP" filen och extrahera all trafik genererar under icke-kontorstid. Detta gör det mycket lättare att hitta infekterade system ringer hem.
  • Vitlista vet lappställen. Exempelvis system kan ringa hem hela natten till Microsoft och Adobe för att leta efter uppdaterade patchar. Om du kan tolka dessa poster, kommer du att sluta med betydligt mindre brus i din slutliga filen.
  • Vissa webbplatser vara till hjälp att tolka ut användarna kontrollera 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, någonsin trafikmönstret du kommer att beskrivas i företagets nätverk användningspolicy. Om dess inte, då ytterligare utredning erfordras.
  • Räkna med att justera ditt manus med tiden, eftersom näten är en utvecklande enhet.

Exec Sammanfattning

Vita notering förväntade trafikmönster i din brandvägg loggen kan bidra till att påskynda registreringsprocessen loggen. 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 för att skapa ditt eget skript med hjälp av ett antal olika brandväggsprodukter.

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

31 aug 2009

I mitt förra inlägg diskuterade jag en inaktiv skanner och hur den kan tillåta en angripare att dölja sin IP-adress under en port scan. I denna delbetalning ska vi titta på några spår, samt diskutera hur man identifierar när en inaktiv skanner 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 [none], 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å ett Linux eller Unix-system. Eftersom vi är råa skriva paketet direkt till tråden detta värde styrts av hping. 64 bara råkar vara program standard, men vi kunde ändra värdet till något vi vill med "-t" switch.

Målet adressen skrivs ut som "192.168.100.2.0", vilket innebär 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 inte egentligen försöker ansluta till Windows-systemet. Vi behöver bara den för att skicka 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 refereras till som ett nollpaket och skulle aldrig inträffa under normala IP-kommunikation. Därför kan NIDS, NIPS och brandväggar flaggar den. Vi skapade en null-paket eftersom vi inte tala hping ska skickas någon av TCP flaggorna. Till exempel lägga till "S" switch skulle ha vänt på SYN flaggan, "-A" skulle slå på bekräftelse flaggan, och så vidare.

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

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 [none], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (korrekt), 0: 0 (0) ack 918.250.228 vinna 0



07: 22: 16,367453 IP (tos 0 × 0, ttl 128, id 109, offset 0, flaggor [none], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2204: R, cksum 0xfa78 (korrekt), 0: 0 (0) ack 2127488152 vinna 0



07: 22: 17,367763 IP (tos 0 × 0, ttl 128, id 110, offset 0, flaggor [none], proto TCP (6), längd 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (korrekt), 0: 0 (0) ack 1611256374 vinna 0

Det viktiga värdet 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 obruten sekvens i IP-ID, vi vet att Windows-systemet inte sänder några andra paket utom de som ingår i denna session.

Sondering en stängd port

Kom ihåg att som en del av vår scan, kommer vi att skoja med käll 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 [none], 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 ställs in på 64 Så det här är ett paket som vi genereras från 192.168.100.1 med hjälp av en andra instans av hping.

Notera också att vi har riktat TCP-port 79 och har aktiverat SYN flaggan. Här är svaret vi fick från den avlägsna målet:

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), 0: 0 (0) ack 1704542341 vinna 0

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

Så hur kommer Windows-systemet reagera? Du kanske kommer ihåg från mitt förra inlägg att RFC: er anger du ska 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. Det innebär att vi skulle se någon förändring i IP-ID steg.

Sondering 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 läge. Här är sonden paketet. Observera att det är ganska lik den sista, förutom nu vi kontrollerar TCP-port 80.

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

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

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), 262.246.932: 262.246.932 (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, du kan ansluta till TCP-port 80". Detta är ett problem för Windows-systemet eftersom det har något samband post som säger att det faktiskt försökt att 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 den 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 [none], proto TCP (6), längd 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (korrekt), 947.341.261: 947.341.261 (0) vinna 0

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

Identifiera en inaktiv skanner

Så en inaktiv skanner 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 i 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 skanner utfördes snarare än en rakt framåt port scan så vi vet om det är värt att undersöka källan IP-adressen? 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 kontra en vanlig port scanner. När någon kör en vanlig port scanner, kommer skannern vanligen drabbade öppna portar bara en gång utan brandvägg hamnar flera gånger. Detta beror på att de firewalled portar retur inget svar. Skannern kommer att göra flera försök för att se paketen är inte bara att gå vilse. Eftersom den öppna porten faktiskt kommer att reagera, är endast en sond paket som erfordras.

När en inaktiv skanner utförs, är det tvärtom. Om ett brandväggs port sonderas blir det ingen IP-ID stegändring i Windows-systemet. Så bara en kontroll krävs för att bekräfta detta inte är ett aktivt lyssnande port. När en öppen port sonderas dock, vi upptäcker en förändring i system IP-ID steg. Medan vi tror att detta beror på att vi hitta en öppen port, kan det lika gärna bero på att Windows-systemet skickade en sändning. Så vi kommer att vilja utföra flera sonder mot den öppna porten för att se till Windows IP ID data förblir konstant.

So:

  • Probe brandvägg hamnar oftare än öppna portar = normal port scanner
  • Probe öppna portar oftare att brandvägg hamnar = tomgång scan

Timing

Normala portskanningar vara extremt snabb. Det är inte ovanligt att se hundratals prob paket per sekund. Med en inaktiv skanner dock måste vi ta det lite långsammare. Detta beror på att vi måste kontrollera IP-ID för falsk adress, skickar sonden paket, medger tillräckligt med tid för sonden att framkalla en reaktion, ge falska systemet tillräckligt med tid att svara med en återställning om det behövs (alltså med hjälp av en IP-ID ), och kontrollera sedan IP-ID igen för att se om ökningen har ändrats.

Försök att utföra alla dessa steg för snabbt, och du kommer att betala priset i noggrannhet. Exempelvis nmap stöder tomgång skannar med "Si" switch. Standard extremt snabb skanning hastighet fungerar bra om alla system är på samma kopplade nätet. Om värdarna är 15 humle från varandra på Internet har dock min erfarenhet varit noggrannheten rating sjunker betydligt om du inte sakta ner skanningshastighet.

So:

  • Hundratals paket per sekund = normal port scanner
  • Ett dussin eller mindre paket per sekund = möjlig tomgång scan, bara kan vara en långsam skanning

TTL-fältet

Låt oss titta igen på falska sondpaketet samt den legitima återställnings svar skickas av Windows-system:

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



10: 29: 46,953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flaggor [none], proto TCP (6), längd 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (korrekt), 947.341.261: 947.341.261 (0) vinna 0

Du kanske har märkt TTLS är långt bort från varandra. Om båda av dessa paket faktiskt hade sitt ursprung från 192.168.200.2 då skulle de båda har samma start TTL-värdet. Det faktum att de är annorlunda berättar att en av dem är falska.

Om du övervakar omkretsen på målsystemet och märker att SYN och återställnings paket har olika TTL-värden, det är en aning om att du kan ha drabbats av en inaktiv skanning. Nu är det som tidigare nämnts fullt möjligt att ställa in TTL vad allt vi önskar i vårt bedrägeri paket. Så en smart angripare är helt enkelt kommer att ställa in sin start TTL till 128 för att bättre efterlikna Windows-systemet. Om de gör det, är ditt enda hopp att angriparen och Windows-system är ett annat antal hopp bort. Med andra ord, om du konsekvent se SYN paket med en TTL på 115, men återställer har alltid en TTL på 113, du är mest sannolikt att titta på en inaktiv skanner.

Om TTL gör match, kan vi inte helt utesluta en inaktiv skanner. Angriparen kan bara vara så bra.

So:

  • TTL för Syns och RSTS är konsekvent men matchar inte = tomgångs scan
  • TTLS av Syns och RSTS match = normal port scanner eller smart tomgång scanner

IP-ID-värde

Det bästa sättet att märka en inaktiv skanner är utnyttja samma sak angriparen använder, nämligen IP ID-värde. Ta en titt på de två senaste avkodade paket. Observera att IP-ID i den första är 15249, men i det andra är det 176 Om du ser en inaktiv skanner, kommer du att märka resten paketen konsekvent har en IP-ID +2 (samma sak angriparen ser), men de SYN paket kommer att ha några helt orelaterade värde. IP-ID ökningen i SYN paket kan vara förutsägbar eller det kan vara slumpmässigt. Ärligt talat spelar det ingen roll. Vad som däremot räknas är att du kan upptäcka något mönster i IP-ID för resten paket som inte gör det jive med IP-ID i SYN paket.

So:

  • IP ID för SYN och RST paket visas relaterade = normal port scanner
  • IP ID ökning på RST matchar inte Syns = tomgångs scan

Exec Sammanfattning

Förhoppningsvis har du nu en bättre förståelse för vad som händer på tråden när en angripare utför en inaktiv skanner. Om vi ​​är riktade med en inaktiv skanning, kan vi inte fastställa den verkliga källan IP-adressen för angriparen. Det bästa vi kan hoppas uppnå är att bestämma att sökningen är en inaktiv skanner kontra en vanlig port scan. Det finns ett antal berätta tale ledtrådar i paket, det bästa som är IP ID-värde.

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

28 augusti 2009

Jag älskar avslöja myter, är en av mina favoriter "en port scanner måste avslöja sin verkliga källan IP-adress". I den här serien jag ska visa dig hur du utför en port scan samtidigt dölja din IP-källadress från värden som skannas. Jag ska också tala om för dig hur du kan upptäcka tekniken när den används mot dig.

Nmap s decoy läge

Ett alternativ till den teknik som jag kommer att beskriva är nmap s lockbete läge. Med lockbete läge du identifiera ett antal falska käll IP-adresser. Från målet värd, ser det ut som alla de falska IP-adresser, samt den verkliga källan IP-adress, är alla utför en port scan samtidigt. Konceptet är administratören under attack kommer att ha någon möjlighet att veta vilken IP-adress är i själva verket den verkliga IP utför genomsökningen.

Denna teknik verkligen inte maskera den verkliga källan, som källa IP-adress är en av de IP-adresser som utför avsökningen. Om du vet vad du ska leta efter, kan du enkelt räkna ut vilken källa IP faktiskt skannar dig. Så medan denna teknik kommer att fungera, är det inte helt effektiv på att gömma källans IP-adress.

Vad är en inaktiv skanner?

När vi utför en inaktiv skanner, vi faktiskt inte direkt upptäcka öppna portar. Snarare vi upptäcker effekten en öppen port skulle ha på en tredje part-system. Tekniken liknar hur många virus upptäcks i den mänskliga kroppen. I stället för att upptäcka själva viruset, vi ser för antikroppar som får produceras när viruset finns i systemet. En tomgångsökningen upptäcker öppna portar på ungefär samma sätt.

Innan vi kan gräva för djupt i en inaktiv skanner, måste vi titta på några av de invecklade IP.

Förutsägbara header värden

Medan RFC är utformade för att vara specifika nog att olika operativsystem fortfarande kommer att kunna kommunicera via IP, de ändå lämnar ganska lite utrymme för tolkningar. Till exempel RFC anger att den maximala Time To Live (TTL) värde som kan användas är 255 De ger dock inte specificera vad initial TTL-värdet måste användas; så olika operativsystem använder olika utgångs TTL. De RFC beskriver hur Ping borde fungera, men inte anger vad som ska vara i nyttolast Echo-Request-paket. Återigen, olika leverantörer använder olika värden. Dessa nyanser kan tillåta dig att identifiera operativsystemet källbaserade variationer i paketets innehåll. Tekniken kallas passiv fingeravtryck .

Fältet IP identifierare (IP-ID) i IP-huvudet (byte 4 och 5) är en liknande situation. RFC 791 anger att antalet måste vara unikt på en per värd, per session basis. Till exempel låt oss säga att jag ansluter till en fjärr SSH-server. Varje IP-ID i den sessionen måste vara unikt. Om jag stänger sessionen och sedan koppla tillbaka senare, det är RFC-kompatibel, om en eller flera IP ID-värden får användas igen. De behöver inte vara, men om det händer att det är inte ett problem.

Så RFC säger IP-ID måste vara unikt, men det spelar egentligen binda hur man ska generera värde. Detta har lett till olika operativsystem distribuera olika metoder. Till exempel Windows startas vid en IP-ID-värde av 1 och helt enkelt inkrementerar värdet med ett för varje paket som lämnar systemet. När det maximala värdet av 65.535 har nåtts, börjar det tillbaka över åtmin 1. BSD sätter ett slumpvärde till IP-ID-fältet för varje paket som lämnar systemet. Linux är slumpmässigt för TCP-paket (förutom första svaren som alltid noll), en inkrementell för ICMP, och tidsbaserade för UDP. Puh!

Det som är intressant för våra syften är Windows. Det faktum att varje paket som lämnar systemet får en en IP-ID gör värdet extremt förutsägbar. Ta till exempel följande resultat:

[Root @ fubar ~] # hping -r 192.168.100.2

HPING 192.168.100.2 (eth0 192.168.100.2): flaggor är inställda, 40 headers + 0 databyte

LEN = 46 ip = 192.168.100.2 ttl = 128 id = 108 sport = 0 flaggor = RA seq = 0 vinna = 0 RTT = 0,4 ms

len = 46 ip = 192.168.100.2 ttl = 128 id = + 1 sport = 0 flags = RA seq = 1 vinst = 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 artiklar = 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 är ett paket crafting verktyg som låter dig skapa dina egna IP-paket. I ovanstående utgångs vi använder "-r" switch att ha hping övervaka IP-ID ökningen av ett fjärrsystem. Vi vet att det är ett Windows-system, eftersom Windows använder alltid en start TTL av 128 Titta nu på de "id =" värden. På första raden av produktionen hping alltid skriver ut det absoluta IP ID-värde som används av systemet. I det här fallet värdet är 108 Varje påföljande raden skriver sedan ut deltat förändring från det tidigare paketet. Så i den andra raden den faktiska IP-ID var 109, vilket är "+1" från det tidigare värdet av 108 Nästa paket hade en IP-ID på 110, vilket är "+1" från den tidigare IP ID-värdet 109.

Titta noga på den fjärde raden av produktionen. Obs delta förändringen var "+2". Eftersom Windows använder sekventiella IP-ID, berättar detta för oss ett paket som vi inte får se just lämnat Windows-system. Vi vet inte vart det var på väg, men det är OK. Det viktiga är att vi kan identifiera när Windows-systemet sänder och hur många paket den sänder ut. Till exempel hade den linjen läst "5", skulle vi veta att Windows-systemet sänds fyra andra paket sedan att svara på vår sista sond.

Upptäcka öppna portar

Så hur kan vi utnyttja det förutsägbara IP ID värde på Windows ont? En möjlighet är att stänga av Windows-system i en öppen port givare. Här är hur vi gör det:

  1. Övervaka den aktuella IP-ID som används av ett Windows-system. Vi bör kontrollera värdet med jämna mellanrum under en relativt kort tidsperiod. Säg en gång sekund.
  2. Hitta ett målsystem vi vill skanna port.
  3. Medan skoja med käll IP-adressen för Windows-systemet, skickar ett SYN paket till TCP-port som vi vill mäta på målet.

Målet Systemet skickar tillbaka till Windows-systemet ett svarspaket. Detta kommer antingen att vara:

De RFC anger du aldrig svarar på fel paket, oavsett om man anser dem vara legitima eller inte. Så när rutan Windows emot TCP reset felpaketet från målet värd, tyst ignorerar den och kastar paketet.

Saker och ting blir lite mer intressant när en SYN / ACK mottas dock. Från Windows-systemets perspektiv är det bara hänga minding egen verksamhet när någon okänd systemet skickar ett SYN / ACK paket (kom ihåg att vi falska Windows systemets IP-adress i sond paket). En SYN / ACK betyder i praktiken "Visst, du kan ansluta till mig på den TCP-port, inga problem". Naturligtvis eftersom Windows-systemet inte faktiskt skicka SYN paket, den har ingen aning om vad den avlägsna målet talar om.

Med detta i åtanke Windows-systemet skickar ett TCP reset felpaketet tillbaka till målet värd. När återställnings paket sänds, är nästa tillgängliga IP-ID används i IP-huvudet. Detta saknade IP-ID kan upptäckas vi fortfarande övervaka IP-ID ökningen gång per sekund. Så för omdömet:

  • Stängd port på target = Inga paket som lämnar Windows-system
  • Öppna port på target = Windows skickar ett TCP återställning med en IP-ID

Så genom att övervaka IP-ID ökningen, kan vi identifiera när en öppen port upptäcks eftersom endast prober för att öppna portarna kommer att orsaka IP ID ökningen förändras.

Caveats

Du kan inte bara använda alla Windows-system för denna attack. Lådan måste uppfylla vissa kriterier:

  • Relativt ganska systemet genererar lite trafik (som ett hem-system)
  • Ingen stateful filtrering av TCP-trafik

Givetvis går till någon kabel eller DSL-nät vid 02:00 lokal tid och du kan hitta hundratusentals system som uppfyller dessa kriterier. Kom ihåg att Windows-system älskar att godtyckligt sänds, så du kanske vill utföra flera kontroll av varje öppen port bara för att se till att IP-ID ökningen förändringen var i själva verket beror på en öppen port som sonderas.

Exec Sammanfattning

En tomgångs skanning kan du söka öppna portar på en fjärr mål, samtidigt som lurar målet att tro att någon tredje part systemet fungerar genomsökningen. Öppna portar upptäcks genom övervakning efter oegentligheter i IP-ID ökningen av rutan Windows.

I nästa del kommer vi faktiskt se vad dessa paket ser ut på tråden samt diskutera hur man upptäcker en ledig attack när den används mot dig.

Nätverksmappning via en brandvägg - Del 3

26 augusti 2009

I mina två senaste inlägg talade jag om två olika metoder som kan användas för att kartlägga ett nätverk via en brandvägg. Första belånade ICMP tid överskrids i transit fel, medan andra använde IP rekordruttalternativ. I båda inlägg gav jag också möjliga lösningar för att hindra en angripare från att använda dessa tekniker mot ditt nätverk.

I båda fallen dock stödda funktioner som finns i kommersiell kvalitet brandväggar begränsade våra säkerhetsalternativ. I denna tredje och sista delen av serien, kommer jag att täcka hur man korrekt förhindra dessa attacker om du använder en öppen källkod brandvägg. Jag kommer särskilt att använda Netfilter , men många av de tekniker som är tillämpliga på pf samt.

Vad är Netfilter?

Netfilter är Stateful Inspection brandvägg som ingår i varje modern distribution av Linux. Om du har en kopia av Linux, har du också en kopia av Netfilter. Netfilter är ibland kallas iptables, men detta beror på att iptables är namnet på den binära du använder för att manipulera Netfilter rulebase. Netfilter är en extremt kapabel brandvägg med för många funktioner för att täcka i det här inlägget. Jag rekommenderar att du kolla in några av de vanliga frågor och handledning som de gör ett utmärkt jobb med att beskriva många av de funktioner.

Styra tcptraceroute

I det första inlägget beskrev jag hur verktyg som tcptraceroute kunde slå igenom en regel öppen brandvägg för att kartlägga nätverket som sitter bakom den. Med kommersiella brandväggar, vi var begränsat till att reglera flödet av utgående ICMP tid överskrids i transit fel.

Med Netfilter, har vi möjlighet att styra trafik baserat på TTL-värdet. Vi kan leta efter ett specifikt värde eller ett värde över eller under ett visst tröskelvärde. De växlar som stöds är:

  • -m ttl -ttl-eq = Matcha paket med TTL av ett angivet värde
  • -m ttl -ttl-gt = Math paket med en TTL högre än ett angivet värde
  • -m ttl -ttl-lt = Matcha paket med TTL under ett visst värde

Här är en möjlig Netfilter regel vi kan använda:

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

Denna regel skulle bearbetas innan några tillståndsregler i rulebase. Regeln kontrollerar helt enkelt TTL-värdet för att se om det är mindre än 5 Om så är paketet tappas. Eftersom den lägsta TTL används av en modern OS är 64, och de flesta system är ungefär 15 humle från varandra på Internet, får vi aldrig oavsiktligt filtrera bort legitim trafik.

Här är tcptraceroute kör även en vanlig brandvägg:

[Root @ fubar ~] # tcptraceroute -n -f 1 -m 5 -q 1 S 10.1.4.10 80
Valda enheten eth0, adress 10.1.1.10, port 39142 för utgående paket
Spåra sökvägen till 10.1.4.10 på TCP-port 80 (http), max 5 humle
1 10.1.2.2 0,353 ms
2 10.1.4.1 0,450 ms
3 10.1.4.10 [öppna] 0,586 ms

Och här är vad tcptraceroute ser när vi genomföra ovanstående Netfilter regel:

[Root @ fubar ~] # tcptraceroute -n -f 1 -q 1 S 10.1.4.10 80
Valda enheten eth0, adress 10.1.1.10, port 54531 för utgående paket
Spåra sökvägen till 10.1.4.10 på TCP-port 80 (http), max 30 hopp
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 [öppna] 1.007 ms

Observera att när vi börjar filtrera på TTL-värdet, utseendet på våra omkrets förändringar. Utan regeln en angripare skulle kunna räkna upp eller IP adresseringsschema. Även om vi filtrerade utgående Timex paket, skulle de ändå vet den rätta hoppantalet. Den Netfilter regeln gör det mycket svårt att exakt identifiera vårt nätverk layout.

Lägga på något bedrägeri

En av de mer kraftfulla funktionerna i Netfilter är möjligheten att skräddarsy avvisa meddelanden. Medan de flesta brandväggar avvisa paket genom att returnera en administrativt förbjudet felmeddelande, låter Netfilter du välja från ett antal olika onåbar felkoder. Detta gör för en del intressanta möjligheter. Ta till exempel följande regel:

iptables-A FORWARD -m ttl -ttl-lt 5 -j REJECT -reject-med ICMP-värd onåbar

Denna regel säger Netfilter att när man ser ett paket med en TTL mindre än 5, bör den returnera ett ICMP destination värd onåbar paket. Med andra ord kommer Netfilter imitera en router och berätta det sändande systemet att målet värd är off-line. Här är ett exempel på tcptraceroute utgång när denna regel har genomförts:

[Root @ fubar ~] # tcptraceroute -n -f 1 -q 1 S 10.1.4.10 80
Valda enheten eth0, adress 10.1.1.10, port 47555 för utgående paket
Spåra sökvägen till 10.1.4.10 på TCP-port 80 (http), max 30 hopp
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

Jämför denna utgång till den första tcptraceroute utgången visas ovan. Observera att linje 3 är nu annorlunda. Med en vanlig brandvägg, hop tre var ett svar från målet värd. I denna utgång verkar det dock uppströms routern återvänder ett ICMP värd onåbar (betecknas som "! H") betecknar värden är off-line. Eftersom tcptraceroute tycker värden är off-line, ger upp att försöka och aldrig når målet värd.

Så medan denna teknik är lite av säkerhet genom otydlighet är det effektivt på att inaktivera ett verktyg som normalt skulle punsch rakt igenom en brandvägg. Eftersom reguljär trafik inte skulle ha en onormalt låg TTL-värdet, det matchar inte denna regel och påverkas inte.

Styra rekord rutt

I mitt andra inlägg i denna serie jag talade om rekord väg och hur den kan utnyttjas för att kartlägga genom en brandvägg. Jag diskuterade att området av verktyget är begränsad (max 8 humle, 3 om du vill hoppa info i båda riktningarna), men att det finns sätt för en angripare att komma runt denna begränsning. Jag nämnde också att kommersiella brandväggar normalt inte ger dig möjlighet att kontrollera rekord dirigera trafik.

Med Netfilter finns det stöd för att styra IP alternativ via ipv4options modulen (http://netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html). De växlar som stöds är:

  • -m ipv4options -ssrr = Matcha paket med strikta källrouting set
  • -m ipv4options -lsrr = Matcha paket med lös källdirigeringen set
  • -m ipv4options -RR = Matcha paket med posten route set
  • -m ipv4options -TS = Matcha paket med tidsstämpel set
  • -m ipv4options -ra = Matcha paket med router-varning set
  • -m ipv4options -Alla-opt = Matcha paket med minst en IP-option set

Här är ett exempel på en regel som skulle blockera paket med källvägen alternativet set:

iptables-A FORWARD-m ipv4options -RR -j REJECT -reject-med ICMP-värd onåbar

Observera att vi skickar tillbaka ett ICMP värd onåbar svar. Detta för att stänga av funktionen att kartlägga vårt nätverk.

Exec Sammanfattning

Även kommersiella brandvägg excel på central förvaltning och välja talande färger för deras grafiska gränssnitt, de brukar blek i jämförelse till Open Source brandväggar när det gäller att styra trafiken på tråden. För att skydda sina nätverk, brandväggar administratörer behöver större kontroll över IP-huvudet än att bara granska källa och destination IP-adress.

Nätverksmappning via en brandvägg - del 2

25 augusti 2009

I mitt förra inlägg diskuterade jag hur man använder ICMP tid överskrids i transit fel att mappa en nätverks omkrets. Jag diskuterade också hur man kan förebygga angripare från att använda denna teknik mot ditt nätverk. I det här inlägget ska jag diskutera en annan nätverksmappning teknik med hjälp av rekordrutt IP header alternativ.

IPv4-huvudet alternativ

Den IP-huvudet är normalt 20 byte i storlek men kan växa sig större, om ett eller flera alternativ är aktiverade. IP-tillval få läggas till i slutet av IP-huvudet, såsom visas i figur # 1. Det finns ett antal registrerade IP-tillval . De som oftast genomförs dock är de som definieras i RFC 791 . flesta operativsystem och hårdvara har implementerat IP alternativet rekord rutt (alternativ 7), som är en del av RFC 791-specifikationen.

IP-Header-options

Registrering Rutt

Skivan ruttalternativ kan producera liknande data som traceroute, men har en helt annan metod för att identifiera mellanliggande humle. Som jag diskuterade i mitt förra inlägg, traceroute använder mottagande av ICMP tid överskrids i transit fel att kart hela nätverket humle mellan två punkter. Detta kräver flera paket som skall sändas, som verktyget behöver för att inkrementera den TTL-värdet.

Record route varierar inte TTL, och kräver bara ett enda paket för att spela in humle längs en länk. Eftersom alternativet finns inom IP-huvudet, kan det vara hävstång med någon IP-transport eller tillämpning.

Här är exempel produktionen av en rekordrutt session med 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.

Från 192.168.201.1: icmp_seq = 1 Omdirigering Host (Ny nexthop: 192.168.202.2)

64 bytes from 192.168.204.10: icmp_seq = 1 ttl = 125 tid = 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 -

Ett paket som överförs, 1 emot, 0% paketförluster, tids 6ms

rtt min / avg / max / MDEV = 6,564 / 6,564 / 6,564 / 0,000 ms

Observera att genom att ställa in alternativet rekord rutt i Ping (på "R" switch) som vi har spelat in hela routern hoppar ut till målsystemet på 192.168.204.10, och tillbaka igen. Så vi har ett effektivt genererat en karta över nätverket mellan de två punkterna.

Registrering rutt decode

Här är ett exempel avkodning av en post ruttpaket:

07: 04: 32,934999 IP (tos 0 × 0, ttl 64, id 0, offset 0, flaggor [DF], proto ICMP (1), längd 124, alternativ (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 ekobegäran, ID 43604, artiklar 1, längd 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

Ett par punkter i ovanstående avkoda är värt att notera. Normalt början av IP-huvudet börjar med en Hex värde på 4500. Det innebär:

  • 4 = IP version
  • 5 = 5 32-bitars ord, eller (32/8) x 5 = 20 byte, storleken på IP-huvudet
  • 00 = Type Of Service (TOS) fält, inga värden inställd

Avkodnings ovan börjar med Hex värde "4f00", vilket innebär att IP-huvudet är större än en vanlig IP-header. Detta är vår första ledtråd att minst en IP är inställt. Hur stor är den IP-huvudet? Om vi ​​omvandlar "f" i Hex till decimal vi får 15. 15 32-bitars ord konverterar till 60 bytes, vilket är den största möjliga storleken för en IP-header.

Observera också den serie av nollor i slutet av rubriken. När en post rutt paket sänds, måste det sändande systemet att reservera utrymme för alla de IP-adresser som skall ingå. Windows kommer att be dig att identifiera detta värde direkt. Linux och UNIX helt enkelt gå för max. Det orsakar inte ett problem om reserverat plats går oanvända. Resten av paketet bär en normal Echo-Request nyttolast.

Registrering route begränsningar

Du kanske har märkt att ovanstående avkoda endast reserverat plats för 8 IP-adresser. Eftersom de flesta system på Internet är cirka 15 humle från varandra, vad händer när 8 inte är tillräckligt? Kom ihåg att vi sa 60 byte är den maximala storleken för en IP-header. Om vi ​​tar bort resten av IP-rubrikfält, lämnar det oss tillräckligt med utrymme för att lagra 9 IP-adresser. Sändar Systemet lagrar alltid det IP-adress i alternativfältet, eftersom tekniskt sett är den första IP-adressen för att vidarebefordra paketet. Detta lämnar oss tillräckligt med utrymme för maximalt 8 fler IP-adresser. Om paketet färdas över mer än 8 humle kommer de resterande routrar helt enkelt ignorera alternativet rekord rutten.

Här är ett exempel på vad jag menar. Denna utgång skapats med Ping verktyget under Windows. Den "-r" switch identifierar att rekordruttalternativ bör fastställas. Det numeriska värdet identifierar hur många humle för att spela in.

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

Pinga rr.pmtpa.wikimedia.org [208.80.152.2] med 32 byte data:

Svar från 208.80.152.2: byte = 32 tid = 702ms TTL = 50

Rutt: 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-statistik för 208.80.152.2:

Paket: Skickade = 1, Mottagna = 1, Lost = 0 (0% förlust),

Ungefärliga tur och retur gånger i millisekunder:

Minimi = 702ms, Högsta = 702ms, Average = 702ms

Den Wikipedia webbplats är faktiskt 19 humle bort från min nuvarande plats. Record rutten kan endast spela in de första åtta humle längs vägen.

Måste jag bli berörda av rekord rutt?

Eftersom rekord rutten är endast kan spela in 8 humle, och de flesta av oss är 15 humle från varandra, det är verkligen ett giltigt säkerhetsproblem? 15-hop är bara sant en majoritet av tiden. Om jag försöker spela in rutten till ett nätverk som använder samma ISP som jag gör, kommer jag förmodligen att generera en fullständig nätverkskarta. Vidare, om ett internt system blir komprometterad, spela in rutt kan lätt utnyttjas för att kartlägga nätverket från nedsatt värdens läge.

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, flaggor [none], proto ICMP (1), längd 88) 192.168.202.2> 192.168.201.10: ICMP tid överskrids i-transit, längd 68
IP (tos 0 × 0, ttl 1, ID 34730, offset 0, flaggor [none], proto ICMP (1), längd 60) 192.168.201.10> 192.168.204.10: ICMP ekobegäran, ID 18212, artiklar 1, längd 40

En intressant här är att RFC 792 definierar att paket bör utgå när TTL når 0, inte 1 Jag känner inte till något router eller system som faktiskt följer RFC. Varje enhet Jag har sett sjunker paketet när TTL är 1 Du kommer dock att hitta många felaktiga dokument som beskriver denna process citera RFC snarare än verkligheten.

Nätverk kartläggning med Timex

De flesta nätverksadministratörer är bekanta med traceroute och LFT verktyg under Linux och UNIX och tracert och Pathping under Windows. Varje verktyg kommer att identifiera alla router humle från en källsystem till ett angivet mål. Detta åstadkommes genom att sända flera paket och inkrementering TTL-värdet.

Var och en av de ovan nämnda verktygen använda Timex fel att mappa alla de routrar mellan två värdar. Ett exempel visas i figur # 2. Verktyget skulle börja med att sända paket med ett initialt TTL värde på 1 Detta orsakar den första routern för att returnera en Timex fel. Verktyget letar sedan i käll-IP-adressen för TIMEX fel, och registrerar detta som ett första steg på vägen längs länken.

tracing

Paket med en TTL av 2 sänds sedan. När de passerar genom den första routern är TTL dekrementeras till 1. Detta medför att den andra routern för att generera en Timex fel. Återigen, vi spelar helt enkelt källan IP-adressen för Timex fel som den andra hop längs länken. När en initial TTL-värdet av 3 sänds, genererar den tredje routern TIMEX felet. Detta fortsätter tills vi når så småningom målsystemet. Nu har vi ett effektivt kartlagt IP-adresserna för alla routrar mellan källan och målsystemet.

Här är ett exempel på hur produktionen kan se ut:

[Root @ fubar ~] # traceroute Jag -q 1 N 1 10.1.4.10
traceroute till 10.1.4.10 (10.1.4.10), 30 humle max, 60 byte paket
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

Kartläggning genom en brandvägg med överskriden paket

De verktyg tracert och traceroute är lätt besegrad av en brandvägg. Detta beror på att tracert sänder Echo-Request-paket som de flesta miljöer blockerar vid gränsen. traceroute kommer också att vidarebefordra Echo-Begäran om "Jag" switch används, men som standard det mål UDP-portar över 33.000. Återigen, de flesta brandväggar blockerar detta som standard så att verktyget är lätt besegrad.

Men vad händer om en angripare riktar en öppen port i brandväggen? Med andra ord, vad händer om de sänder TCP / 80 paket till webbservern, men variera TTL värden i ett liknande sätt som traceroute? Detta är exakt hur verktyget tcptraceroute fungerar. Det finns även en version för Windows . Vanligtvis kan verktyg som kartan till höger om en brandvägg.

Till exempel har vi en webbserver på 192.168.204.10 med en brandvägg sitter framför den. Brandväggen har standarden "bara låt i TCP / 80 till webbservern" politik set. Här är vad traceroute rapporter:

[Root @ fubar ~] # traceroute -q 1 N 1 -m 5 10.1.4.10
traceroute till 10.1.4.10 (10.1.4.10), 5 humle max, 60 byte paket
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 *

Och här är samma nät mappade med tcptraceroute:

[Root @ fubar ~] # tcptraceroute -n -f 1 -m 5 -q 1 S 10.1.4.10 80
Valda enheten eth0, adress 10.1.1.10, port 39142 för utgående paket
Spåra sökvägen till 10.1.4.10 på TCP-port 80 (http), max 5 humle
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 [öppna] 0,701 ms

Eftersom traceroute skickar UDP-paket, vår brandväggspolicy släpper dem vid gränsen. tcptraceroute dock skickar TCP / 80 paket till webbservern IP-adress. Eftersom detta är tillåtet enligt policyn, paketen klara sig igenom. Vi vet nu 10.1.3.1 fungerar som en brandvägg. Vi vet också att det sitter direkt framför webbservern.

Här är en kopia av en av paketen som genereras av tcptraceroute. För ett otränat öga ser det ut som en helt normal TCP / 80 SYN paket, utom TTL värdet är mycket lågt (det finns andra ledtrådar som detta paket är inte normalt, men jag ska spara det för en annan tjänst):

18: 33: 21,531117 IP (tos 0 × 0, ttl 3, id 41587, offset 0, flaggor [none], proto TCP (6), längd 40) 10.1.1.10.37496> 10.1.4.10.80: S, cksum 0x7eaa (korrekt), 1793661553: 1793661553 (0) vinna 0

Skydd mot Timex kartläggning

De flesta stateful inspektionsbaserade brandväggar är hemsk på att stoppa Timex kartläggning. I del 3 i detta inlägg, jag får in det rätta sättet att styra Timex om du kör en öppen källkod brandvägg. För nu men jag vill begränsa råd jag ger till lösningar som fungerar för varje produkt.

Det finns två delar till varje konversation, stimulus och respons. När det kommer till nätverk kartläggning kan vi effektivt omintetgöra en skanning om vi kan styra antingen del av samtalet. I det här fallet har vi:

  • Stimulus = IP-paket med en onormalt låg TTL-värdet
  • Svar = Timex från routrar, port svar från målet

Eftersom de flesta kommersiella brandväggar inte tillåter dig att filtrera trafik baserat på TTL, kan vi inte styra den stimulans i denna situation. Vi kan inte heller kontrollera port svar, eftersom det kommer att vara identisk med en normal konversation. Detta lämnar oss med de utgående Timex paket.

Så nära som möjligt till kanten av din omkrets, installera ett filter som förhindrar ICMP typ 11, kod 0 (Tid överskriden i transit) paket från att skickas till Internet. Till exempel om du har en gränsrouter utanför brandväggen, montera filtret på routern. Observera att om du kör Cisco IOS, kommer routern delvis ignorera filtret och fortfarande sänder Timex paket som genereras av det egna gränssnittet. Köra "no ip unreachables" kommandot kan förhindra detta, men det här kommandot inaktiverar alla ICMP felrapportering och kan orsaka kommunikationsproblem . Se till att du förstår den fulla effekten av detta kommando innan du använder den.

Genom att filtrera utgående Timex-paket, kommer vi att förhindra en attackerare från att se IP-adressen för alla routrar och brandväggar mellan filterinstallationspunkten och målet värd. Angriparen kommer fortfarande att kunna räkna upp hur många humle finns på länken; de bara inte kommer att kunna bestämma IP-adressen för varje.

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

Som nämnts på sidan Om, jag tillbringar lite tid undervisning datasäkerhet via SANS samt direkt till kunderna. 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. Mindre än så, och du måste skära kunskapskurvan. 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. Växlar blockerar unicast trafik till alla portar.
  • B) 2
  • C) 4
  • D) 6

2) Du får ICMP-paket som visas nedan från en fjärrvärd. Which of the following is the most likely source of the packet?

  • A) Ping körs på en 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, flaggor [none], proto: ICMP (1), längd: 28) 1.2.3.4> 172.30.2.10: ICMP echo begäran id 18.492, SEKV 21.446

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

  • A) Lugnt släppa alla inkommande SYN / ACK-paket som är oönskad.
  • B) Return an ICMP Admin Prohibited error packet for all inbound SYN/ACK traffic that is unsolicited.
  • C) Annonsera samtliga partier (även oanvända) i din IP-adress utrymme via BGP.
  • D) Rapport all misstänkt inkommande trafik till det börsnoterade administrativ kontakt för käll 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) Vilka libpcap filter skulle tillåta dig att se potentiellt skadliga IP-fragment som inte kunde ha genererats av en vanlig topologi MTU?

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

6) Vilket av följande tekniker skulle tillåta en angripare att port skanna ditt nätverk utan att ge någon uppgift om deras verkliga källan IP-adress?

  • A) nmap "stealth" (-SS) scan.
  • B) nmap "tomgång" (Si) scan.
  • C) nmap "lockbete" (D) scan.
  • D) Portsökningar kräver svar på stimuli så den verkliga källan IP kan inte helt döljas.

7) Vilket av följande beskriver vad som händer när du surfar på en webbplats, se "HTTPS" i webbadressen, och den lilla låsikonen på din webbläsare är aktiverad?

  • A) Alla data till och från webbservern är minst autentiseras.
  • B) Alla data till och från webbservern är minst krypterad.
  • C) Alla data till och från webbservern är krypterad och det digitala certifikatet är fullt verifierad.
  • D) Alla data till och från webbservern är autentiserad och krypterad.
  • E) Alla data till och från webbservern autentiseras, krypterad och det digitala certifikatet är fullt verifierad.

8) Du ser följande paket lämnar din webbserver och leds till en IP-adress på Internet. Vilken är den troligaste orsaken?

  • A) Problem med brandväggen tillståndstabell timeout sätts för lågt.
  • B) Automatisk uppdatering söker efter nya patchar.
  • C) Anfallare hämta en verktygslåda.
  • D) En säker HTTPS-session.

17: 08: 08,412172 IP (tos 0 × 0, ttl 128, ID 18210, offset 0, flaggor [DF], proto: UDP (17), längd: 33) 172.30.2.185.32851> 1.2.3.4.69:

9) Du ser följande paket kommer in i nätverket. Vilket svar ger den mest exakta och sannolika möjligheten att vad som händer?

  • A) TCP sändning från en Windows-system.
  • B) SMTP överföring från en Windows-system.
  • C) Spam eller phishing försök från en Windows-system.
  • D) SMTP överföring från ett Linux eller Unix-system.

19: 22: 17,631407 IP (tos 0 × 0, ttl 112, ID 30435, offset 0, flaggor [DF], proto: TCP (6), längd: 48) 1.2.3.4.4110> 192.168.1.10.25: S , cksum 0xc25c (korrekt), 103.504.428: 103.504.428 (0) vinner 8192 <mss 1460, nop, nop, sackOK>

10) Med tanke på följande netstat utgång, vilket av svaren bästa beskriver situationen:

  • A) Systemet har potentiellt äventyrats.
  • B) Systemet behöver en omstart för att installera uppdaterad programvara.
  • C) Systemet är konfigurerat som en typisk Windows-skrivbordet.
  • D) Systemet är konfigurerat som en typisk 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) Det här är normalt och förväntat trafik till våra servrar.

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. Växlar blockerar unicast trafik till alla portar.

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 körs på en 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) Lugnt släppa alla inkommande SYN / ACK-paket som är oönskad.

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) Rapport all misstänkt inkommande trafik till det börsnoterade administrativ kontakt för käll 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) Portsökningar kräver svar på stimuli så den verkliga källan IP kan inte helt döljas.

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.

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″ “-” “-”

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

Trafiken i fråga är en utgående försök att ansluta till en TFTP-server. Since Web servers do not use TFTP, this is not a problem with the firewall state table. Dessutom behöver säljare inte gör korrigeringar tillgängliga via TFTP, så detta är inte en check på nya patchar. 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 använder 128 som utgångs TTL så detta sannolikt skulle kunna vara en Windows-värd ligger 16 humle bort. Detta är ett TCP-paket på väg till port 25, så det är mest sannolikt början på en SMTP-session. Systemet använder en mycket liten fönsterstorlek (8192 bytes) och stöder inte TCP fönsteralternativet (skulle detta vara införd i den ut som "wscale" följt av ett numeriskt värde), vilket tyder på att det är en äldre Windows-skrivbordssystem . Eftersom de flesta organisationer inte lita på gamla Windows-datorer som deras SMTP-servrar, är det sannolikt en nedsatt värd sänder spam eller phishing-attacker. En brandvägg såsom pf eller Netfilter skulle kunna filtrera dessa paket genom att passivt identifiera källan operativsystemet.

10) A

Inom en Linux eller UNIX-miljö, kan portarna endast öppnas exklusivt. 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. Resultatet är att en ansökan kommer att serva de flesta inkommande sessioner, men om den porten är busied ut, anslutningar sedan till det andra programmet. This can permit an attacker to open a back door on a system that is undetectable during port scans of the system.

11) D

Den klassiska uppfattningen är att endast system med öppen lyssnande portar utsätts för tillgång till Internet är känsliga för angrepp. Poängen med risk är faktiskt tillåter okända enheter att interagera med kod som körs på det lokala systemet. 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

Det finns många misstänkta mönster i dessa loggposter. 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. Detta innebär att inga TCP optioner har ställts in. 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.

Så vad händer? 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). Om du vet vilken brandväggsprodukter hävstång varje teknik, dess nu bara en fråga om att ytterligare minska möjligheterna.

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. Baserat på vad svaren kommit tillbaka från var och en av dessa prob-paket en smart angripare kan få möjlighet att identifiera vilken leverantör brandväggsprodukt som vi kör.

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; genom brandväggen, genom VPN-gateway och genom omkopplaren. Brandväggen kan angripas direkt eller via Data svar från en skadlig webbplats. 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. Funktioner som automatisk trunk förhandling kan utnyttjas för att få tillgång till det interna nätverket från DMZ, alltså förbi brandväggen filtreringskapacitet mellan dessa två säkerhetszoner.

So how did you do? Riktmärket är att kunna svara på (vilket innebär att du visste svaret, inte bara en lycklig gissning ;) ) 12/15 questions. Om du fick under den punkten är det dags att finslipa de gamla färdigheter.