Detektering av typ av operativsystem med hjälp av TCP/IP stackens fingeravtryck

Detektering av typ av operativsystem med hjälp av TCP/IP stackens fingeravtryck
av Fyodor <fyodor@insecure.org> (insecure.org)
Skapad: 8 juni, 2001
Senast ändrad: 8 juni, 2001

Detta dokument får distribueras fritt. Senaste kopian är alltid
tillgänglig på http://nmap.org/nmap-fingerprinting-article.html

SAMMANFATTNING

Detta dokument beskriver hur man får tag i värdefull information om ett
system genom att undersöka dess TCP/IP stack. Först kommer jag att presentera
några av de "klassiska" metoderna för att avgöra systemets OS. Dessa metoder
använder sig inte av stackens fingeravtryck. Sen beskriver jag de nuvarande
"state of the art" verktygen för stack fingeravtryck. Sedan kommer en beskrivn-
ing av många av de olika tekniker som får fjärrsystemet att läcka information
om sig själv. Slutligen ger jag en detaljerad beskrivning av hur jag har imple-
menterat det i nmap. Detta följs av olika ögonblicksbilder som visar vilka ope-
rativsystem som körs på flera populära Internet siter.

ORSAKER

Jag tror att det är ganska uppenbart varför det är intressant att avgöra vilket OS
som ett system kör, så därför kommer jag hålla detta avsnitt kort. En av de starkaste
anledningarna är att många säkerhetshål är beroende av OS version. Låt oss säga att
du gör ett penetreringstest och finner att port 53 är öppen. Om det är en sårbar
version av Bind, så kommer du bara att få en chans att exploatera den för att ett
felaktigt försök kommer att krascha demonen. Med en bra fingeravtrycksprogramvara för
TCP/IP kan du snabbt ta reda på om maskinen kör 'Solaris 2.51' eller 'Linux 2.0.35'
och anpassa din kod därefter.

En annan värre möjlighet är att någon scannar 500,000 system i förväg för att se vilka
OS som körs och vilka portar som är öppna. När sedan någon gör ett inlägg (säger) att
det finns ett root-hål i Suns comsat demon, så kan den lille crackers söka igenom sin
lista efter 'UDP/512' och 'Solaris 2.6' och genast får han sida efter sida fylld med
maskiner som han kan bli root på. Värt att notera är att detta beteende hör till
SCRIPT KIDDIES. Du har inte demonstrerat någon färdighet och ingen kommer att vara
det minsta imponerad av att du har lyckats hitta någon sårbar .edu som inte lyckades
patcha hålet i tid. Människor kommer bli än mindre imponerade om du använder din
nyfunna kunskap till att sänka avdelningens webb-server samtidigt som du med ditt
självcentrerade skryt berättar om hur duktig du är och hur dumma systemadministratörerna
måste vara.

Ett annan möjligt användningsområde är social engineering. Låt oss säga att du scannar
företaget som är ditt mål och nmap rapporterar om en 'Datavoice TxPORT PRISM 3000 T1
CSU/DSU 6.22/2.06'. Hackern kan nu ringa upp och utge sig för att vara från 'Datavoice support'
och berätta om vissa problem med deras PRISM 3000. "Vi kommer att berätta om ett
säkerhetshål snart, men först vill vi att alla våra nuvarande kunder installerar patchen --
Jag skickade precis den till dig..." Vissa naiva administratörer kommer kanske att tro
att endast en behörig tekniker från Datavoice kan känna till så mycket om deras CSU/DSU.

Ett annat användningsområde är att göra en utvärdering av de företag som du ska göra affärer
med. Innan du väljer en ny ISP, scanna dem och se vilken typ av utrustning de använder.
De där "1000 kr/år" affärerna kanske inte låter lika bra när du ser att de använder sig
av skräp-routrar och kör PPP-tjänster på ett gäng Windows burkar.

KLASSISKA TEKNIKER

Stack fingeravtryck löser problemet med OS identifiering på ett unikt sätt. Jag tycker att
denna teknik är mest lovande, men det finns för närvarande många andra lösningar. Trist nog
är detta fortfarande en av de mest effektiva metoderna:

playground~> telnet hpux.u-aizu.ac.jp
Trying 163.143.103.12 ...
Connected to hpux.u-aizu.ac.jp.
Escape character is '^]'.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

