Minun viimeinen viesti puhuin idle scan ja miten se voi sallia hyökkääjän peittää heidän IP-osoitetta Porttiskannausten. Tässä erässä me tarkastelemme joitakin jälkiä, sekä keskustella siitä, miten tunnistaa kun idle scan on käytetty vastaan verkkoon.
Valvonta IP ID lisäys
Aloitetaan tarkastelemalla paketit olivat seuranta IP kenttään Windows-järjestelmässä. Tässä on mitä koetin paketti näytti:
07:22:15.367140 IP (tos 0 × 0, TTL 64, id 63897, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.1.2203> 192.168.100.2.0:., Cksum 0xeca2 (oikea), voittaa 512
Muutama näistä kentistä on sellainen mielenkiintoinen. TTL arvo on "64", mikä viittaa Linuxissa tai Unixissa. Koska olemme raaka kirjallisesti paketin suoraan lanka tämä arvo on todellisuudessa ohjaa hping. 64 vain sattuvat olemaan ohjelman oletusarvo, mutta voisimme muuttaa arvoa mihinkään haluamme kanssa "-t" kytkin.
Kohdeosoite tulostetaan "192.168.100.2.0", mikä tarkoittaa paketti lähetettiin TCP-porttiin 0 klo IP-osoite 192.168.100.2. Windows ei tarjoa palveluja TCP portti 0, mutta se on ok. Emme oikeastaan yrittää muodostaa yhteyden Windows-järjestelmän. Meidän täytyy vain se lähettää meille IP-paketti, jotta voimme tarkistaa IP ID arvo. Jos halusimme lyödä eri portti, voisimme käyttää hping n "-p" kytkin.
"." Jälkeen kohdespesifikaatio tarkoittaa sitä, ettei TCP lippuja asetettiin sisällä paketin. Tämä kutsutaan null paketti ja voisi koskaan tapahtua normaalin IP-viestintään. Tästä syystä voi nids, maaohjelmat ja palomuurit lippu sitä. Loimme null packet koska emme kerro hping Lähetettävät tahansa TCP lippuja. Esimerkiksi lisäämällä "-S" kytkin olisi kytketty päälle SYN lippu "-" kääntyisi siitä tunnustus lippu, ja niin edelleen.
Kaikki koetinpaketteja Windows-järjestelmät näyttävät samanlaisilta kuin tämä yksi. Vain arvoja, jotka muuttaisivat ovat aikaleima (ilmeisesti), TCP lähdeportin ja CRC tarkistussumma.
Tässä mitä vastauksista näyttävät palaamassa Windows järjestelmään:
07:22:15.367296 IP (tos 0 × 0, ttl 128, id 108, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.0> 192.168.100.1.2203: R, cksum 0xc431 (oikea), 0:00 (0) ack 918250228 voittaa 0
07:22:16.367453 IP (tos 0 × 0, ttl 128, id 109, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.0> 192.168.100.1.2204: R, cksum 0xfa78 (oikea), 0:00 (0) ack 2127488152 voittaa 0
07:22:17.367763 IP (tos 0 × 0, ttl 128, id 110, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.0> 192.168.100.1.2205: R, cksum 0x2b9f (oikea), 0:00 (0) ack 1611256374 voittaa 0
Tärkeä arvo tässä on IP ID, on luokiteltu "id". Ensimmäisessä paketti on asetettu 108, ja sitten arvon askelin +1 kutakin seuraava paketti (109 sitten 110). Niin kauan kuin jatkamme nähdä keskeytyksettä sekvenssi IP ID, tiedämme Windows-järjestelmä ei lähetä muita paketteja, paitsi ne, jotka ovat osa tätä istuntoa.
Hyvää suljettu portti
Muista, että Osana skannata, olemme vedätys lähde IP-osoite Windows-järjestelmän, kun tavoite porttien etäjärjestelmän. Muutos IP ID lisäys on mitä kertoo meille löysimme avoimen portin.
Otetaan katsele yhtä näistä voi paketteja:
10:30:28.852602 IP (tos 0 × 0, TTL 64, id 41256, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.1266> 192.168.100.3.79: S, cksum 0x97a6 (oikea), 1704542340:1704542340 (0) voittaa 512
Huomaa lähde IP osoite on se, että Windows-järjestelmän (192.168.100.2). Tiedämme tämän ei olisi voinut tulla Windowsin kuitenkin koska TTL on asetettu 64. Joten tämä on paketti meillä syntyvät 192.168.100.1 käyttäen toinen esiintymä hping.
Huomaa myös meillä on kohdistettu TCP-portin 79 ja käynnistänyt SYN lippua. Tässä on vastaus saimme kauko tavoite:
10:30:28.852839 IP (tos 0 × 0, TTL 64, id 0, offset 0, flags [DF], proto TCP (6), pituus 40) 192.168.100.3.79> 192.168.100.2.1266: R, cksum 0xbb1a (oikea), 0:00 (0) ack 1704542341 voittaa 0
Huomaa "R" arvo, joka kertoo meille reset lippu oli päällä TCP-otsikon. Näemme myös "ACK", joka kertoo meille tunnustus lippu oli päällä myös. Tämä on virhe paketti ilmoittaa lähde, että TCP-portti on suljettu tila. Huomaa myös paketti siirretään Windows-järjestelmässä, koska se oli lähde IP osoite anturi paketin.
Joten miten Windows-järjestelmän vastata? Saatat muistan Uusin viesti että RFC valtion sinun ei pitäisi koskaan vastata virheen paketin. Vaikka Windows-järjestelmän ei ole aavistustakaan, mitä tavoite puhuu, se hiljaa hävittää tämän virheen paketin. Toisin sanoen, Windows-järjestelmä ei lähetä vastausta. Tämä tarkoittaa meidän pitäisi nähdä mitään muutosta IP ID lisäyksen.
Luotaa avoin portti
Nyt katsomaan mitä tapahtuu, kun kohde portti on todella avoin tila. Tässä koetin paketti. Huomautus On melko samanlainen kuin edellinen, paitsi nyt meillä on tarkistaa TCP-portin 80.
10:29:46.947964 IP (tos 0 × 0, TTL 64, id 15249, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (oikea), 947341260:947341260 (0) voittaa 512
Tässä on vastaus tavoite. Huomaa, että näemme "S" sijaan "R" eli ne SYN lippu on päällä eikä reset lippua. Tämä on tavoitteita tapa tiedottaa lähteen että TCP-portti 80 on avoin ja on sovellus istuu sen takana huolto yhteyksiä.
10:29:46.953333 IP (tos 0 × 0, TTL 64, id 0, offset 0, flags [DF], proto TCP (6), pituus 44) 192.168.100.3.80> 192.168.100.2.1984: S, cksum 0x0de6 (oikea), 262246932:262246932 (0) ack 947341261 voittaa 5840 <mss 1460>
Joten tällä kertaa Windowsin vastaanottaa paketin sanonta "Toki voit liittää TCP-porttiin 80". Tämä on ongelma Windows-järjestelmän, koska se ei liity merkinnän sanomalla, että se todella yrittäessä muodostaa porttia 80 tavoite. Ilman yhteys merkintä, Windows ei voi tietää mikä sovellus pyysi istunnossa. Tässä mielessä, se ainoa asia, se voi tehdä, lähettää kuittaus paketin kohde tappaminen istuntoon. Tässä on mitä paketti näytti:
10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (oikea), 947341261:947341261 (0) win 0
Huomaa, että Windows leimattu seuraavaan käytettävissä IP-tunnuksen IP-otsikko (176). Joten olisimme seuranneet IP ID kasvu on Windows-järjestelmän eri istunnon näkisimme: 173, 174, 175, 177, 178, 179. Toisin sanoen olisimme nähneet, että 176 oli kateissa (+2 edelliseen paketti). Tämä olisi meidän osoitus siitä TCP/80 luotain lähetettiin tavoite osuma avoin portti.
Tunnistaminen idle scan
Joten idle scan tekee erinomaista työtä peittää todellisen lähteen IP osoite Porttiskannausten. Tämä tarkoittaa, että ei ole mahdollisuutta kirjata tietoa Windows isäntä (ja tämä ei ole olemassa, jos hyökkäys on tehnyt kotiläksynsä), emme koskaan voi löytää todellinen lähde IP-osoite hyökkäyksen.
Onko tapa kertoa idle scan tehtiin sijaan suoraan eteenpäin Porttiskannausten joten emme tiedä, onko se kannattaa tutkia lähde IP osoite? On itse asiassa pari vihjeitä voimme etsiä.
Probe retries
Jos tavoitteeksi asetettua järjestelmä istuu palomuurin takana, huomaat eron määrä koetin retries vs. normaali portti skanneri. Kun joku kulkee normaali portti skanneri, skanneri tyypillisesti osuma avaamaan portteja vain kerran vaan palomuurin porttien useita kertoja. Tämä johtuu palomuurin portit palauta yhtään vastausta. Skanneri tekee useita yrityksiä varmistamaan paketteja ei juuri menetetty. Koska avoin portti todella vastata vain yksi anturi paketti tarvitaan.
Kun tyhjäkäynnillä skannaus suoritetaan, on päinvastainen. Jos palomuurin portti on kysyneet ei tule IP ID lisäys muuttaa Windows-järjestelmässä. Joten vain yksi tarkistus pyydetään vahvistamaan tämä ei ole aktiivinen kuuntelu portti. Kun avoin portti on kysyneet kuitenkin me havaita muutoksia Windows-järjestelmän IP-ID lisäys. Mielestämme tämä johtuu meitä löytämään avaa portti, se voisi yhtä todennäköisesti, koska Windows-järjestelmän lähetti lähetystä. Joten me haluamme tehdä useita antureita vastaan avata portti jotta Windows IP ID data pysyy vakiona.
Joten:
- Probe palomuurin portit useammin kuin avoimet portit = normaali portti skanneri
- Probe avoimet portit useammin, että palomuurin portit = idle scan
Ajoitus
Normaali porttiskannaukset olla erittäin nopea. Ei ole harvinaista nähdä satoja koetinpaketteja sekunnissa. Kanssa idle scan meidän on kuitenkin ottaa asiat hieman hitaampi. Tämä johtuu meidän täytyy tarkistaa IP-tunnus väärennetty osoite, lähettää luotain paketin, salli tarpeeksi aikaa koetin tekisivät vastauksen, anna väärennetty järjestelmä riittävästi aikaa vastata reset tarvittaessa (siis käyttää enintään IP tunnus ), ja tarkista sitten IP ID uudelleen, onko lisäys on muuttunut.
Yritä suorittaa kaikki nämä vaiheet liian nopeasti, ja maksat hinnan tarkkuuteen. Esimerkiksi nmap tukee tyhjäkäynnillä skannaa kanssa "SI" kytkin. Oletuksena erittäin nopea skannaus toimii hyvin, jos kaikki ovat samassa kytketty verkkoon. Jos isännät ovat 15 humalan poispäin toisistaan Internetissä kuitenkin kokemukseni on tarkkuus rating putoaa huomattavasti, ellet hidastaa skannausnopeus.
Joten:
- Sadat pakettia sekunnissa = normaali portti skanneri
- Kymmenkunta vähemmän pakettia sekunnissa = mahdollista idle scan, voisi vain olla hidas skannaus
TTL kenttä
Katsotaanpa uudelleen väärennetty anturi paketin sekä laillista nollata vastaus lähetetään Windows-järjestelmän:
10:29:46.947964 IP (tos 0 × 0, TTL 64, id 15249, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.1984> 192.168.100.3.80: S, cksum 0x476b (oikea), 947341260:947341260 (0) voittaa 512
10:29:46.953439 IP (tos 0 × 0, ttl 128, id 176, offset 0, flags [none], proto TCP (6), pituus 40) 192.168.100.2.1984> 192.168.100.3.80: R, cksum 0x5df1 (oikea), 947341261:947341261 (0) win 0
Olet ehkä huomannut TTLS ovat kaukana toisistaan. Jos molemmat paketit olivat itse asiassa peräisin 192.168.200.2 sitten he molemmat ovat samat alkaen TTL arvo. Se, että he ovat erilaisia kertoo, että yksi niistä on väärennetty.
Jos seuraamme kehä kohdejärjestelmän ja huomaa, että SYN-ja reset-paketteja on eri TTL-arvot, jotka on vihje siitä, että kyseessä saattaa olla käyttämättömänä skannata. Nyt, kuten aiemmin mainittiin, on täysin mahdollista asettaa TTL mitä ikinä haluamme meidän väärennetty paketti. Joten älykäs hyökkääjä ei yksinkertaisesti tule asettaa niiden alkaen TTL 128 paremmin matkia Windows-järjestelmän. Jos he tee näin, ainoa toivo on, että hyökkääjä ja Windows-järjestelmän on eri määrä humalaa pois. Toisin sanoen, jos jatkuvasti nähdä SYN paketteja TTL 115, mutta palautuu aina on TTL 113, olet todennäköisesti katsot tyhjäkäynnillä skannata.
Jos TTLS tehdä ottelun, emme voi täysin sulkea pois käyttämättömänä skannata. Hyökkääjä voi vain olla, että hyvä.
Joten:
- TTLS on SYNs ja RSTs ovat johdonmukaisia, mutta eivät täsmää = idle scan
- TTLS on SYNs ja RSTs ottelu = normaali portti skanneri tai Smart vapaa skanneri
IP ID arvo
Paras tapa tag idle scan on hyödyntää samaa hyökkääjä käyttää, eli IP ID arvo. Katsomaan uudelleen noita kaksi viimeistä puretussa paketteja. Huomaa, että IP-tunnuksen ensimmäinen on 15249, mutta toisessa se on 176. Jos näet tyhjäkäynnillä skannaus, huomaat loput paketit johdonmukaisesti ovat IP tunnus +2 (sama asia hyökkääjä näkee), mutta SYN paketteja on joitakin liity mitenkään arvoa. IP ID lisäyksen SYN paketteja voi olla ennustettavissa tai se voi olla satunnainen. Rehellisesti sanottuna se ei ole väliä. Mitä väliä on, että voit paikalla joitakin kuvio IP ID lopusta paketteja, jotka eivät jive kanssa IP tunnuksia SYN paketteja.
Joten:
- IP-tunnus SYN ja RST-paketteja näyttävät liittyvän = normaali portti skanneri
- IP ID väliksi RST ei vastaa SYNs = idle scan
Exec Yhteenveto
Toivottavasti sinulla on nyt parempi käsitys mitä tapahtuu langan kun hyökkääjä tekee tyhjäkäynnillä skannata. Jos me kohdistettuja idle scan, emme voi määrittää todellinen lähde IP osoite hyökkääjä. Parasta, mitä voimme toivoa saavuttaa on todeta, että skannaus on tyhjäkäynnillä scan vs. normaali Porttiskannausten. On olemassa useita Tell Tale vihjeitä paketteja, joista paras on IP ID arvo.
Liittyvien virkojen:
