Jak mogę telnet do portu HTTP 80?

Po przeszukaniu google dowiedziałem się, że możemy telnetpołączyć się z serwerem internetowym do jego portu http i użyć GETdo pobrania strony HTML.

Na przykład:

$ telnet web-server-name 80

Ale nie jestem w stanie zrozumieć, jak to możliwe?

Pomyślałem, że jeśli port 80 jest przeznaczony dla serwera HTTP, wówczas port 80 będzie nasłuchiwał tylko httpżądań. Ale jak jestem w stanie telnetdo HTTPportu?

Nie są telneti HTTPdwa różne protokół?

Gratulacje, właśnie zagłębiłeś się w koncepcję warstw sieciowych, zdając sobie sprawę, że porty i protokoły nie są ze sobą bezpośrednio połączone. Jak mówią inni, telnet może być używany do łączenia się z dowolnym portem TCP. Jednak, aby zrozumieć, dlaczego jest to możliwe, musisz trochę zrozumieć warstwy sieciowe. Jeśli kiedykolwiek słyszałeś o modelu warstwy OSI 7, to pozwala ci używać telnetu do łączenia się z innym portem. Chociaż w Internecie, dotyczą tylko 4 warstw i nazywa się Internet Protocol Suite. Bez warstw sieci każdy program musiałby nie tylko zrozumieć własny protokół, ale musiałby również zdefiniować własny schemat adresowania IP i system portów, co oznacza, że ​​każdy router musiałby zrozumieć, w jaki sposób kierować tymi schematami, a różne protokoły byłyby dużo trudniej się uczyć i diagnozować. Krótko mówiąc, Internet nie działałby równie dobrze bez warstw.

Dotyczy to warstwy transportowej i warstwy aplikacji. W warstwie transportowej mamy protokoły internetowe, takie jak TCP i UDP, z numerami portów od 1 do 65535 na każdym. W warstwie aplikacji mamy protokoły takie jak HTTP, SMTP i DNS. Zwykle każdy dokument standardów internetowych definiujący protokół określa domyślny port TCP lub UDP, z którego protokół powinien korzystać domyślnie. Takich jak port TCP 80 dla HTTP, port TCP 25 dla SMTP, port UDP 53 dla DNS i port TCP 23 dla Telnet. Program telnet faktycznie mówi protokołem TELNET, który jest protokołem standardowym, ale przeważnie starożytny według obecnych standardów. Ponieważ sekwencje protokołów składają się z 8-bitowych znaków, rzadko widzi się sam protokół i jest on przeważnie przezroczysty w porównaniu z innymi bardziej nowoczesnymi protokołami, takimi jak HTTP i SMTP, które używają widocznych dla człowieka słów w ASCII, takich jak GET, POST, HELO, LOGIN, itp.

Ponieważ jego protokół nie jest ogólnie widoczny, telnet stworzył dobre narzędzie do łączenia się z innymi portami TCP i umożliwiające użytkownikowi ręczne wpisywanie protokołów. Niektórzy administratorzy sieci używają tej techniki do diagnozowania problemów z serwerami. Ponieważ jednak program Telnet nadal ma swój własny protokół i może czasami wysyłać dodatkowe bity danych, nadal możesz napotkać problemy z tą techniką. Podczas korzystania z usługi telnet naprawdę „nawiążesz połączenie” zarówno z warstwą aplikacji, jak i warstwą transportową. Zdarza się po prostu, że inne protokoły warstwy aplikacji mogą działać poprawnie przez większość diagnostyki i nie będą zakłócały protokołu telnet. Jest lepszy program do robienia tego poprzez nc (Net Cat. Nazwa pochodzi od wersji komendy cat).

$ nc www.stackexchange.com 80

Program nc nie zna żadnego protokołu warstwy aplikacji, a gdy nawiązujesz z nim połączenie, „nawiązujesz połączenie” tylko w warstwie internetowej (adres IP) i warstwie transportowej (TCP lub UDP). Oznacza to, że kontrolujesz, który protokół warstwy aplikacji jest używany. Prawie wszystko jest uczciwą grą, nawet binarne protokoły. Pozwala to również robić przydatne rzeczy, takie jak przesyłanie plików bez ich uszkodzenia i nasłuchiwać portów na przychodzącym ruchu:

nc -l 9000 < movie.mp4  (Your friend runs this)

nc friends.computer.hostname 9000 > movie.mp4  (you run this)

Następnie film.mp4 jest przesyłany przez sieć w ogóle bez protokołu warstwy aplikacji (takiej jak FTP). Protokół aplikacji jest tak naprawdę Twoim przyjacielem, który informuje cię, że jest gotowy do uruchomienia polecenia.

nc może także obsługiwać pakiety UDP i gniazda domeny UNIX. Używanie go do słuchania może być również interesujące.

nc -l 12345

Teraz w przeglądarce internetowej odwiedź http: // localhost: 12345 /, a podczas sesji nc powinieneś zobaczyć GET / HTTP/1.1żądanie przeglądarki . W tym momencie możesz wpisać coś i nacisnąć Ctrl-Di powinno to pojawić się w przeglądarce jako zwykły tekst (jeśli chcesz, aby HTML się pojawił, musisz odesłać mu poprawną odpowiedź protokołu HTTP, a następnie kod HTML).