Det finns ingen mening med att gå igenom allt besvär som det innebär med fingervatryck om
maskinen ändå annonserar ut till världen exakt vad den kör! Tråkigt nog är det fortfarande
många tillverkare som skeppar sina nya system med dessa typer av meddelanden och många admini-
stratörer stänger heller aldrig av dem. Bara för att det finns andra metoder för att avgöra
vilket OS som körs (såsom fingeravtryck) behöver det inte betyda att vi ska basunera ut vårt
OS och vår arkitektur till varje tönt som försöker koppla upp sig.

Problemet med att förlita sig på den här tekniken är att många väljer att stänga av sina
inloggningsmeddelanden, många system ger inte ut så mycket information och det är ganska lätt
för folk att "ljuga" i sina inloggningsmeddelanden. Hur som helst, läsning av inloggnings-
meddelanden för att ta reda på OS och OS version är allt du får om du spenderar tusentals
dollar på den kommersiella scannern ISS. Ladda ner nmap och queso istället och spara dina
pengar :).

Även om du slår inloggningsmeddelandet, så kommer fortfarande många applikationer att
gladeligen lämna ifrån sig den typen av information när den efterfrågas. Vi kan till exempel
ta oss en titt på en FTP server:

payfonez> telnet ftp.netscape.com 21
Trying 207.200.74.26 ...
Connected to ftp.netscape.com.
Escape character is '^]'.
220 ftp29 FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS

Först ger den oss detaljerad systeminformation i sitt inloggningsmeddelande. Sedan använder
vi kommandot 'SYST' och den ger oss gladeligen ännu mer information.

Om anonym FTP tillåts, så kan vi ofta ladda ner /bin/ls eller andra binärer och avgöra vilken
arkitektur de skapades för.

Många andra applikationer är också givmilda med information. Ta webb-servrar till exempel:

playground> echo 'GET / HTTP/1.0\n' | nc hotbot.com 80 | egrep '^Server:'
Server: Microsoft-IIS/4.0
playground>

Hmmm ... Undrar vilket OS de där töntarna kör.

Andra klassiska metoder inkluderar DNS system info poster (sällan effektivt) och social
engineering. Om maskinen lyssnar på 161/udp (snmp), så är du nästan garanterad en mängd
detaljerad information om du använder 'snmpwalk' från CMU SNMP tools distributionen och
'public' som community name.

NUVARANDE FINGERAVTRYCKSPROGRAM

Nmap är inte det första OS igenkänningsprogrammet som använder TCP/IP fingeravtryck.
Den vanliga IRC spoofern sirc av Johan har inkluderat en väldigt rudimentär fingeravtrycks-
teknik sen version 3 (eller tidigare). Den försöker placera ett system i någon av klasserna
"Linux", "4.4BSD", "Win95", eller "Unknown" genom att använda sig några simpla TCP flaggtest.

Ett annat sådant program är checkos, som släpptes i januari detta år av Shok i Confidence
Remains High Issue #7. Teknikerna för fingeravtryck är exakt de samma som för SIRC och koden
är till och med identisk på många ställen. Checkos användes länge enbart privat innan den
släpptes fri, så jag har inte en aning om vem som stal kod från vem. Men ingen verkar berömma
den andre. En sak som checkos lägger till är kontroll av telnets inloggningsmeddelande, som
är fullt användbart men har de problem som beskrevs tidigare. [ Uppdatering: Shok skrev att
checkos aldrig var tänkt att släppas fritt och det var anledningen till att han inte tackade
SIRC för delar av koden. ]

Su1d skrev också ett OS kontroll program. Hans heter SS och kan i version 3.11 identifiera
12 olika typer av OS. Jag är lite partisk till detta på grund av att han tackar mitt nmap
program för delar av nätverkskoden :).

Slutligen har vi queso. Detta program är det nyaste och det är ett stort kliv framåt jämfört
med de andra programmen. De introducerar inte bara några nya tester, men de var också först
(vad jag har sett) med att flytta OS fingeravtrycken utanför koden. De andra scannrarna
innehöll kod som kunde se ut så här:

/* from ss */
if ((flagsfour & TH_RST) && (flagsfour & TH_ACK) && (winfour == 0) &&
(flagsthree & TH_ACK))
reportos(argv[2],argv[3],"Livingston Portmaster ComOS");

