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 omkrets 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 omedelbart 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 är en del av 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 en å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 varit övervakning av 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 föregående paket). 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. Skannern kommer att göra flera försök för att se till att paketen inte bara gå vilse. Eftersom den öppna porten som faktiskt kommer att svara, är endast en sond paket som erfordras.

När en inaktiv skanning utförs, är det tvärtom. Om ett brandväggs porten sonde blir det ingen IP-ID ökningen förändring i Windows-systemet. Så bara en check krävs för att bekräfta detta är inte ett aktivt lyssnande port. När en öppen port är sonderas dock kommer vi att upptäcka en ändring i Windows-systemets IP-ID steg. Även om vi tror att det beror på oss att 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 ID-uppgifter för Windows IP förblir konstant.

Alltså:

  • Probe brandvägg hamnar oftare än öppna portar = normal port scanner
  • Sond öppna portar oftare som en brandvägg portar = inaktiv skanner

Timing

Normala portskanningar vara extremt snabbt. Det är inte ovanligt att se hundratals prob paket per sekund. Med en inaktiv skanning men vi måste ta det lite långsammare. Detta beror på att vi måste kontrollera IP ID för falsk adress, skickar sonden paketet, tillåta tillräckligt med tid för sonden att framkalla en reaktion, ge falska systemet tillräckligt med tid för att reagera med en återställning om det behövs (alltså med hjälp av en IP-ID ), och sedan kontrollera IP-ID igen för att se om ökningen har förä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 scanningshastighet fungerar bra om alla system är på samma kopplade nätet. Om värdarna är 15 hopp ifrån varandra på Internet har dock min erfarenhet varit riktigheten rating sjunker betydligt om du inte sakta ner skanningshastighet.

Alltså:

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

TTL-fältet

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

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



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

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 olika berättar att en av dem är förfalskat.

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

Om TTL matchar, kan vi inte helt utesluta en inaktiv skanning. Angriparen kan bara vara så bra.

Alltså:

  • TTL för Syns och RSTS är konsekventa men matchar inte = inaktiv skanner
  • TTLS av Syns och RSTS matcha = normal port scanner eller smart tomgång scanner

IP-ID-värde

Det bästa sättet att märka en inaktiv skanning är utnyttja samma sak angriparen använder, nämligen IP-ID-värdet. Ta en titt på de två senaste avkodade paketen. Observera att IP-ID i den första är 15249, men i det andra är det 176. Om du ser en inaktiv skanning, kommer du att märka resten paketen har genomgående en IP-ID 2 (samma sak angriparen ser), men SYN paket kommer att ha några helt orelaterade värde. IP ID ökning 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 hitta några mönster i IP-ID för de övriga paketen som gör inte jive med IP-ID i SYN paket.

Alltså:

  • IP ID för SYN och RST-paket visas relaterade = normal port scanner
  • IP ID ökning av RST matchar inte Syns = inaktiv skanner

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 skanning. 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 skanningen är en inaktiv skanning kontra en vanlig port scan. Det finns ett antal berätta tale ledtrådar i paket, det bästa som är IP-ID-värdet.

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 källa IP-adress 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 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älla IP-adresser. Från målvärden, ser det ut som alla de falska IP-adresser, liksom 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 egentligen inte dölja den verkliga källan, som källa IP-adress är en av de IP-adresser som utför genomsökningen. Om du vet vad du ska leta efter, kan du enkelt räkna ut vilken källa IP är faktiskt skannar dig. Så även om denna teknik kommer att fungera, är det inte helt effektiv på att gömma käll-IP-adress.

Vad är en inaktiv skanning?

När vi utför en inaktiv skanning, vi egentligen 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, ser vi för antikroppar som får produceras när viruset finns i systemet. En ledig genomsökning upptäcker öppna portar på ungefär samma sätt.

Innan vi kan gräva för djupt i en inaktiv skanning, 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 tillräckligt specifik för 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 ange vilken start TTL-värdet ska användas, så olika operativsystem använder olika utgångs TTL. De RFC beskriver hur Ping borde fungera, men inte bestämma vad som ska vara i nyttolasten av Echo-Request-paket. Återigen, olika tillverkare använder olika värden. Dessa nyanser kan tillåta dig att identifiera källan operativsystem baserade variationer i paketets innehåll. Tekniken kallas passiv fingeravtryck .

