A portscan - szabályos vagy szabálytalan - kapcsolat kezdeményezése több - az összes vagy a privilégizált - portokra. Folyamatának megértéséhez szükségünk lesz némi hálózati ismeretre; tudnunk kell, hogy néz ki általában egy TCP kapcsolat.
Ennek vázlatos módja a következő (a TCP csomagban beállított flag-ek kiemelve):
Eközben a sequence number-ek mindkét oldalon az elküldött csomagok adatterületének méretével inkrementálódnak. Az ACK nem, a SYN és a FIN pedig 1-gyel növeli a sequence number értékét.
Egy élő példa a tcpdump programot használva (a könnyebb érthetőség kedvéért a számunkra lényegtelen információkat töröltem):
15:25:16.889541 kliens.1697 > szerver.www: S 8347:8347(0) 15:25:16.890050 szerver.www > kliens.1697: S 90350:90350(0) ack 8348 15:25:16.890121 kliens.1697 > szerver.www: . ack 90351 15:25:19.988589 kliens.1697 > szerver.www: P 8348:8355(7) ack 90351 15:25:19.989047 szerver.www > kliens.1697: . ack 8355 15:25:19.993787 szerver.www > kliens.1697: P 90351:90580(229) ack 8355 15:25:19.993842 kliens.1697 > szerver.www: . ack 90580 15:25:19.993934 szerver.www > kliens.1697: F 90580:90580(0) ack 8355 15:25:19.993967 kliens.1697 > szerver.www: . ack 90581 15:25:19.995206 kliens.1697 > szerver.www: F 8355:8355(0) ack 90581 15:25:19.995628 szerver.www > kliens.1697: . ack 8356
Sok rendszerellenőrző program is használja ezt a technikát az elemzéshez. A scannelő valószínűleg arra kíváncsi, hogyan tudna betörni gépünkre vagy egyszerűen csak ,,érdeklődik'' a gépen futó szolgáltatások iránt.
A rendszeresen visszatérő próbálkozók gépének adminisztrátorait célszerű tájékoztatni az esetekről. Ha ők nem tesznek semmit a helyzet megváltoztatására, érdemes firewall-lal, de legalábbis tcp-wrapperrel kifilterezni ezeket a címeket.
A tcp-wrapper a portscan-eket nem észleli, ha a scannelő csak elkezdi és nem fejezi be a TCP handshake-et (kivéve a 2.0.x kerneleknél, mivel az accept() hibája miatt a nem befejezett TCP handshake-et is képes volt logolni a tcpd).
A TCP/UDP/ICMP scan log-olására több program is létezik, például az ippl[12], amely képes logolni az ICMP, TCP és UDP kapcsolatokat a megadott szabályok alapján (Apache-szerű config file-ja van) vagy a snort[13], amely nemcsak a protokoll információkat, hanem a csomagok tartalmát is ellenőrzi. Utóbbi fejlesztése elég előremutató, a 2.0-ás verzió már képes lesz ,,IP defragmentation''-re (a fragmentált IP csomagok összeállítására) és ,,TCP stream reassembly''-re (a TCP csomagokból a teljes adatfolyam összerakására), ami főként a csomagok tartalmának figyelésekor fontos illetve akkor, ha a scannelő fragmentált IP csomagokkal próbálkozik, (például az nmap[14] program -f paramétere segítségével), hogy a TCP header ne legyen egyben kiolvasható és így átcsússzon bizonyos firewall-ok és portscan detektorok ellenőrzésén. Az nmap egyébként gyakran használatos és jó portscanner. A snort logjának folyamatos elemzésére írt rövid kis programmal megoldhatjuk, hogy ellenlépéseket is tegyen bizonyos események bekövetkeztekor (pl. a kapcsolat megszakítása).
Ha egy másik gépen akarjuk a logot tárolni/elemezni, akkor érdemes megfontolni a snort listán[15] ajánlott megoldást:
$ snort | gzip -cv3 | nc -lw 5 -n tavoli_host nem_használt_TCP_port
a tavoli_host-on pedig:
$ nc -l -p TCP_port | gzip -d | ./logelemzo_prg
(Az nc a netcat program.) A log átvitelére lehetőséget nyújt a syslogd is, ehhez a snort-ot a -s paraméterrel, a célgépen a syslogd-t pedig -r paraméterrel kell indítani.
Sajnos a log-ban szereplő címek megbízhatósága megkérdőjelezhető, mert lehetséges spoof-olt forráscímű csomagokkal is scannelni. Ebben az esetben a scannelő egy számára sniffelhető hálózatról spoofol egy címet és a választ kiolvassa a hálózati forgalomból.
Nehéz ellenőrizni, hogy a logban talált IP valódiságát de nem mindig lehetetlen. Ha a scannelő - mivel nem szeretné, ha a saját hálózatáról felfedezné valamelyik gép adminisztrátora, aki logolja gépe forgalmát, így a scannelt gép válaszát is - olyan IP-t választ, amelyik nincs kiosztva vagy az adott gép a scannelés időpontjában ki van kapcsolva, elvben lehetséges, hogy a scan tényének felfedezése után rövid idővel a logban talált címet visszaellenőrizzük, működik-e. Ha nem, valószínűleg nem ott fut a scanner.
Az előzőleg leírtak szerint lehetséges az is, hogy több, különböző címről érkező portscan egy programtól származzon. Ebben az esetben a sok cím közül csak egy a valós, több spoof-olt cím közé rejtve. Ezt ellenőrizni traceroute segítségével lehet. Ha valamelyik címhez tartozó TTL érték megegyezik a traceroute által megadottal, kezdhetünk gyanakodni.
Sajnos azonban a legtöbb portscanner a TTL értékét egy adott intervallumon belül véletlenszerűen választja, így kicsi az esélye az egyezésnek. Ebben az esetben viszont összehasonlíthatjuk a címeket régebbi portscan log-okkal. Ha találunk megegyező címeket, valószínűleg megvan a scanner.