Istället flyttar queso detta till en konfigurationsfil som givetvis medför bättre skalning
och gör det lika lätt att addera ett OS som det är att skriva in några rader i filen för
fingeravtryck.

Queso skrevs av Savage, en av bra människorna vid Apostols.org .

Ett problem med samtliga tidigare nämnda program är de är väldigt begränsade i antalet
kontroller av fingeravtryck. Detta medför att finkornigheten i svaren begränsas. Jag vill
veta mer än bara att 'den här maskinen är OpenBSD, FreeBSD, eller NetBSD', jag vill veta
exakt vilken av dessa det är och dessutom få tips om vilken version det kan vara. På samma
sätt vill jag hellre se 'Solaris 2.6' än bara 'Solaris'. För att erhålla denna finkornighet
i svaren använder jag mig av ett antal tekniker för fingeravtryck, som beskrivs i nästa
avsnitt.

METODOLOGI FÖR FINGERAVTRYCK

Det finns många olika tekniker som kan användas för hitta fingeravtryck för nätverksstackar.
Det börjar alltid med att du tittar på vilka skillnader som finns mellan olika operativsystem
och skriver en programsnutt som letar efter denna skillnad. Om du kombinerar tillräckligt
många sådana, så kan du begränsa svaret innehållande OS väldigt hårt. Nmap kan till exempel
med säkerhet skilja på Solaris 2.4 och Solaris 2.5-2.51 och Solaris 2.6. Det kan också skilja
på Linux kärna 2.0.30 från 2.0.31-34 eller 2.0.35. Här är några tekniker:

FIN probe -- Här skickar vi ett FIN paket (eller vilket paket som helst utan att sätta ACK
eller SYN flaggan) till en öppen port och väntar på ett svar. Korrekta sättet
enligt RFC793 är att INTE svara, men många trasiga implementationer som till
exempel MS Windows, BSDI, CISCO, HP/UX, MVS, och IRIX skickar tillbaka en RESET.
De flesta nuvarande verktyg använder sig av den här tekniken.

BOGUS flag probe -- Queso är den första scanner jag har sett använda detta smarta test.
Idén är att sätta en odefinierad TCP "flagga" (64 eller 128) i huvudet
för TCP på ett SYN paket. Linux maskiner före 2.0.35 behåller flaggan
satt i sina svar. Jag har inte lyckats hitta något annat OS som har detta
fel. Vissa operativsystem verkar dock vilja skicka reset för uppkopplingen
när de får ett SYN+BOGUS paket. Detta beteende kan vara användbart när
man ska identifiera dem.

TCP ISN Prover -- Idén bakom den här är att försöka hitta mönster i det initiala sekvensnumret
som väljs av TCP implementationen när de svarar på ett uppkopplingsförsök.
Dessa kan kategoriseras i många grupper som till exempel den traditionella
64K (många gamla UNIX-burkar), Slumpmässiga ökningar (Nyare versioner av
Solaris, IRIX, FreeBSD, Digital UNIX, Cray, och många andra), äkta
"slumpmässighet" (Linux 2.0.*, OpenVMS, nyare AIX, etc). Windows burkar
använder sig av en "tidsberoende" modell där ISN ökas med ett litet fast
tal varje tidsperiod. Det är väl överflödigt att påpeka att detta är lika
lätt att lista ut som det gamla 64K beteendet. Sen har vi givetvis min
favorit "konstant". Maskinen använder alltid samma ISN :). Jag har sett
detta på vissa 3Com hubbar (de använder 0x803) och Apple Laserwriter
skrivare (de använder 0xC7001).

Du kan också göra subklasser av grupper såsom slumpmässiga ökningar genom
att räkna ut variationer, största gemensamma nämnare, och andra funktioner
på de olika sekvensnumren och skillnaderna mellan dessa nummer.

Det bör noteras att ISN genereringen har viktiga säkerhetsaspekter. För mer
information om detta, kontakta "säkerhetsexperten" Tsutomu "Shimmy" Shimomura
vid SDSC och fråga honom hur han utnyttjades. Nmap är det första programmet
jag har sett som använder detta för OS identifiering.