IP identifierarfält (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, är det RFC-kompatibel, om en eller flera IP-ID-värden får användas igen. De behöver inte vara, men om det gör det hända att det inte är ett problem.

Så RFC säga IP-ID måste vara unikt, men det är inte riktigt binda hur man ska generera värde. Detta har lett till olika operativsystem som använder olika metoder. Till exempel Windows startar på en IP-ID-värde på 1 och bara ökar värdet med 1 för varje paket som lämnar systemet. När det maximala värdet av 65535 nås, börjar det tillbaka över på ett. 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 huvuden + 0 databyte

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

len = 46 ip = 192.168.100.2 ttl = 128 id = en sport = 0 flags = RA seq = 1 vinst = 0 RTT = 0,4 ms

len = 46 ip = 192.168.100.2 ttl = 128 id = en 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 = en sport = 0 flags = RA seq = 4 win = 0 RTT = 0,4 ms

len = 46 ip = 192.168.100.2 ttl = 128 id = en 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ång vi använder "-r" switch att ha hping övervakning av 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. Nu titta på "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 detta fall här värdet är 108. Varje efterföljande rad skriver sedan ut deltat förändring från föregående paketet. Så i den andra raden den faktiska IP-ID var 109, vilket är "+1" från det tidigare värdet på 108. Nästa paket hade en IP-ID 110, som är "+1" från den tidigare IP-ID-värde på 109.

Titta noga på den fjärde raden av produktionen. Observera deltaförändringen var "två". 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 var 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 som den sänder ut. Till exempel hade den linjen läste "+5", skulle vi veta att Windows-system som sänds fyra andra paket sedan svara på vår sista sond.

Upptäcka öppna portar

Så hur kan vi utnyttja den förutsägbara IP ID-värdet för Windows för ont? En möjlighet är att stänga av Windows-system till en öppen port sensor. 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 spoofing källan IP-adressen för Windows-system, skicka ett SYN paket till TCP-port som vi vill mäta på målet.

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

Den RFC tillstånd du aldrig ska svara på fel paket, oavsett om du anser dem vara legitima eller inte. Så när rutan Windows tar emot TCP reset felpaketet från målet värd, tyst ignorerar det och kasserar paketet.

Saker och ting blir lite mer intressant när en SYN / ACK mottas dock. Från Windows-systemets perspektiv är det bara hänger skötte sin egen verksamhet när någon okänd systemet skickar ett SYN / ACK paket (minns vi falska Windows-systemets IP-adress i sonden paketet). 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 det avlägsna målet talar om.

Med detta i åtanke Windows-systemet skickar ett TCP-återställning felpaket tillbaka till målet värd. När återställnings paket sänds, visas nästa tillgängliga IP-ID som används i IP-huvudet. Detta saknade IP-ID kan upptäckas vi fortfarande övervakar IP-ID ökningen en gång per sekund. Så för att granska:

  • 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 som bara sonder för att öppna portar gör att IP-ID ökningen till förändring.

Förbehåll

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

Naturligtvis 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ända, så du kanske vill utföra flera kontroll av varje öppen port bara för att se IP-ID ökningen förändring i själva verket beror på en öppen port som sonderas.

Exec Sammanfattning

En ledig skanning låter dig söka öppna portar på en avlägsen mål, samtidigt lura målet att tro att någon tredje part systemet utför genomsökningen. Öppna portar upptäcks genom övervakning för 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 inaktiv 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. Den första lånefinansierade ICMP tid överskrids i transit fel, medan den andra används för IP-rekord ruttalternativ. 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ött 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 också.

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ända för att manipulera Netfilter rulebase. Netfilter är en mycket kapabel brandvägg med för många funktioner för att täcka i det här inlägget. Jag rekommenderar starkt 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 funktionerna.

Styra tcptraceroute

I det första inlägget beskrev jag hur verktyg som tcptraceroute slog tillbaka genom ett öppet brandväggsregel för att kartlägga nätverket som sitter bakom den. Med kommersiella brandväggar, var vi begränsade till att kontrollera 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 visst 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 en TTL på ett angivet värde
  • -M ttl-ttl-gt = Math paket med TTL högre än ett angivet värde
  • -M ttl-TTL-lt = Matcha paket med en TTL under ett visst värde

Här finns en möjlig Netfilter regel som 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 fallet är förpackningen tappas. Eftersom den lägsta TTL används av ett modernt operativsystem är 64, och de flesta system är cirka 15 humle bort från varandra på Internet, bör vi aldrig av misstag 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), 5 humle max
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ör den ovan Netfilter regeln:

[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), 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 [Öppna] 1.007 ms

Observera att när vi börjar filtrera på TTL-värdet, utseendet på vår 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.

Att 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 ett administrativt förbjudet felmeddelande, låter Netfilter du välja mellan ett antal olika onåbar felkoder. Detta gör att en del intressanta möjligheter. Ta till exempel följande regel:

iptables-A FORWARD-m ttl-TTL-lt 5-j REJECT-avvisa-med ICMP-host-onåbar

Denna regel säger Netfilter att när det 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 sändningssystem som målvärden ä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), 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

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, hoppa 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") som betyder 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 mörkläggning, är det effektivt på att inaktivera ett verktyg som normalt skulle punsch rakt igenom en brandvägg. Eftersom regelbunden trafik inte skulle ha en onormalt låg TTL-värdet, inte matcha denna regel och är opåverkad.

Styra record route

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 utbudet av verktyget är begränsad (max 8 humle, 3 om du vill hoppa information i båda riktningar), 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 linjetrafik.

Med Netfilter, det finns stöd för att styra IP alternativ via modulen ipv4options (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 rutt set
  • -M ipv4options-ts = Matcha paket med tidsstämpel set
  • -M ipv4options-ra = Matcha paket med router-varning set
  • -M ipv4options-någon-opt = Matcha paket med minst en IP-option set

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

iptables-A FORWARD-m ipv4options-rr-j REJECT-avvisa-med ICMP-host-onåbar

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

Exec Sammanfattning

Även kommersiella brandvägg utmärka sig på centraliserad hantering och välja talande färger för sin grafiska gränssnittet, de brukar blek i jämförelse med öppen källkod brandväggar när det gäller att styra trafiken på tråden. För att skydda sina nätverk, brandvägg administratörerna behöver större kontroll av 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 förhindrar angripare från att använda denna teknik mot ditt nätverk. I detta inlägg ska jag diskutera ett annat nätverk kartläggning teknik med hjälp av skivrutt 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-huvud, som visas i figur nr 1. Det finns ett antal registrerade IP-tillval . De som oftast genomförs är dock de som definieras i RFC 791 . De flesta operativsystem och hårdvara har implementerat IP alternativet rekord rutt (alternativ 7), vilket är en del av RFC 791-specifikationen.

IP-Header-options

Record Rutt

Skivan ruttalternativ kan ge liknande uppgifter till traceroute, men har en helt annan metod för att identifiera förmedlande humle. 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.

Rekordvägen varierar inte TTL, och bara kräver ett enda paket för att spela in humle längs en länk. Since the option exists within the IP header, it can be leverage with any IP transport or application.

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 Omdirigera Host (Ny 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 rutt decode

Här är ett exempel avkodning av ett rekord rutt paket:

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

Avkodnings ovan börjar med Hex-värde "4f00", vilket innebär att IP-huvudet är större än en vanlig IP-headern. Detta är vår första ledtråd att minst en IP är inställt. Hur stor är den IP-huvudet? 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 kommer att be dig att identifiera detta värde på framsidan. Linux and UNIX simply go for the maximum. It does not cause a problem if reserved space goes unused. Resten av paketet bär en normal Echo-Request nyttolast.

Record route begränsningar

Du kanske har märkt att ovanstående avkoda endast reserverat plats för 8 IP-adresser. 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. Om vi ​​tar bort resten av IP-rubrikfält, ger det oss tillräckligt med utrymme för att lagra 9 IP-adresser. Sändar Systemet lagrar alltid det är 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 ytterligare 8 IP-adresser max. 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. Denna utgång skapats med Ping verktyget under Windows. Den "-r" switch identifierar att rekordet ruttalternativ bör fastställas. Det numeriska värdet anger 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

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

Paket: Skickade = 1, mottagna = 1, Förlorade = 0 (0% förlust),

Approximate round trip times in milli-seconds:

Minimi = 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.

Behöver jag vara orolig med rekord rutt?

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.

Så spela in rutten är inte en vanlig attack vector, men det kommer säkert att bli ett av de verktyg en smart angripare kommer att utnyttja när det är möjligt.

Att skydda mot posten rutt

Rekord väg är en av de kommunikationsparametrar som får ignoreras av de flesta kommersiella brandväggar leverantörer. Med det menar jag att de inkluderar stöd för rekord rutt i sin RFC-kompatibla IP-stacken, men ger dig lite möjligheten att kontrollera den via policytillämpning. Öppen källkod brandväggar brukar göra ett bättre jobb kontrollerar rekord väg, men jag ska få in det i del 3 i denna serie.

Om din brandvägg, HIPS eller HIDS ger dig tillgång till signaturen språk, kan du brukar skriva en signatur att flagga alla paket med en IP-header storlek större än 20 byte. Detta garanterar inte paketet med hjälp av registervägen, eftersom det också kan innebära att någon annan IP-alternativet används. För att vara ärlig kan dock alla IP alternativ tas tillvara för det onda. Var och en av dem ska blockeras, eller åtminstone upptäcks vid omkretsen. Jag täcker mer om IP-alternativ i ett senare inlägg.

Exec Sammanfattning

Rekord rutt kan producera en nätverkskarta som liknar den traceroute verktyg, men är begränsad till endast inspelning 8 humle. Även detta begränsar dess användbarhet för en angripare, det fullt möjligt att köra en rekordrutt session tillräckligt nära målet nätverk för att räkna upp värdefulla data. De flesta brandväggar inte ger dig möjlighet att kontrollera rekord linjetrafik, men du kanske kan styra / upptäcka det med en signatur baserad enhet.

Nätverksmappning via en brandvägg - Del 1

24 augusti, 2009

När vi skapar en uppsättning brandväggsregler, är oftast ett av våra mål att stoppa angriparna på Internet från att kunna kartlägga det interna nätverket som sitter bakom brandväggen. I denna skriva upp jag kommer att diskutera två olika tekniker som låter en angripare punsch rätt om de flesta brandväggsinställningar, och vilka ytterligare åtgärder som måste vidtas för att förhindra dem.

De två tekniker som vi behandlar är:

  • Eliciting tid överskrids i transit fel
  • IP header rekord ruttalternativ

Förstå tid överskrids i transit fel

När en router tar emot ett paket som reser från ett nätverk till ett annat, är det nödvändigt att minska det TTL-värdet med ett. Så om paketet har för närvarande en TTL av 120, skulle routern ändra värdet till 119 när den passerar paketet längs nätet. TTL-fältet är bitgruppen 8 inom IP-headern och är visad i figur # 1.

IP-Header

Om en router mottar ett paket med en TTL-värde på ett, är det inte tillåtet att minska värdet till 0. Snarare ger routern en ICMP typ 11, kod 0 paket, kallas ett ICMP tid överskrids i transit (Timex) fel. Timex fel skickas sedan till källan IP-adressen i det paket som hade ett TTL-värde på 1. Här är ett exempel Timex paket. Observera att 28 bitgrupper av det ursprungliga paketet som orsakade Timex som skall alstras är inbäddad i nyttolasten. TTL värdet av denna inbäddade header är 1.

10:14:19.947925 IP (tos 0xC0, ttl 63, ID 26344, offset 0, flaggor [ingen], 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 [ingen], proto ICMP (1), längd 60) 192.168.201.10> 192.168.204.10: ICMP echo begäran, ID 18212, artiklar 1, längd 40

En intressant här är att RFC 792 definierar att paketen ska tappas 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 som jag har sett sjunker paketet när TTL är 1. Du kommer dock att hitta många felaktiga dokument som beskriver denna process citerar 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 ett källsystem till ett angivet mål. Detta åstadkommes genom att sända flera paket och inkrementering av TTL-värdet.

Var och en av de ovan nämnda verktygen använda Timex fel för att mappa alla de routrar mellan två värdar. Ett exempel visas i figur nr 2. Verktyget skulle börja med att sända paket med en initial TTL-värde på 1. Detta bringar den första routern att returnera en Timex felet. Verktyget letar sedan i IP-källadress 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 ett. Detta medför att den andra routern för att generera en Timex felet. Återigen registrerar vi helt enkelt IP-källadressen hos 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 slutligen når målsystemet. Vi har nu ett effektivt sätt 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-I-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 sända Echo-Begäran om "-I" 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 din webbserver, men variera TTL-värden i ett liknande sätt som traceroute? Det är precis hur verktyget tcptraceroute fungerar. Det finns även en version för Windows . Vanligtvis kan verktyg som kartan till höger om en brandvägg.

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. Här är vad traceroute rapporter:

[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 *

Och här är samma nätverk 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), 5 humle 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

Eftersom traceroute skickar UDP-paket, vår brandväggspolicy tappar dem vid gränsen. tcptraceroute however is sending TCP/80 packets to the Web server's IP address. Eftersom detta är tillåtet enligt den policy, paketen klara sig igenom. We now know 10.1.3.1 is acting as a firewall. Vi vet också att det sitter direkt framför webbservern.

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-paket med en onormalt låg TTL-värde
  • 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.

Så nära som möjligt till kanten av din omkrets, installera ett filter 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, installera filtret på routern. 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. Vidare, dessa verktyg är oftast effektiva som uppräkning av network address translation (NAT) inställningar. 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. Jag lägger svaren på en annan tjänst så dess mindre frestande att fuska. ;)

OBS: Jag har trasslat med inlämningsdatum så att svaren inte visas innan frågorna på huvudsidan.

1) Hur många olika tekniker finns tillgängliga för att sniffa på en switchad miljö:

  • 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 med "-sP" alternativet.