Czasami programy, które natywnie mówią jeden protokół, taki jak HTTP, mogą łączyć się z innymi portami przeznaczonymi dla innego protokołu. Zazwyczaj nie można tego zrobić w przeglądarce GUI, ponieważ ograniczyły one możliwość łączenia się z niektórymi portami, ale jeśli użyjesz programu takiego jak curl, aby połączyć się z portem 25 (SMTP do wysyłania poczty), prawdopodobnie zobaczysz kilka błędy dotyczące zerwania protokołu.

$ curl yourispsmtpserverhost.com:25
220 yourispsmtpserverhost.com ESMTP Postfix
221 2.7.0 Error: I can break rules, too. Goodbye.

Dzieje się tak, ponieważ curl zwykle mówi protokołem HTTP, więc po ustanowieniu uzgadniania TCP zaczyna wysyłać dane w następujący sposób:

GET / HTTP/1.1
Host: yourispsmtpserverhost.com:25
User-agent: curl

Ale serwer SMTP oczekuje SMTP, który jest bardziej podobny do tego:

HELO myhomecomputername.local

W którym momencie serwer odsyła linię identyfikacyjną:

250 yourispsmtpserverhost.com

Widzisz więc, że nic nie stoi na przeszkodzie, aby curl nawiązał połączenie warstwy transportowej z serwerem SMTP, po prostu nie może odczytać protokołu. Ale możesz mówić protokół samemu za pomocą programu takiego jak telnet lub bardziej korzystnie nc.

telnet to narzędzie, które można podłączyć do dowolnego portu TCP.

Domyślnie łączy się z portem telnet (23), ale możesz mu powiedzieć, aby łączył się z portem http (80) lub smtp (25) lub czymkolwiek.

Musisz jednak wiedzieć, jak „mówić” protokół, którego serwer zdalny nasłuchuje na tym porcie.

Na przykład, jeśli chcesz uzyskać nagłówki strony internetowej (nazwy domen itp. Zostały zmienione, aby chronić winnych):

$ telnet www.example.com 80
Trying xxx.xxx.xxx.xxx...
Connected to www.example.com.
Escape character is '^]'.
HEAD http://www.example.com/ HTTP/1.0

HTTP/1.1 200 OK
Date: Fri, 30 Oct 2015 09:28:58 GMT
Server: Apache/2.4.17 (Debian)
Last-Modified: Sun, 14 Nov 2010 06:30:26 GMT
ETag: "843-494fd75830480"
Accept-Ranges: bytes
Content-Length: 2115
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Connection closed by foreign host.

HEADLinia to co mam wpisane w związku. Pamiętaj, że protokół HTTP wymaga wysłania pustego wiersza wskazującego koniec HEAD lub GET lub cokolwiek innego. To jest pusta linia natychmiast po żądaniu HEAD.

Wstępne negocjacje dla obu protokołów wykorzystują polecenia tekstowe, dzięki czemu można się połączyć i rozpocząć wprowadzanie poleceń. Dotyczy to innych starych protokołów, takich jak SMTP, a telnet był od dawna wykorzystywany do rozwiązywania problemów połączeniami z odpowiednimi usługami.

Na przykład

• HTTP Help: Jak testować HTTP za pomocą Telnet
• XFOR: Telnet do portu 25 w celu przetestowania komunikacji SMTP

Protokoły są niezależne od portu, na którym się komunikują. Prawie wszystkie implementacje można skonfigurować do nasłuchiwania na dowolnym porcie.

Niektóre protokoły (takie jak HTTPS) nie używają poleceń tekstowych do negocjacji. Możesz jednak (zwykle) połączyć się z portem, na którym serwer nasłuchuje, ale nic nie robić.

Część twojego zrozumienia jest poprawna, a niektóre nie. Port 80 jest ogólnie zarezerwowany dla HTTP, ale to tylko konwencja; każdy program może nasłuchiwać na dowolnym otwartym porcie w systemie. Jeśli serwer sieciowy nasłuchuje na porcie 80 w systemie, z którym się łączysz, musisz użyć HTTP, aby się z nim komunikować.

telnetwcale nie jest protokołem, to program, który pozwala wysyłać nieprzetworzony tekst do dowolnego hosta na dowolnym porcie. Zdalny host nie ma pojęcia, z jakim programem się łączy; wszystko, co widzi, to wysyłane do niego pakiety. Każdy program, który wysyła pakiety zgodne z protokołem, którego oczekuje zdalny host, będzie działał, więc możesz z niego korzystaćtelnet do komunikacji za pośrednictwem dowolnego protokołu tekstowego.

Wysłałeś coś wzdłuż linii GET /path/to/a/file HTTP/1.1, która jest ważna komenda HTTP 1.1 i wygląda tak samo jak żądanie, które będą wysyłane przez przeglądarkę internetową, tak to działa dobrze.