Don't Fragment bit -- Många operativsystem har börjat sätta IP biten "Ingen fragmentering" på
vissa paket som sänds. Detta ger diverse förbättringar i prestanda (även
om det också kan vara enerverande -- det är därför nmaps fragmenterings-
scanningar inte fungerar från Solaris burkar). Hur som helst, det är inte
alla OS som gör det och vissa gör det i olika fall, så genom att studera
detta kan vi komma åt ytterligare information om målets OS. Jag har inte
sett detta anändas tidigare heller.

TCP initial window -- Detta innebär helt enkelt att vi tittar på fönsterstorlek på returnerade
paket. äldre scanners använde helt enkelt icke-noll fönster på ett RST
paket till att betyda "BSD 4.4 derivering". Nyare scanners som till
exempel queso och nmap spårar den exakta fönsterstorleken på grund av att
den är ganska konstant för respektive OS typ. Det här testet ger oss
mycket information eftersom vissa operativsystem unikt kan identifieras
av enbart fönstret (till exempel, AIX är det enda OS jag har sett som
använder 0x3F25). I deras "helt omskrivna" TCP stack för NT5, anänder
Microsoft 0x402E. Intressant är att det råkar vara exakt samma tal som
används av OpenBSD och FreeBSD.

ACK Value -- Även om du tror att detta är en standard, så varierar värdet som används i ACK
fältet mellan olika implementationer. Låt oss säga att du skickar ett paket med
FIN|PSH|URG till en stängd TCP port. De flesta implementationer kommer att sätta
ACK till att vara samma som ditt initiala sekvensnummer, men Windows och några
dumma skrivare kommer att sända ditt sqe + 1. Om du skickar ett paket innehållande
SYN|FIN|URG|PSH till en öppen port, så beter sig Windows väldigt konstigt. Ibland
skickar den tillbaka din seq, men ibland skickar den tillbaka S++ och vid vissa
tillfällen skickar den tillbaka ett till synes slumpmässigt tal. Det här får en
att undra över vilken kod MS egentligen skriver som ändrar sig på detta sätt.

ICMP Error Message Quenching -- Vissa (smarta) operativsystem följer förslaget i RFC 1812 om
att begränsa antalet felmeddelanden som sänds. Linux kärnan
(i net/ipv4/icmp.h) begränsar meddelandet destination unreachable
till max 80 per sekund, med en 1/4 sekunds straff om detta
överksrids. Ett sätt att testa detta är att skicka ett gäng paket
till en slumpmässig hög UDP port och räkna hur många felmeddelanden
det blir. Jag har inte sett detta användas tidigare och faktum
är att jag inte använder det i nmap (förutom i UDP port scanningen).
Detta test skulle göra att OS detekteringen skulle ta längre tid
eftersom du skulle bli tvungen att sända ett gäng paket och sedan
vänta tills de kommer tillbaka. Att ta hand om problemet med att
vissa paket kanske förloras i nätverket skulle också bli jobbigt.

ICMP Message Quoting -- I RFC beskrivs att ICMP felmeddelanden ska citera en liten del av ett ICMP
meddelande som orsakar felet. För felmeddelandet port unreachable, skickar
de allra flesta implementationer enbart tillbaka det erforderliga IP-huvudet
+ 8 bytes. Men Solaris skickar tillbaka lite mer och Linux skickar tillbaka
ännu mer. Det fina i kråksången är att detta tillåter nmap att känna igen
både Linux och Solaris även om de inte lyssnar på några portar.

ICMP Error message echoing integrity -- Den här idén fick jag från något som Theo De Raadt
(ledande OpenBSD utvecklare) postade i gruppen
comp.security.unix. Som jag nämnde tidigare så måste system
skicka tillbaka delar av ditt ursprungliga meddelande
tillsammans med ett felmeddelande om att porten inte gick att nå.
Men det finns en del system som verkar använda dina huvuden
som "arbetsyta" under den initiala behandlingen och därför är
de lite förändrade när du får tillbaka dem. Till exempel
AIX och BSDI skickar tillbaka fältet IP 'total storlek' som
är 20 bytes för högt. Vissa BSDI, FreeBSD, OpenBSD, ULTRIX
och VAXen förstör IP ID som du skickade dem. även om
checksumman kommer att ändras på grund av ändrad TTL ändå,
så finns det trots det vissa system (AIX, FreeBSD, etc.) som
skickar tillbaka ett inkonsekvent nummer eller 0 som checksumma.
Samma sak gäller för UDPs checksumma. Allt som allt gör nmap
nio olika kontroller på ICMP felen för att luska rätt på
subtila skillnader som dessa.

