Před nějakou dobou jsem kývnul na správcování sítě v jednom hotelu nedaleko Brna. Předchozí správce se o síť údajně nedokázal uspokojivě postarat. Jelikož celý hotel bere konektivitu ze standardní komerční přípojky velkého provozovatele telekomunikačních služeb, tu a tam se občas stalo, že vinou nějakého veselého zavirovaného zařízení na síti byla služba omezena nebo úplně pozastavena. Majiteli po nějakém čase došla trpělivost a mým novým úkolem tedy bylo dát to tam trochu do kupy a viníka vyhledat a zničit. Říkal jsem si, že nejprve provoz trochu zafiltruju a když to nepomůže, vytáhnu těžší kalibr v podobě inspekce paketů. K tomu jsem naštěstí nedošel, takže následující článek bude zejména souhrnem všelijakých služeb a jejich portů, které na veřejných sítích můžete potkat.
Výpadovka na internet
Předchozí správce byl naštěstí natolik technicky zručný, aby jej napadlo jako ústřední zařízení posadit MikroTik CCR1016-12G. To je docela slušný drobeček, vhodný pro velký provoz, který se nezadýchá ani při nějakém filtrování. Bohužel použití RouterOSu a jeho skriptovacího jazyka, o kterém se ve slušné společnosti nemluví, je stále šíleně limitující faktor. Předem se přiznám, že při filtrování IP nachytaných v různých blacklistech třetích stran, jsem si pomohl shell skriptem běžícím na stroji poháněným linuxem. A když už jsem začal psát o filtrování IP, tak předvedu, jakým způsobem jsem to řešil.
Nejprve je potřeba zmínit, že nejrůznějších IP a DNS blacklistů se po internetu povaluje spousta, takže je jen na vás, které se vám budou líbit a které se rozhodnete použít. Já jsem se rozhodl pro Ransomware Tracker, ZeuS Tracker, Malc0de a Malware Domain List. Od nich jsem si stáhl blacklisty, přidal nějaké svoje adresy (různé honeypoty a watering hole) a naopak některé jiné whitelistoval, protože u sdílených hostingů a content delivery sítí je pro jednoho distributora malware až příliš snadné stáhnout s sebou stovku legitimních webů jen proto, že sdílí IP. DNSBL by přibyl v dalším kroku, ale k tomu naštěstí nedošlo. No a na závěr jsem tyto blacklisty propasíroval přes grep, sort a sed a vypadl mi krásný RSC skript, který na MikroTiku můžu rovnou importovat.
#!/bin/bash
RSCFILE=/var/www/html/malware.rsc
TMPDIR=$(mktemp -d)
wget -q https://ransomwaretracker.abuse.ch/downloads/RW_IPBL.txt -O ${TMPDIR}/rwt.txt
wget -q https://zeustracker.abuse.ch/blocklist.php?download=badips -O ${TMPDIR}/zeus.txt
wget -q https://malc0de.com/bl/IP_Blacklist.txt -O ${TMPDIR}/malcode.txt
wget -q https://www.malwaredomainlist.com/hostslist/ip.txt -O ${TMPDIR}/mdl.txt
cat <<EOF >${TMPDIR}/custom.txt
192.168.1.1
EOF
cat <<EOF >${TMPDIR}/whitelist.txt
192.168.1.1
EOF
echo -e "/ip firewall address-list\nremove [find list=Malware]" > ${RSCFILE}
cat ${TMPDIR}/*.txt | grep '^[[:digit:]]' | grep -v -f ${TMPDIR}/whitelist.txt | sort -u | sed 's/^/add list=Malware address=/' >> ${RSCFILE}
Na straně MikroTiku pak už jen stačí naskriptovat stahování
/tool fetch url=http://linuxovy-server/malware.rsc
import malware.rsc
A celou parádu šoupnout do cronu a scheduleru.
Well-known porty
Článek jsem nazval Malá encyklopedie portů protože právě charakteristika používaných portů, počtu spojení a cílových IP adres na kterých kýžené porty naslouchají, je velmi dobrým vodítkem ke zjištění, co které zařízení provádí, jaké síťové aplikace na něm běží a jestli náhodou zrovna neobsahuje červíka, po kterém jdu. Služby a porty, které jsem potkal, se pokusím sdružit do logických celků. Podotýkám, že se v žádném případě nejedná o kompletní výčet všech 65534 portů, ale jen o ty, které jsem při svém bádání potkal, z nich některé jsem ani neznal. Schválně, kdo z hlavy vysype, jaké porty používá třeba takový Viber nebo MQTT?. Taktéž zdůrazňuji, že se jedná o výchozí a doporučená čísla portů a jejich filtrování není samospásné, protože přesunout službu na jiný port je pro správce dané služby otázkou jednoho řádku v konfiguraci. Třeba ale i jen takový strohý výčet jednou někomu ušetří půlhodinu googlení.
Well-known porty jsou porty s číslem nižším než 1024, na nichž běží dlouhodobě zavedené (čti: „prehistorické“) a dobře známé služby.
- 21/TCP a 990/TCP – FTP – Přesněji řečeno FTP commands, protože v závislosti na aktivním/pasivním režimu připojení FTP používá také další porty. V aktivním režimu FTP klient naslouchá na portu 20/TCP a přijímá na něm data, ale v internetu se zpravidla používá pasivní režim přenosu. FTP také umí běžet skrze implicitně navazované zabezpečené spojení FTP over TLS (FTPS, neplést se SFTP, což je subsystém SSH sloužící ke stejnému účelu), pro které je výchozí číslo portu 990/TCP.
- 22/TCP – SSH – Secure Shell, zabezpečený protokol pro vzdálené připojení terminálu. Protokoly jako SCP nebo SFTP jsou subsystémy SSH, takže ty také poběží na portu 22/TCP.
- 23/TCP – Telnet – Nezabezpečený protokol pro vzdálené připojení terminálu. Tento port doporučuju důkladně pozorovat, protože v dnešní době prakticky neexistuje důvod, aby se klientská stanice připojovala kamkoliv do internetu skrze telnet. Leda by se chtěla podívat na hvězdné války. Zvýšený počet spojení na různé adresy může značit přítomnost malware na domáhajícím se zařízení.
- 25/TCP, 465/TCP a 587/TCP – SMTP – Protokol pro předávání pošty mezi mailovými servery. Záměrně píšu předávání, protože ideální konfigurace by měla být taková, která na portu 25/TCP dovolí pouze doručení lokálním příjemcům. Pro odesílání by se v dnešní době měl používat port 587/TCP, který vyžaduje TLS a ověření identity odesílatele. Také existuje SMTP over TLS (SMTPS), které obvykle běží na portu 465/TCP.
- 53/TCP+UDP – DNS – Protokol pro překlad názvů hostitelů. Nejprve se vždy použije UDP, ale pokud je dotaz nebo odpověď větší než zadaný limit, přepne se na TCP.
- 67-68/UDP – DHCP – Protokol pro dynamickou konfiguraci klientů, tedy zpravidla automatické přidělení lokální IP adresy, výchozí brány a DNS serverů. Na portu 67/UDP naslouchá DHCP server, který následně posílá odpovědi na klientův port 68/UDP, podobně jako tomu bývalo u aktivního FTP. Na internetu byste jej zahlédnout neměli, protože DHCP požadavky používají broadcast, který nepřeleze hranici sítě.
- 69/UDP – TFTP – Tento protokol byste v internetu také najít neměli, protože je absolutně transparentní, ale na místních sítích se občas zahlédnout dá. Jedná se o Trivial File Transfer Protocol, který se používá například pro flashování routerů nebo různých jiných zařízení a také se přes něj zpravidla dopravují data v počátečních fázích bootování po síti.
- 80/TCP a 443/TCP+UDP – HTTP – Tady není moc co vysvětlovat. Protokol, na kterém běží prakticky celý world-wide-web a ještě hromada dalších věcí. Při filtrování dbejte zvýšené opatrnosti, protože u portu 443 je skutečně občas použito i UDP. Používá jej QUIC, což je Googlí experimentální protokol, který si dává za úkol dělat totéž co HTTPS, ale daleko rychleji. Nějaké podrobnosti o tom, jak HTTP vypadá a funguje si můžete přečíst v dílu seriálu o textových protokolech, který se HTTP zabývá. Na portu 443/TCP se také může krčit tunelovací protokol SSTP, který se za HTTPS prakticky maskuje.
- 110/TCP a 995/TCP – POP3 – Protokol pro stahování e-mailových správ ze serveru. POP3 over TLS (POP3S) naslouchá ve výchozím stavu na portu 995/TCP.
- 123/UDP – NTP – Protokol pro synchronizaci času.
- 137/TCP, 138/TCP+UDP, 139/TCP a 445/TCP – NetBIOS a SMB – Protokoly pro sdílení souborů, tiskáren, hostitelských názvů a dalších věcí ve světě Windows. Na internetu nemají co dělat. Přílišná aktivita, kdy se jedno zařízení snaží vehementně pořád dokola na těchto portech kontaktovat všechna ostatní zařízení v síti, může naopak značit přítomnost nějakého malware. Pravidla pro IDS na nich však nestavte, protože občas jsou i dokonale čisťounké Windowsy nehorázně ukecané.
- 143/TCP a 993/TCP – IMAP – Protokol pro přístup ke vzdálené e-mailové schránce. Modernější bratříček POP3. IMAP over TLS (IMAPS) naslouchá ve výchozím stavu na portu 993/TCP.
- 161/UDP – SNMP – Služba pro monitoring zařízení po síti. SNMPv1 a SNMPv2 neposkytuje žádnou ochranu. SNMPv3 pak umožňuje šifrování a autentizaci, ale i tak jej na internetu většinou neuvidíte, protože slušní lidé je schovávají do VPN nebo zabezpečených VLAN.
- 389/TCP a 636/TCP – LDAP – Protokol k dotazování adresářových serverů. Taktéž častější v intranetech než na internetu. LDAP over TLS (LDAPS) naslouchá ve výchozím stavu na portu 636/TCP.
- 514/UDP – Syslog – Vzdálené systémové logování. Podobně jako u SMNP i zde se jedná převážně o nešifrovanou komunikaci a tak je záhodno ji zašít do nějakého tunelu. 514/TCP se kdysi používal pro Remote Shell (rsh), který sloužil ke vzdálenému přihlašování k terminálu, ale stejně jako Telnet nebyl šifrovaný, takže dnes už se s ním potkáte jen velmi vzácně.
- 554/TCP+UDP – RTSP – Protokol pro řízení síťového proudu. Dříve se používal ke streamování videí, dnes se od něj upouští ve prospěch obyčejného HTTP(S).
- 843/TCP – Flash Socket Policy – Tohle je trochu chuťovka. I přesto, že má číslo nižší než 1024, nejedná se o well-known port. Prostě si ho Adobe jen tak ze srandy zvolilo. Tato služba má za úkol blacklistovat/whitelistovat hostitele, kteří se mohou připojovat k instanci flash playeru. Nějaké informace se dají najít na Adobe DevNetu. Flash nejspíš ještě není zdaleka tak mrtvý, jak to s ním vypadá, protože za týden dohlížení jsem pěkných pár stovek paketů na tomto portu nachytal.
Tím končí well-known porty a dál pojedu tematicky.
VPN a proxy služby
- 1080/TCP – SOCKS5 – Univerzání
ponožkovýTCP a při troše snahy i UDP proxy server. - 1194/TCP+UDP – OpenVPN – Otevřený tunelovací protokol a stejnojmenný klient i server. Standardně používá UDP, ale pro zvýšení stability za cenu snížení propustnosti je možno použít i TCP.
- 1701/UDP – L2TP – Nezabezpečený tunelovací protokol emulující linkovou vrstvu. Zpravidla se používá v kombinaci s IPsec, který potřebuje ještě port UDP/500 pro výměnu klíčů (IKE) a transportní protokol IPsec-ESP (číslo 50). Složitost tohoto zabezpečení je důvodem, proč se na klientských stanicích obvykle nepoužívá, ale mezi servery či routery je celkem běžný.
- 1723/TCP – PPTP – Tunelovací protokol, který mimo portu 1723/TCP pro řízení relace vyžaduje ještě transportní protokol GRE (Generic Routing Encapsulation, číslo 47).
- 1900/UDP – SSDP – Technicky vzato není přímo tunelovací služba jako spíš služba pro dynamické zjišťování zařízení v síti a zprostředkování spojení nebo NAT. V současnosti je hojně využívána v UPnP zařízeních, multimediálních serverech a pro hraní online. V malých nedůležitých soukromých domácích sítích jsem schopen ji přežít, ale ve veřejné se 100+ klienty ji na routeru vidím zapnutou nerad.
- 3128/TCP – Squid proxy – HTTP a FTP proxy. Ostatní HTTP proxy zpravidla běží na portu 8080/TCP, přezdívaném Alternative HTTP.
- 3478/TCP+UDP – STUN – Ačkoliv tento protokol není VPN nebo tunelem sám o sobě, napomáhá při identifikaci koncových adres zařízení používajících jiné protokoly při prolézání NATem. Typicky jej používá třeba SIP pro VoIP telefonii.
- 3544/UDP – Teredo – Tunelovací technologie pro přístup k IPv6 konektivitě na IPv4 sítích. Na rozdíl od jiných technologií (např. 6to4) funguje i za NATem. Velmi oblíbená technologie u torrentových stahovačů na sítích se zaříznutým P2P provozem.
- 5351/UDP – NAT-PMP – Služba určená výhradně k „dělání děr“ pomocí dynamického NATování portů. V ideálním případě její pakety na internetu nezahlédnete, protože je před odchodem ven sežere router.
- 6851/TCP a 6861/TCP – Hola – Tohle je docela svinstvo. Jedná se o decentralizovanou TOR-like síť, takže z každého z koncových uzlů, může vylézt obluda z podzemních rozměrů a vesele si DDoSovat nebo posílat ransomware. Jelikož jsem její koncové body objevil na dvou mobilních zařízeních, nejsem úplně přesvědčen o tom, že o ní jejich vlastnící ví, takže jsem milou Hola trochu přiškrtil. Problematiku identifikace TOR sítí trochu proberu v dalším článku.
- 8080/TCP a 8443/TCP – Alternative HTTP – Tyto porty se zpravidla používají u HTTP proxy serverů nebo u aplikačních serverů, na které není zamýšleno přistupovat přímo. Obecně vzato ale fungují stejně jako klasické HTTP(S).
Vzdálený přístup
- 3306/TCP – MySQL – Skrze tento port je možno se připojit přímo k MySQL/MariaDB databázi. TLS je sice podporováno, ale vynucuje explicitní nastavení certifikační autority u klienta, případně rovnou používání klientských certifikátů, na což se každý vyprdne a místo toho použije SSH a port si protuneluje.
- 3389/TCP+UDP – RDP – Protokol vzdálené plochy Microsoft Windows. Od verze RDP 8.0, uvedené ve Windows 8 a Windows Server 2016 je možno kombinovat TCP s UDP, což velmi znatelně zrychluje a zpříjemňuje použití vzdálené plochu i na pomalých internetech.
- 5432/TCP – PostgreSQL – Výchozí port pro PostgreSQL databázi. Stejně jako v případě MySQL není úplně obvyklé takový port v divočině potkat, protože se na databázové služby zpravidla přistupuje skrze webové rozhraní nebo port tunelovaný skrze SSH.
- 5900/TCP – VNC – Otevřený protokol pro vzdálenou plochu, používaný převážně na linuxech. Je poměrně časté, že mimo 5900/TCP je na systému otevřeno i několik dalších portů v jeho blízkosti, na kterých se dá připojit k jednotlivým relacím a plochám.
- 5938/TCP+UDP – TeamViewer – Univerzálně použitelná služba vzdálené plochy, která si umí pomocí rendezvous serveru přelézt NAT.
- 8291/TCP – WinBox – Jelikož řeším filtrování provozu na MikroTiku, nemůžu nezmínit proprietární protokol pro ovládání MikroTiků skrze grafické rozhraní WinBox.
Komunikace a mobilní služby
- 4244/TCP, 5242/TCP, 5243/UDP, 9785/UDP – Viber – Moderní kecálek. Pozor, dva porty jsou TCP a dva UDP.
- 4433/TCP – Signal – Moderní superbezpečný kecálek. Měl by si vystačit i s HTTP(S) na portech 80/TCP a 443/TCP, ale některé verze (např. Signal pro Chrome) může kvůli důveryhodnosti certifikační autority (Signal používá vlastní CA) vyžadovat i port 4433/TCP.
- 5060/TCP+UDP a 5061/TCP – SIP – Protokol používaný pro navazování spojení, zejména u VoIP. Často používaný v kombinaci se STUN na 3478/UDP. SIP over TLS (SIPS) naslouchá ve výchozím stavu na portu 5061/TCP.
- 5190/TCP – OSCAR – Protokol používaný ICQ a AOL klienty. Budiž jim země lehká.
- 5222-5223/TCP, 5269/TCP – XMPP – Rozšiřitelný protokol pro posílání zpráv. Dříve známý jako Jabber, dnes použitý i u jiných systémů pro zasílání zpráv (např. Whatsapp). XMPP over TLS (XMPPS) naslouchá ve výchozím stavu na portu 5223/TCP, což je shodou okolností stejný port, který si Apple ukradlo pro své iCloudové služby a oznámení Apple Push Notifications (APNS). Port 5269/TCP je pak XMPP Federation, který je použit pro komunikaci mezi XMPP servery.
- 5228/TCP – Google Play – Dříve známý jako Google Market. Služba, skrze kterou mohou androidi stahovat aplikace, knihy, hudbu a jiný obsah.
- 6667/TCP, 6697/TCP – IRC – Prastarý, ale díky své jednoduchosti a nenáročnosti stále hojně používaný skupinový kecálek. IRC over TLS (IRCS) naslouchá ve výchozím stavu na portu 6697/TCP. Bohužel porty obsahující číslo 666 jsou oblíbené u různých script kiddies, takže je využívá i hromada malware. Ach jo. Kde jsou ty časy, kdy byl port 666 pouze pro Doom multiplayer.
- 9987/UDP, 10011/TCP a 30033/TCP – TeamSpeak – Hlasový chat oblíbený zejména u hráčů počítačových her.
- 16384-16387/UDP a 16393-16402/UDP – Apple FaceTime – Mutlimediání messaging pro jablíčkáře.
- 19302-19309/UDP – Google Hangouts – Multimediální messaging pro nejablíčkáře.
Drtivá většina instant messaging aplikací mimo výše uvedené rozsahy vyžaduje i přístup na klasické HTTP(S) na portech 80/TCP a 443/TCP. Některé (Facebook Messenger, SnapChat, Telegram atd.) si vystačí pouze s HTTP(S).
Počítačové hry a konzole
- 1119/TCP+UDP, 3724/TCP+UDP, 6012/TCP+UDP a 6112-6119/TCP+UDP – Blizzard – Battle.net a hry jako Diablo, Hearthstone, Overwatch, StarCraft, WarCraft a World of WarCraft. Úplný seznam portů naleznete na stránkách battle.net, ale výše uvedený výčet stačil k tomu, aby výrazně ubylo stížností.
- 1863/TCP+UDP, 3074/TCP+UDP, 3544/UDP – Xbox – Služby Microsoftí herní konzole.
- 3480/TCP, 3658-3659/TCP+UDP – PlayStation – Konzole od Sony mimo těchto portů pro PS Home a PS AMS vyžadují ještě STUN na 3478/UDP. Pravděpodobně mi zde ještě nějaké porty chybí, jelikož jsem neměl možnost zafiltrovaný PlayStation nijak otestovat.
- 4379-4380/UDP, 27000-27014/UDP, 27015-27030/TCP+UDP – Steam – Steam je pěkně nenažraný, jelikož jeho distribuční mechanismy fungují na principu P2P. Na portech 4379-4380/UDP ve spojení se STUN na 3478/UDP mu funguje voice chat a P2P networking. Na portech 27015-27030/TCP+UDP přihlašovaní herního klienta a stahování obsahu. Zbytek je veden jako game client traffic což může znamenat opět P2P distribuci obsahu. Seznam všech portů je na stránce Steam supportu.
Ostatní
- 1883/TCP a 8883/TCP – MQTT – Protokol pro Internet of Things (IoT). Svého času chvíli používán i Facebook Messengerem. MQTT over TLS (MQTTS) naslouchá ve výchozím stavu na portu 8883/TCP.
- 1935/TCP – RTMP – Protokol pro řízení multimediálního proudu. Na rozdíl od RTSP je původně jednalo o proprietární protokol Adobe, ale nakonec byl tak nějak s neúplnou dokumentací otevřen.
- 5355/TCP+UDP – LLMNR – Protokol pro zjišťování názvů zařízení v místní síti. Link-Local Multicast Name Resolution je naštěstí skutečně jen link-local multicast, takže tyto pakety byste na internetu skutečně vidět neměli. Zato na místní síti jich uvidíte hromadu, protože s tímhle umí být Windowsy opravdu otravné.
- 6881/UDP – DHT Router – Tohle je záležitost, která se týká BitTorrentu. Je poněkud komplikovaná na vysvětlení, takže o celé problematice zjišťování a blokování BitTorrentu napíšu samostatný článek.
- 7275/TCP – SUPL – Protokol, skrze který předává a přijímá data A-GPS pro zvýšení přesnosti určování polohy.
- 40001-40046/TCP+UDP – Windows Update – Mimo Windows update také slouží pro zasílání oznámení o chybách a zřejmě i nějaké další věci. Pro paranoiky připomínám, že rozhodně nedoporučuji updaty nijak blokovat a že telemetrie používá klasické HTTPS na portu 443/TCP.
Firewall po Disassemblerovsku
Osobně zastávám filozofii „Žij a nech žít“, takže obvykle vůbec neblokuji odchozí provoz a nechávám jej volně plynout, ve víře, že uživatelé vědí, co dělají. To že to často není pravda, ponechme stranou. Mimo výše uvedených portů jsem se ještě pustil do křížku s TOR sítěmi a torrenty, ale jejich problematika je natolik komplexní, že si ji nechám pro samostatný článek. Máte-li zájem o skript pro filtrování provozu na zařízeních MikroTik, který jsem stvořil před bůhvíkolika lety a vylepšil na základě výše uvedené analýzy, utíkejte se podívat ke mně na GitHub. Jsem si celkem jistý, že v průběhu následujících pár let se bude ještě do sytosti měnit. Podotýkám, že se jedná o skripty vhodné pro použití v domácích a malofiremních IPv4 sítích. Ve velkém měřítku nebo v dual-stack sítích řeším spoustu věcí jinak.
Úplně za závěr jen prozradím, že jsem nakonec viníka našel. Byl to nějaký idiot s Windows XP a vypnutými aktualizacemi, kterému tam ve velkém stylu řádil Conficker. Tak jsem mu za vydatného pyskování počítač odviroval a nainstaloval alespoň ty opravdu kritické záplaty. I tak jich bylo blízko ke stovce.