15:52:50.129178 IP (tos 0 × 0, ttl 47, ID 51389, offset 0, flaggor [ingen], proto: ICMP (1), längd: 28) 1.2.3.4> 172.30.2.10: ICMP echo begäran, id 18492, seq 21446

3) Vilket är det bästa sättet att avskräcka angripare från att använda din adressutrymme som en del av en 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) Vilka brandväggsprodukt är känslig för lös källa rutt attacker?

  • 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 och ont bit = aktivera
  • B) ip [12:02] = ip [16:02]
  • C) ip [02:02] <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 indikation om deras verkliga källan IP-adress?

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

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ås-ikonen 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 helt verifieras.
  • D) Alla data till och från webbservern är autentiserad och krypterad.
  • E) Alla data till och från webbservern är autentiserad, krypterad och det digitala certifikatet är helt verifieras.

8) Du ser följande paket lämnar din webbserver och leds till en IP-adress på Internet. What is the most likely cause?

  • A) Problem med brandväggen tillståndstabell time-out är för lågt.
  • B) Automatic update checking for new patches.
  • C) Anfallare hämta en verktygslåda.
  • D) A secure 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 paketet som 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 transmission from a Windows system.
  • C) Spam or Phishing attempt from a Windows system.
  • D) SMTP-sändning från en Linux-eller 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) 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 AVLYSSNINGS 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) Vilket av följande system kan eventuellt tas över av en angripare?

  • A) A Web server exposed to Internet access.
  • B) A desktop with Internet access.
  • C) En brandvägg eller nätverks Based Intrusion Prevention (NIPS) systemet.
  • D) Alla ovanstående.
  • E) None of the above.

12) En nätverksbaserad Intrusion Prevention System (NIPS) är helt enkelt en relabeled:

  • A) Proxy baserad brandvägg.
  • B) Stateful inspektion baserad brandvägg.
  • C) Inte heller är det sin egen unika teknik.
  • D) en kombination av båda.

13) Du ser följande mönster i ditt brandväggslogg, som svarar bäst beskriver vad som kan vara på gång?

  • A) Någon är fingeravtryck som brandvägg produkt vi använder.
  • B) En annan sajt är att ha anslutningsproblem som ansluter till vår webbserver.
  • C) The state table time-out value on our firewall is set too low.
  • D) This is normal and expected traffic to our servers.

8 jun 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
8 jun 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
8 jun 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
8 jun 05:40:45 SRC = 1.2.3.4 DST = our_dns_server LEN = 38 TTL = 44 ID = 7834 PROTO = ICMP TYPE = 8 KOD = 0 ID = 47578 SEK = 5
8 jun 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
8 jun 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 hämtar patchar.
  • C) Någon på 192.168.1.22 kör en nmap version scan mot 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) Analysera följande nätverksritning. Hur många potentiella vägar behöver en angripare har tillgängliga för att få tillgång till det interna nätverket?

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

network-paths

Svaren kommer att publiceras i morgon!

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) Du får ICMP-paket som visas nedan från en fjärrvärd. Vilket av följande är den mest sannolika källan av paketet?

15:52:50.129178 IP (tos 0 × 0, ttl 47, ID 51389, offset 0, flaggor [ingen], proto: ICMP (1), längd: 28) 1.2.3.4> 172.30.2.10: ICMP echo begäran, 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 med "-sP" alternativet.

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) Vilka brandväggsprodukt är känslig för lös källa rutt attacker?

A) Check Point

B) Cisco

C) Netscreen

D) None of the above

5) Vilken 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 och ont bit = aktivera

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

C) ip [02:02] <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 indikation om deras verkliga källan IP-adress?

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

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

C) nmap "lockbete" (-D) skanna.

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

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ås-ikonen 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 helt verifieras.

D) Alla data till och från webbservern är autentiserad och krypterad.

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

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 med brandväggen tillståndstabell time-out är för lågt.

B) Automatic update checking for new patches.

C) Anfallare hämta en verktygslåda.

D) A secure HTTPS session.

9) You see the following packet entering your network. Vilket svar ger den mest exakta och sannolika möjligheten att vad som händer?

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-sändning från en Windows-system.

B) SMTP transmission from a Windows system.

C) Spam or Phishing attempt from a Windows system.

D) SMTP-sändning från en Linux-eller Unix-system.

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

Proto Local Address Utländsk adress State PID

TCP 0.0.0.0:80 0.0.0.0:0 LYSSNANDE 2648

TCP 0.0.0.0:80 0.0.0.0:0 LYSSNANDE 2292

TCP 0.0.0.0:135 0.0.0.0:0 LYSSNANDE 1204

TCP 0.0.0.0:445 0.0.0.0:0 LYSSNANDE 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) Systemet är konfigurerat som en typisk Windows-server.

11) Vilket av följande system kan eventuellt tas över av en angripare?

A) A Web server exposed to Internet access.

B) A desktop with Internet access.

C) En brandvägg eller nätverks Based Intrusion Prevention (NIPS) systemet.

D) All of the above.

E) None of the above.

12) En nätverksbaserad Intrusion Prevention System (NIPS) är helt enkelt en relabeled:

A) Proxy baserad brandvägg.

B) Stateful inspektion baserad brandvägg.

C) Inte heller är det sin egen unika teknik.

D) en kombination av båda.

13) Du ser följande mönster i ditt brandväggslogg, som svarar bäst beskriver vad som kan vara på gång?

A) Någon är fingeravtryck som brandvägg produkt vi använder.

B) En annan sajt är att ha anslutningsproblem som ansluter till vår webbserver.

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

Juni 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

Juni 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

Juni 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

Juni 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

Juni 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) Du ser följande trafikmönstret i din proxylogg. Vilken är den troligaste orsaken?

A) 192.168.1.22 is performing normal Web browsing.

B) 192.168.1.22 hämtar patchar.

C) Någon på 192.168.1.22 kör en nmap version scan mot 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

I gårdagens inlägg gav jag dig en snabb nätsäkerhet test för att prova. Here are the answers:

1) D

Det finns sex olika tekniker som kan användas för att vädra i en switchad miljö. ARP cache poisoning, ARP cache flooding, DHCP spoofing, Port stealing, ICMP redirect attack and ICMP route discovery attack. Leverantörs switchar High end kan konfigureras att blockera alla dessa utom ICMP omdirigera attack. Det måste åtgärdas på en per värdnivå.

2) D