Type of Service -- För felet från ICMP att porten inte gick att nå tittar jag tillbaka på
typ av service (TOS) värdet för paketet som skickades tillbaka. Nästan
alla implementationer använder 0 för detta ICMP fel även om Linux använder
0XC0. Detta är inte en indikation på ett TOS värde, utan istället är det
en del av det oanvända (AFAIK) ordningsföljd fältet. Jag vet inte varför
detta sätts, men om de ändrar det till 0 så kan vi fortsätta att identifiera
gamla versioner och vi kan skilja på gamla och nya.

Hantering av fragmentering -- Detta är favorittekniken för H. Ptacek från Secure Networks, Inc
(Numera ägt av en grupp Windows användare vid NAI). Det här tar
hänsyn till att olika implementationer ofta hanterar överlappande
IP fragment på olika sätt. Vissa skriver över de gamla med nya,
och i andra fall har det gamla sättet företräde. Det finns många
olika sätt att avgöra hur paketet blev ihopplockat. Jag adderade
inte denna funktion på grund av att jag inte känner till något sätt
att få porterbar kod som sänder IP fragment (i Solaris är det riktigt
svårt). För mer information om överlappande fragment kan du läsa deras
IDS dokument (www.secnet.com).

TCP optioner -- Det här är en riktig guldgruva, när det gäller att läcka information. Skönheten
med dessa är att:
1) De behöver för det mesta inte vara med (öhh!) :) så alla system implementerar
inte dem.
2) Du vet om ett system har implementerat dem genom att skicka en fråga med en
option satt. Målmaskinen visar vanligtvis att det finns support genom att
sätta flaggan i svaret.
3) Du kan sätta massor med optioner i ett och samma paket för att testa alla på
samma gång.

Nmap skickar med dessa optioner med nästan alla testpaket:

Window Scale=10; NOP; Max Segment Size = 265; Timestamp; End of Ops;

När du får tillbaka ditt svar tar du dig en titt på vilka optioner som
returnerades och därför också supportades. Vissa operativsystem som till
exempel nyare FreeBSD system har support för alla optioner, emedan andra
som till exempel Linux 2.0.X har support för endast ett fåtal. De senaste
Linux 2.1.x kärnorna har support för alla optioner. Men å andra sidan är
de mycket mer sårbara för att gissa sekvensnummer i TCP. Tänk själv.

Även om många system har support för samma optioner så kan du ibland
skilja dem åt genom att titta på värdet på optionerna. Till exempel, om
du skickar ett litet MSS värde till ett Linux system så kommer det
vanligtvis att skicka tillbaka samma MSS till dig. Andra system ger
andra värden.

Och även om de har support för samma optioner OCH returnerar samma värden,
så kan du fortfarande skilja dem åt genom att titta på i vilken ordning
optionerna kommer och var någonstans utfyllnad används. Till exempel
Solaris returnerar 'NNTNWME' som betyder:
<no op><no op><timestamp><no op><window scale><echoed MSS>

Men Linux 2.1.122 returnerar MENNTNW. Samma optioner, samma värden,
men en annan ordning!

Jag har inte sett något annat verktyg för OS detektering som använder TCP
optioner, men det är väldigt användbart.

Det finns en del andra användbara optioner som jag kanske kommer att testa
på vid tillfälle, som till exempel de som har support för T/TCP och
selektiva bekräftelser.

Kronologi för utnyttjande -- Trots alla tester beskrivna ovan kan inte nmap skilja på TCP stacken i
i Win95, WinNT eller Win98. Detta är ganska förvånande, speciellt med
tanke på att Win98 kom ut ungefär 4 år efter Win95. Man skulle kunna
tro att de hade förbättrat sin stack på något sätt (som att erbjuda
support för fler TCP optioner) så att vi också skulle kunna upptäcka
skillnaderna och därigenom också skilja på operativsystemen. Så är
olyckligt nog inte fallet. NT stacken är precis samma skit stack som
de hade i '95. Och de brydde sig inte om att uppgradera den till '98.

