Numer portu w sieci wewnętrznej

Na jednej konferencji na temat chmury Microsoft Azure, w której wziąłem udział, prowadzący przedstawił pewną sprawę dotycząca sieci wewnętrznej.

Na przykład, jest router, do routera są podłączone 3 komputery, na jednym jest uruchomiony serwer HTTP. Wiadomo, że zwyczajowo, serwery HTTP pracują na porcie 80. W tym przypadku są dwie możliwości:

1. Serwer jest uruchomiony na jednym z komputerów na porcie 80, a w routerze jest ustawione przekierowanie ruchu na porcie 80 do tego komputera bez zmiany portu.
2. Serwer jest uruchomiony na jednym z komputerów na porcie 1234, a w routerze jest ustawione przekierowanie ruchu na porcie 80 do tego komputera ze zmianą portu na 1234.

Według prowadzącego konferencję, pierwsza konfiguracja jest podatna na prymitywne ataki (script kiddies), podczas, gdy druga konfiguracja jest na nie odporna ze względu na użycie nietypowego portu w serwerze HTTP i dokonanie zmiany portu na routerze.

Moim zdaniem, to jest bzdura totalna, gdyż w obu przypadkach, serwer HTTP od zewnątrz sieci jest widziany pod tym samym adresem IP i na tym samym porcie, więc każdy program atakujący (czy to wysłanie masowej ilości danych w krótkim czasie, czy wysłanie odpowiednio spreparowanego żądania do serwera, czy coś jeszcze innego) zadziałałby tak samo i on nie musi "znać" konfiguracji od routera do serwera, bo dla programu jest to ten sam adres IP i ten sam port. Nie wspominam o zmianie domyślnego hasła routera na inne, bo to jest już inny temat i żaden szanujący się administrator sieci nie pozostawi hasła domyślnego (na przykład "admin").

Czy to ja mam rację, czy prowadzący konferencję miał rację? Jeżeli prowadzący, to w jaki sposób można wytłumaczyć zależność podatności na ataki od konfiguracji sieci wewnętrznej (prywatnej)?

Masz racje, z punktu widzenia atakującego w obu przypadkach aplikacja stoi na porcie 80. Może to robić różnicę co najwyżej jeśli atakujący ma jakieś ograniczone RCE i nie może sobie sprawdzić gdzie co stoi a potrzebuje atakować z poziomu localhosta.
Wyobraź sobie że np. baza danych pozwala na połączenia tylko z localhosta a ty masz możliwość wykonania kodu PHP przez jakąś dziurę w aplikacji webowej. Jeśli nie wiesz na jakim porcie stoi baza i nie masz jak wywołać jakiegoś netstata to ciężko coś zrobić, oprócz próby łączenia się "na pałe", więc cię to spowolni przynajmniej.

Jedyny przypadek jaki mi przychodzi do głowy jest taki, że ktoś cudem wpina się w sieć wewnętrzną i ma niczym nieskrępowaną możliwość ataku na http://localhost:80 (podczas gdy router ma jakiś zabezpieczenie np. pozwalające na wysłanie ograniczonej liczby zapytań pod jeden adres).

Przy czym udawanie, że sieć wewnętrzna jest bezpieczna bo się port zmieniło jest głupie i niebezpieczne.