Ping on both Windows and Linux encapsulate data in the payload of their Echo-Request packets. Ovanstående paket har en längd på 28, vilket är bara en IP och ICMP header. When hping generates Echo-Request packets, it uses an initial sequence number of 0 and then increments by +256. Den ovan sekvensnummer 21446 inte är jämnt delbart med 256. Detta gör nmap den mest sannolika kandidaten som den genererar tomt nyttolast Echo-Begäran med slumpsekvensnummer.

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. Lugnt släppa denna trafik gör din adressutrymmet mycket attraktiv för angripare skoja paket eftersom det maximerar den tid deras anfall SYN paket fylla upp den fjärranslutning skön. Genom att lämna ett ICMP fel för dessa paket, blir din IP-adress utrymme mindre önskvärt eftersom du snabbt ta bort den attacker SYN paket från fjärranslutning skön.

4) C

All three products prevent source route packets (both loose and strict) from being bounced off of the firewall itself. Netscreen emellertid passerar löst källa dirigera paket som riktar en värd på den andra sidan. 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. Den andra delen av filtret, "ip [6] & 32! = 0" kontrollerar om den mer fragmentet flagga sätts på. So the complete filter will catch non-last fragments smaller than 500 bytes. Alla icke-sista fragmenten kommer att uttrycka den minsta topologi Maximum Transmission Unit (MTU) de passerar igenom. Den minsta LAN eller WAN MTU används på Internet är 512 byte. 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 och lock alternativ fortfarande sända paket med hjälp av angriparens verkliga källan IP-adress.

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. Så det är möjligt att använda antingen SSL eller TLS för att kommunicera utan att kryptera någon av de uppgifter som passerar mellan systemen. Det enda sättet att förhindra detta är att inaktivera dessa alternativ i din webbläsare. 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. Detta kan också ändras via webbläsarens alternativ.

8) C

The traffic in question is an outbound attempt to connect to a TFTP server. Eftersom webbservrar inte använder TFTP, är detta inte ett problem med brandväggen tillståndstabell. 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. 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 inte stöder TCP fönsteralternativet (detta skulle vara införd i den produktionen som "wscale" följt av ett numeriskt värde), vilket tyder på att det är en äldre Windows-skrivbordssystem . 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. En brandvägg som t.ex. pf eller Netfilter skulle kunna filtrera dessa paket genom att passivt identifiera operativsystemet källan.

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. Resultatet är att en ansökan kommer att betjäna de flesta inkommande sessioner, men om den porten är busied ut, är anslutningarna 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 öppna lyssnande portar utsätts för tillgång till Internet är känsliga för angrepp. 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. Med detta i åtanke, kan alla potentiellt vara fjärr äventyras.

12) B

Nätverksbaserade system för förebyggande intrångs hävstång Stateful Inspection teknik för att analysera både sidhuvud och nyttolastinformation, samma som en stateful inspection baserad brandvägg. 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. För att starta, är det Time To Live (TTL) i det första paketet 2. Med tanke på moderna operativsystem använder en start TTL på 64 eller högre, och de flesta system är cirka 15 humle bort från varandra på internet, skulle vi aldrig se en TTL denna låga. Troligtvis det är någon som kör en tcptraceroute variant för att kartlägga vårt nätverk genom brandväggen.

Titta på längden av de första tre TCP-paket, dess 40 bitgrupper. Detta innebär att inga TCP alternativ 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.

So what's going on? Look at the source port in the first two packets. Baserat på svaret (om någon) från dessa sonder en smart angripare kan berätta vilken teknik brandväggen bygger på (proxy, statisk filtrering eller Stateful-filtrering). 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. Det tredje paketet skulle identifiera om en ACK kan skapa en ny stat tabellpost, som återigen görs av vissa varor men inte andra. 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

De loggposter hävdar detta är normalt HTTP 1.1 trafik. Problemet är att vanlig HTTP-trafik skulle omfatta ytterligare fält av information såsom den fullständiga URI besökte (vi bara se målet IP-adress 1.2.3.4) och värdidentifieringsfältet (vilken operativsystem som används, namn och version av webbläsaren, etc). Both of these pieces of information are missing, which makes the log entries very suspicious. GET och POST karaktären av trafiken innebär att ett informationsutbyte sker. 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. Funktioner som automatisk stammen förhandling kan utnyttjas för att få tillgång till det interna nätverket från DMZ, alltså förbi brandväggens filtreringskapacitet mellan dessa två säkerhetszoner.

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.