Men ge inte upp hoppet, för det finns en lösning. Du kan använda dig
av de tidiga Windows DOS attackerna (Ping of Death, Winnuke, etc) och
stega dig uppåt en bit till Teardrop och Land. Efter varje attack, kan
du pinga dem och se efter om de har kraschat. När du slutligen har
kraschat dem, så kommer du sannerligen kunna gissa vad de kör ner
till vilket service pack och vilken hotfix.

Jag har inte lagt till denna funktionalitet även om jag medger att det
är väldigt frestande :).

SYN Flood Motstånd -- Vissa operativsystem slutar att acceptera nya uppkopplingar om du skickar för
många falska SYN paket till dem (falska paket gör att du undviker problem med
att din kernel stänger ner uppkopplingarna). Många operativsystem kan bara
hantera 8 paket. Nyare Linux kärnor (bland andra operativsystem) tillåter
olika metoder som till exempel SYN cookies för att undvika detta problem.
Detta innebär att du kan lära dig en del om målets OS genom att skicka 8 paket
från en falsk källa till en öppen port och sedan se om du kan koppla upp dig
mot den porten. Detta är inte implementerat i nmap eftersom vissa personer
kan bli uppretade om du gör en SYN flood mot dem. även om du försöker förklara
att du bara ville ta reda på vilket OS de kör så kommer det troligtvis inte
att lugna ner dem.

NMAP IMPLEMENTATION OCH RESULTAT

Jag har skapat en referens implementation av de OS detekteringstekniker som nämnts ovan
(förutom de som inte är inkluderade). Jag har lagt till detta till min Nmap scanner, vilket
får den fördelen att den redan vet vilka portar som är öppna och stängda för att ta
fingeravtryck, så du behöver aldrig ange det. Det är också porterbart mellan Linux, *BSD,
och Solaris 2.51 och 2.6 och även en del andra operativsystem.

Den nya versionen av nmap läser en fil som är full med fingeravtrycks mallar som följer en
simpel uppställning. Här är ett exempel:

FingerPrint IRIX 6.2 - 6.4 # Thanks to Lamont Granquist
TSeq(Class=i800)
T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)
T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)
T3(Resp=Y%DF=N%W=C000|EF2A%ACK=O%Flags=A%Ops=NNT)
T4(DF=N%W=0%ACK=O%Flags=R%Ops=)
T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)
PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Låt oss ta en titt på första raden (Jag lägger till '>' citat tecken):

> FingerPrint IRIX 6.2 - 6.3 # Thanks to Lamont Granquist

Den här raden talar helt enkelt om att fingeravtrycket täcker IRIX version 6.2 till och med
6.3 och kommentaren talar bara om att Lamont Granquist snällt nog skickade mig IP-adressen
eller fingeravtrycket till de IRIX system som testades.

> TSeq(Class=i800)

Det här betyder att ISN prover placeras i klassen "i800". Det betyder att varje ny ISN är en
ökning på 800 jämfört med den tidigare.

> T1(DF=N%W=C000|EF2A%ACK=S++%Flags=AS%Ops=MNWNNT)

Det här testet heter T1 (för test1, klokt eller hur?). I detta test skickar vi ett SYN paket
med en massa TCP optioner satta till en öppen port. DF=N betyder att "Fragmentera inte" biten
i svaret inte ska sättas. W=C000|EF2A betyder att fönsterstorleken som aviseras måste vara
antingen 0XC000 eller 0XEF2A. ACK=S++ betyder att bekräftelsen som vi får tillbaka måste vara
vårt initiala sekvensnummer plus 1. Flags = AS betyder att ACK och SYN flaggorna skickades i
svaret. Ops = MNWNNT betyder att optioner i svaret måste vara (i denna ordning):

> T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=)

Test 2 involverar ett NULL med samma optioner till en öppen port. Resp=Y betyder att vi måste
få ett svar. Ops= betyder att inga optioner får vara inkluderade i svaret. Om vi hade tagit
bort '%Ops=' helt och hållet så skulle optioner som vi skickade matcha.

> T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AS%Ops=M)

Test 3 är en SYN|FIN|URG|PSH med optioner till en öppen port.

> T4(DF=N%W=0%ACK=O%Flags=R%Ops=)

