Ne, pole čísla portu v hlavičce TCP je technicky omezeno na 2 bajty. (získáte 2^16=65536 možné porty)
Pokud změníte protokol rezervováním více bitů pro vyšší porty, porušíte specifikaci pro segmenty TCP a klient to nepochopí. Jinými slovy, už nemluvíte o TCP a termín „port“ jako v „zdrojovém/cílovém portu TCP“ by neplatil. Stejné omezení platí pro porty UDP.
To znamená, že zadní vrátka by místo toho mohla komunikovat přes jiný protokol než TCP nebo UDP, aby zakryla svou komunikaci. Například icmpsh je reverzní shell, který používá pouze ICMP. Nakonec můžete také implementovat svůj vlastní protokol transportní vrstvy pomocí nezpracovaných soketů, které mohou mít vlastní představu o portech s větším rozsahem než 0-65535.
Ne, je to toto číslo, protože pole TCP je dlouhé pouze 16 bitů (65536, ale začíná na 0), takže je v zásadě nemožné komunikovat vyšší port než 65535
Tento příspěvek obsahuje opravdu pěkný popis toho, proč tomu tak je v IPv4, jak je to stejné v IPv6 a jak můžete znovu použít porty při běžném používání.
Pokud byste přestavěli zásobník TCP/IP lokálně na počítači, nefungoval by celkový koncept kvůli tomu, jak funguje RFC 793 - Transmission ControlProtocol Standard, jak je uvedeno níže v některých odpovědích? Znemožnění přístupu ke službě běžící na vyšším portu potom 65535.
Neexistují žádné služby TCP/UDP na portech vyšších než 65535. Pokud podporuje čísla portů vyšší než 2–1, pak již to není TCP (nebo UDP) .
Můžete mít něco jiného že...? Tak určitě. A mohlo by to být velmi podobné TCP? Do bodu zpětné kompatibility? Ano na obě otázky.
Tolik se mluvilo o hardwaru a zařízeních, která mají vytvořená zadní vrátka, že k monitorování má přístup pouze vláda, a mě jen zajímalo, jestli to byl možná jeden ze způsobů, jak to dělali a vyhýbali se odhalení a nalezení?
Kdybych takové zařízení vyvinul, spoléhalo by se na protokol natolik běžný, že by nebyl pozoruhodný. Neznámý/nelegální protokolový paket, po kterém následuje nějaký další provoz, by byl docela podezřelý.
Skryjte se (téměř) na očích
Co by takové zařízení mohlo dělat, může být například kontrola některých bajtů v užitečné zátěži. Obvykle by to byly nekorelované hodnoty; Pak bych mohl posílat pakety do cíle, nebo pokud je to router, dokonce bez vlastní IP adresy, nějakému náhodnému, možná dokonce neexistujícímu hostiteli mimo cíl, vydávající se za (řekněme) požadavek HTTPS nebo pokus o přihlášení přes SSH.
Pokud uvidíte balíček, který neznáte, můžete mít podezření. Ale i když jste v protokolech viděli něco jako
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
SSH: failed attempt for user maintenance
nebudete se bát, zejména pokud jste měli ne uživatelská „údržba“. Možná byste předpokládali, že někdo někde objevil útok na nějaké zařízení s výchozím uživatelem „údržby“ (sakra, kdybych byl státní správou, mohl bych marketovat mít takové zařízení zranitelné a neopravovat ho, výhradně za účelem ospravedlnění takových připojení na úplně jiných zařízeních . Co bys udělal jako první, kdybys viděl takové pokusy? Buď nic ("neškodný bruteforce. Idiot"), googlujte a pokrčte rameny ("Ach, někdo si myslí, že mám CheapRouter 2000. Idiote", případně napište pravidlo firewallu pro blokování IP - kromě toho, že pakety stále přicházejí do síťová karta ).
A ve skutečnosti se stane, že ten zlý firmware v routeru, síťové kartě, základní desce nebo co máte, rozpozná paket a odešle zpět odpověď . Mohlo by to udělat falšováním paketů odpovědí přepisujících ty "skutečné".
Jediným příznakem něčeho velmi špatného by bylo, kdybyste porovnali, řekněme, příchozí a odchozí provoz ze zlého routeru:
Hostitel se serverem SSH:
--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH S+A <-- HOST
--> SSH ACK --> ROUTER --> SSH ACK --> HOST
...
--> LOGIN ----> ROUTER --> LOGIN ----> HOST
<-- FAIL2------ ROUTER <-- FAIL1 <---- HOST packets are different!
Hostitel bez serveru SSH:
--> SSH SYN --> ROUTER --> SSH SYN --> HOST
<-- SSH S+A --- ROUTER <-- SSH RST <-- HOST wait, WTF?
--> SSH ACK --> ROUTER HOST
...
--> LOGIN ----> ROUTER HOST
<-- FAIL2------ ROUTER HOST
Pokud byste přičichli ke kabelu, ať už nalevo nebo napravo od napadeného zařízení, okamžitě byste si nevšimli ničeho špatného.
Další podezřelou věcí by pak bylo, že odesílatel zřejmě používá rozšíření TCP Fast Open. Všimněte si, že můžete posílat další data v SYN i bez TCP/FO, budou jednoduše ignorována zařízeními, která jsou obě bez FO a bez kompromisů.