Które porty są uważane przez Chrome za niebezpieczne?

Niektóre porty generują błąd ( ERR_UNSAFE_PORT) podczas przeglądania do nich przez Chrome (patrz powiązane pytanie ). Które porty są uważane za bezpieczne, a które za niebezpieczne?

google-chrome

— ripper234
źródło

Odpowiedzi:

118

Poniżej znajduje się lista wszystkich ograniczonych portów w Chrome:

1,       // tcpmux
7,       // echo
9,       // discard
11,      // systat
13,      // daytime
15,      // netstat
17,      // qotd
19,      // chargen
20,      // ftp data
21,      // ftp access
22,      // ssh
23,      // telnet
25,      // smtp
37,      // time
42,      // name
43,      // nicname
53,      // domain
77,      // priv-rjs
79,      // finger
87,      // ttylink
95,      // supdup
101,     // hostriame
102,     // iso-tsap
103,     // gppitnp
104,     // acr-nema
109,     // pop2
110,     // pop3
111,     // sunrpc
113,     // auth
115,     // sftp
117,     // uucp-path
119,     // nntp
123,     // NTP
135,     // loc-srv /epmap
139,     // netbios
143,     // imap2
179,     // BGP
389,     // ldap
427,     // SLP (Also used by Apple Filing Protocol)
465,     // smtp+ssl
512,     // print / exec
513,     // login
514,     // shell
515,     // printer
526,     // tempo
530,     // courier
531,     // chat
532,     // netnews
540,     // uucp
548,     // AFP (Apple Filing Protocol)
556,     // remotefs
563,     // nntp+ssl
587,     // stmp?
601,     // ??
636,     // ldap+ssl
993,     // ldap+ssl
995,     // pop3+ssl
2049,    // nfs
3659,    // apple-sasl / PasswordServer
4045,    // lockd
6000,    // X11
6665,    // Alternate IRC [Apple addition]
6666,    // Alternate IRC [Apple addition]
6667,    // Standard IRC [Apple addition]
6668,    // Alternate IRC [Apple addition]
6669,    // Alternate IRC [Apple addition]
6697,    // IRC + TLS

Źródło: źródło Chrome .

— ciężki
źródło

I niebezpieczna lista portów Mozilli Firefox: www-archive.mozilla.org/projects/netlib/…

— CoolAJ86

Dzięki, to było bardzo pomocne w ustaleniu, dlaczego mój serwer ZNC nie działał poprawnie

— Hamy

od 2017 r. 65535 jest również uważany za „niebezpieczny”. Nie mam pojęcia, dlaczego err_unsafe_ports ma zastosowanie do żądań do localhost(oczywiście żądania do localhost powinny oznaczać, że jestem programistą lub w inny sposób celowo pośredniczę w żądaniach przez localhost).

— cowbert

@cowbert twoje założenie jest nieprawidłowe. Może to być XSS lub złośliwa witryna wysyłająca żądania do hosta lokalnego.

— cytinus

6697 jest także portem ograniczonym. Zdecydowanie dodatkowe są niewymienione w tym segmencie kodu źródłowego. Ktoś, kto wie więcej na ten temat, powinien dodać do tej odpowiedzi.

— AndrewF

Nazywa się to niebezpieczne nie dlatego, że jest niebezpieczne dla Chrome, ale dlatego, że jest niebezpieczne dla tych usług, w których atakujący może próbować użyć Chrome jako serwera proxy do atakowania usług na tych portach. Więcej wyjaśnień tutaj:

http://jazzy.id.au/default/2012/08/23/why_does_chrome_consider_some_ports_unsafe.html

— James Roper
źródło

domyślnie usługi sieciowe działają zwykle na porcie 80, a ruch szyfrowany SSL działa na porcie 443, więc powinny to być porty „bezpieczne”. Zazwyczaj jest to znane jako „domyślne porty” lub „dobrze znane porty”. „bezpieczny” wydaje się być chromem :)

„bezpieczny” jest jednak trochę bez znaczenia. Jeśli działa na innym porcie, jest bardziej prawdopodobne, że ruch jest niejasny, ale tylko dlatego, że na porcie 80 nie oznacza, że nie zainstaluje złośliwego oprogramowania itp. Na komputerze.

— Sirex
źródło

Nie ma powodu, dla którego ruch na portach innych niż domyślne byłby nieostry. Na przykład porty inne niż domyślne są używane na komputerach uniksowych, na których serwer WWW jest administrowany całkowicie niezależnie od lokalnego administratora (unix ogranicza serwery na portach <1024 do administratora systemu). Takie konfiguracje są obecnie bardzo rzadkie, ponieważ zmieniły się warunki ekonomiczne hostingu, ale nie ma w nich nic nielegalnego.

— Gilles

powyższe jest prawdą, ale nie zamierzam klikać żadnych adresów URL, które określają numer portu.

— Sirex,

@ Sirex Nawiasem mówiąc, czy chodzi o numer portu czy używany schemat połączenia? Na przykład, jeśli adres URL jest podobny: https://<domain_name>:20/<path_name>nie ma powodu się martwić, prawda? Ponieważ określa schemat bezpiecznego połączenia. Chociaż znajduje się on na porcie FTP (niebezpieczny, uważany za port), jeśli port nie działa https, to nie będzie żadnego połączenia? Więc czy chodzi o numer portu czy schemat połączenia? (Nawiasem mówiąc, nie staram się być mądrym dupkiem. Staram się zrozumieć, co jest bezpieczne, a co nie i dlaczego)

— Utku

Zazwyczaj, mimo że strona zaszyfrowana ssl może zainstalować złośliwe oprogramowanie na twoim komputerze, https oznacza po prostu, że zrobi to bezpiecznie. To nie jest oznaczenie, że ruch jest bezpieczny. Jest to oznaczenie bezpiecznego ruchu. Może to być również nieprawidłowy certyfikat ssl, ale ostrzeże Cię w przeglądarce. Krótka odpowiedź brzmi: nic nie jest naprawdę bezpieczne, chyba że znasz nadawcę informacji i wiesz, że kanał jest prywatny.

— Sirex,

W dobie usług internetowych jest to absolutnie nieprawda. Nawet w 2010 roku domyślnymi portami dla serwerów aplikacji internetowych, takich jak Tomcat lub Unicorn, były 8080 lub 8443. Unix ogranicza porty <1024 do działania jako root i nikt w 2010 roku nie będzie działał na serwerach aplikacji internetowych (apache http jest wyjątkowy, ponieważ wie, jak su do nieuprzywilejowanego użytkownika po uruchomieniu procesu głównego jako root) na porcie 80 lub 443.

— cowbert