Det här ett ACK till en öppen port. Notera att vi inte har satt Resp= här. Det betyder
att om svar inte ges (till exempel ett paket som slängs på nätverket eller av en elak
brandvägg) inte glöms bort så länge de andra testerna matchar. Vi gör så här för att
nästan alla OS kommer att skicka ett svar, så ett borttappat svar beror troligtvis på
nätverksgrejer och inte på operativsystemet. Vi sätter Resp flaggan i test 2 och 3 för
att vissa operativsystem slänger dessa utan att svara.

> T5(DF=N%W=0%ACK=S++%Flags=AR%Ops=)
> T6(DF=N%W=0%ACK=O%Flags=R%Ops=)
> T7(DF=N%W=0%ACK=S%Flags=AR%Ops=)

De här testerna är SYN, ACK och FIN|PSH|URG var för sig till en stängd port. Samma
optioner sätts alltid. Detta är givetvis ganska uppenbart med tanke på de deskriptiva
namnen 'T5', 'T6' och 'T7' :).

> PU(DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Den här stora busen är ett test av meddelandet 'port unreachable'. Du borde känna igen
DF=N nu. TOS=0 betyder att IP typen av service fältet var 0. Nästa två fält ger (hex)
värdet av den totala IP längden av IP meddelandets huvud och den totala längden i IP
huvudet som ekas tillbaka till oss. RID=E betyder att RID värdet vi fick tillbaka i
kopian av vårt ursprungliga UDP paket var väntat (med andra ord samma som vi skickade).
RIPCK=E betyder att de inte sabbade checksumman (om de hade gjort det skulle det ha stått
RIPCK=F). UCK=E betyder att UDP checksumman också är korrekt. Sen kommer UDP längden som
var 0X134 och DAT=E betyder att de ekade våra UDP data riktigt. Eftersom de flesta
implementationer (inklusive den här) inte skickar tillbaka någon UDP data, så får de också
alltid DAT=E.

Versionen av nmap med denna funktionalitet är för tillfället i sjätte privata beta cykeln.
Den kanske är ute när du läser om detta i Phrack. Men å andra sidan kanske inte. Kolla på
http://nmap.org/ för den senaste versionen.

POPULÄRA ÖGONBLICKSBILDER FRÅN PLATSER

Här kommer det roliga resultatet från våra ansträngingar. Vi kan numera ta en slumpvist
utvald Internet plats och bestämma vilket OS de kör. Många av dessa personer har tagit
bort telnets inloggningsmeddelanden etc. för att hålla denna information privat. Men
det hjälper inte mot våran nya fingeravtryckläsare! Detta är också ett bra sätt att
exponera dina användare vilka förlorare de är :)!

Kommandot som användes i dessa exempel var: nmap -sS -p 80 -O -v

Notera också att de flest av dessa scanningar gjordes 1998-10-18. Vissa av dessa personer
kan ha uppgraderat/ändrat system sedan dess.

Det är inte så att jag inte tycker om de platser som listas här.

# "Hacker" platser eller (i vissa fall) de som tror att de är det
www.l0pht.com => OpenBSD 2.2 - 2.4
insecure.org => Linux 2.0.31-34
www.rhino9.ml.org => Windows 95/NT # Ingen kommentar :)
www.technotronic.com => Linux 2.0.31-34
www.nmrc.org => FreeBSD 2.2.6 - 3.0
www.cultdeadcow.com => OpenBSD 2.2 - 2.4
www.kevinmitnick.com => Linux 2.0.31-34 # Befria Kevin!
www.2600.com => FreeBSD 2.2.6 - 3.0 Beta
www.antionline.com => FreeBSD 2.2.6 - 3.0 Beta
www.rootshell.com => Linux 2.0.35 # ändrade till OpenBSD efter
# att de köptes upp.

# Säkerhetsföretag, konsulter etc.
www.repsec.com => Linux 2.0.35
www.iss.net => Linux 2.0.31-34
www.checkpoint.com => Solaris 2.5 - 2.51
www.infowar.com => Win95/NT

# Tillverkare lojalitet mot sitt OS
www.li.org => Linux 2.0.35 # Linux International
www.redhat.com =>> Linux 2.0.31-34 # Jag undrar vilken distribution :)
www.debian.org => Linux 2.0.35
www.linux.org => Linux 2.1.122 - 2.1.126
www.sgi.com => IRIX 6.2 - 6.4
www.netbsd.org => NetBSD 1.3X
www.openbsd.org => Solaris 2.6 # Hmm :) (det är bara för att UAlberta
# äger uppkopplingen)
www.freebsd.org => FreeBSD 2.2.6-3.0 Beta

# Plugg ligan
www.harvard.edu => Solaris 2.6
www.yale.edu => Solaris 2.5 - 2.51
www.caltech.edu => SunOS 4.1.2-4.1.4 # Hallå! Det här är nittiotalet :)
www.stanford.edu => Solaris 2.6
www.mit.edu => Solaris 2.5 - 2.51 # Sammanträffande att så många bra
# skolor verkar gilla Sun?
# Kanske beror på den 40%
# .edu rabatten :)
www.berkeley.edu => UNIX OSF1 V 4.0,4.0B,4.0D
www.oxford.edu => Linux 2.0.33-34 # Rocka på!

# Förlorarnas platser
www.aol.com => IRIX 6.2 - 6.4 # Inte konstigt att de är så osäkra :)
www.happyhacker.org => OpenBSD 2.2-2.4 # Trött på att vara köpt, Carolyn?
# även det säkraste OS är
# oanvändbart i händerna på en
# inkompetent admin.

# Blandat
www.lwn.net => Linux 2.0.31-34 # Den här Linux platsen rockar!
www.slashdot.org => Linux 2.1.122 - 2.1.126
www.whitehouse.gov => IRIX 5.3
sunsite.unc.edu => Solaris 2.6

Kommentarer: I sitt säkerhetsdokument så säger Microsoft följande om sin
bristande säkerhet: "detta antagande har förändrats över åren eftersom
Windows NT blir mer och mer populärt på grund av sina säkerhetsfunktioner.
Hmm, av vad jag kan utläsa verkar det inte som om Windows är särskilt
populärt bland säkerhetsfolket :). Jag kan bara se 2 Windows system i hela
gruppen och Windows är enkelt för nmap att skilja ut eftersom det är så
trasigt (med avseende på standarder).

Och givetvis finns det en till plats vi måste kolla. Det är webb-platsen
för det ultra-säkra Transmeta företaget. Intressant nog grundades företaget
av Paul Allen från Microsoft, men de har anställt Linus Torvalds. Så följer
de Paul och kör NT eller huserar de med rebellerna och ansluter till Linux-
revolutionen? Låt oss se:

Vi använder kommandot:

nmap -sS -F -o transmeta.log -v -O www.transmeta.com//24

Detta säger att vi ska SYN scanna efter kända portar (från /etc/services), logga
resultatet till 'transmeta.log', ge mycket output, scanna efter OS och scanna
klass 'C' som www.transmeta.com finns på. Här är ett utdrag från resultaten:

neon-best.transmeta.com (206.184.214.10) => Linux 2.0.33-34
www.transmeta.com (206.184.214.11) => Linux 2.0.30
neosilicon.transmeta.com (206.184.214.14) => Linux 2.0.33-34
ssl.transmeta.com (206.184.214.15) => Linux unknown version
linux.kernel.org (206.184.214.34) => Linux 2.0.35
www.linuxbase.org (206.184.214.35) => Linux 2.0.35 ( possibly the same machine as above )

Ja, jag tror att svaret på vår fråga är ganska givet :).

TACK TILL

Den enda anledningen till att Nmap för tillfället kan upptäcka så många olika
operativsystem är för att många människor i det privata beta teamet lade ner
mycket möda på att söka efter nya intressanta system att ta fingeravtryck på!
Särskilt Jan Koum, van Hauser, Dmess0r, David O'Brien, James W. Abendschan,
Solar Designer, Chris Wilson, Stuart Stock, Mea Culpa, Lamont Granquist,
Dr. Who, Jordan Ritter, Brett Eldridge, and Pluvius skickade in tonvis med
IP adresser på konstiga system och/eller fingeravtryck på system som inte
gick att nå via Internet.

Tack till Richard Stallman för att du skrev GNU Emacs. Den här artikeln skulle
inte vara så väl radbruten om jag hade använt vi eller cat och ^D.

Frågor och kommentarer kan skickas till fyodor@insecure.org. Nmap kan hämtas
från http://insecure.org/nmap.