Zapobieganie wiązaniu innych aplikacji z portami 80 i 443

16

W zeszłym tygodniu zadzwonił do mnie przestraszony klient, ponieważ myślał, że jego witryna została zhakowana. Kiedy spojrzałem na jego stronę internetową, zobaczyłem apache2stronę domyślną. Tej nocy mój serwer ( Ubuntu 16.04 LTS) zaktualizował się i uruchomił ponownie. Zwykle gdy coś pójdzie nie tak, zostałbym powiadomiony w nocy. Tym razem nie, ponieważ system monitorowania sprawdza kod stanu HTTP 200, a apache2strona domyślna zawiera kod stanu 200.

Stało się tak, że podczas uruchamiania apache2było szybsze połączenie z portami 80 i 443 niż mój rzeczywisty serwer WWW nginx. Sam nie instalowałem apache2. Przez aptitude why apache2dowiedziałem się pakiet php7.0 wymaga.

Proste usunięcie apache2nie zadziała, ponieważ najwyraźniej wymaga tego php7.0. Czy w jakiś sposób można stworzyć ograniczenie, aby tylko nginx mógł się łączyć z portami 80 i 443?

Inne rozwiązania są również mile widziane.

— Boyd
źródło

15

I dlatego powinieneś skonfigurować swoje serwery na żywo, aby aktualizowały się tylko wtedy, gdy wyraźnie zażądasz aktualizacji, abyś mógł najpierw przetestować swoje aktualizacje na komputerze programistycznym.

— Nzall,

2

Nie testuję najpierw aktualizacji na maszynie testowej, ale zawsze sprawdzam dzienniki zmian przed ręcznym planowaniem aktualizacji. Wygląda również na to, że apache2 prześlizgnął się podczas wcześniejszej aktualizacji. Po prostu tym razem zrestartował apache2, który jako pierwszy powiązał porty HTTP i https.

— Boyd

9

Na marginesie - This time not, because the monitoring system checks for HTTP status code 200. Możesz ulepszyć system monitorowania, sprawiając, że sprawdzi on rzeczywistą zawartość strony internetowej (niektóre ciągi znaków w treści lub nagłówku), będzie to bardziej niezawodne.

— VL-80

2

@Boyd Nie testuję najpierw aktualizacji na maszynie testowej, ale zawsze sprawdzam dzienniki zmian. Ale właśnie doświadczyłeś, jak niewiarygodna jest ta metoda. Czytanie dziennika zmian nie powie ci, jaki będzie wpływ na wdrożony system, ani nie powie o wprowadzonych błędach lub niezgodnościach.

— Andrew Henle,

5

@Nzall, aby być uczciwym, brzmi to tak, jakby tego rodzaju problem mógł nie pojawić się na maszynie testowej ... skutecznie ma warunki wyścigu, czy apache2 lub nginx powiążą porty, a maszyna testowa teoretycznie może mieć Nginx wygrał (przypadkowo) na czas testowania, aby problem nie został wykryty.

— Doktor J

29

Nie można zapobiec powiązaniu portu z niewłaściwą usługą. W twoim przypadku po prostu usuń apache z autostartu i powinieneś być dobry.

W przypadku wersji 16.04 i nowszych:

sudo systemctl disable apache2

W przypadku starszych wersji Ubuntu:

sudo update-rc.d apache2 disable

— Gerald Schneider
źródło

2

Zrobię to, ale miałem nadzieję, że będę w stanie obronić się przed przyszłymi sytuacjami, w których inny pakiet, który wiąże się z portami 80 i 443, jest nieświadomie zainstalowany w moim systemie jako zależność od innego pakietu.

— Boyd

1

Ponieważ jest to 16.04, również:systemctl disable apache2

— muru 13.04.17

12

@Boyd: Dlaczego ślepo instalujesz pakiety „nieświadomie”? Dlaczego na twoim serwerze na żywo używanym przez klientów nie odczytujesz nawet, które pakiety i zależności są instalowane? I dlaczego nie testujesz wszystkiego na serwerze lustrzanym przed wykonaniem? Są to podstawowe zasady działania i rozwiążą wszystkie twoje problemy.

— Lekkość ściga się z Moniką

6

@BoundaryImposition Chęć obrony przed powiązaniem oprogramowania z portami nie oznacza, że po prostu ślepo instaluję pakiety. Ale my też jesteśmy ludźmi, popełniamy błędy. Niestety nie jesteśmy w stanie najpierw przetestować każdej operacji na fikcyjnym serwerze, ale w tym przypadku nie pokazałby on od razu problemu, ponieważ apache2 został zainstalowany na tydzień przed pojawieniem się problemu (system został w międzyczasie nawet zrestartowany ). Chociaż nie jesteśmy w stanie przetestować każdego uaktualnienia, wciąż aktualizujemy co tydzień. Wolimy aktualne poprawki bezpieczeństwa niż ograniczone (poprzez monitorowanie) ryzyko przestoju.

— Boyd

3

@Boyd: „Niestety nie możemy najpierw przetestować każdej operacji na fikcyjnym serwerze” Dlaczego nie? Czy Twoi klienci wiedzą, że pomijasz tę procedurę?

— Lekkość ściga się z Moniką

27

Jeśli tak naprawdę nie używasz apache2, a PHP 7.0 tego wymaga, wygląda na to, że masz libapache2-mod-php7.0zainstalowany. Ten pakiet jest bezużyteczny bez Apache. Ponieważ używasz nginx, prawdopodobnie masz również zainstalowany php7.0-fpmlub php7.0-cgizainstalowany, z których każdy jest wystarczający do spełnienia php7.0wymagań dotyczących zależności:

$ apt-cache depends php7.0
php7.0
 |Depends: php7.0-fpm
 |Depends: libapache2-mod-php7.0
  Depends: php7.0-cgi
  Depends: php7.0-common
  Conflicts: <php5>

Jeśli masz którykolwiek z nich php7.0-{fpm,cgi}, możesz śmiało odinstalować Apache.

— muru
źródło

6

Rzeczywiście nauczyłem się dzisiaj, że w mojej sytuacji lepiej jest po prostu zainstalować, php7.0-fpma nie php7.0pakiet. Jest to również zalecane przez Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/…

— Boyd

5

Oto prawdziwe rozwiązanie prawdziwego problemu: jak zainstalować nginx i PHP na Ubuntu bez instalowania Apache.

— David Cullen

2

Aby odpowiedzieć na twoje pytanie, prawdopodobnie możesz ograniczyć port do konkretnej aplikacji za pomocą SElinux. Sam go nie używałem i mam jedynie powierzchowną wiedzę o jego możliwościach, ale oto wskaźnik, który znalazłem na tej stronie:

/server//a/257056/392230

W tej odpowiedzi wzzrd wydaje się pokazywać, jak udzielić określonej aplikacji (foo) uprawnienia do łączenia się z określonym portem (803). Musisz tylko skonfigurować zasady, aby tylko twoja aplikacja (nginx) była dozwolona dla określonych portów (80 i 443).

Opierając się na odpowiedzi wzzrd, może to być tak proste, jak dodanie tego do polityki

allow nginx_t nginx_port_t:tcp_socket name_bind;

i uruchamiam to

semanage port -a -t nginx_port_t -p tcp 80
semanage port -a -t nginx_port_t -p tcp 443

Chociaż wydaje mi się, że będziesz potrzebować również linii w polityce, która określa, że żaden inny program nie może się połączyć z tymi portami.

W końcu zgaduję, jaka jest odpowiednia konfiguracja.

W każdym razie nie sądzę, aby istniało Ubuntu z zainstalowanym i domyślnie włączonym SElinux. Ponieważ uważam, że wymaga zastosowania pewnych poprawek do różnych narzędzi i opcji jądra, łatwiejsze może być po prostu użycie Centos z zainstalowanym i włączonym SElinux od samego początku.

Przepraszam, nie jestem więcej pomocy. Może kiedyś ściągnę obraz Centos i spróbuję tego; to będzie dobry krok do nauki. Zaktualizuję tę odpowiedź, jeśli to zrobię.

— JoL
źródło

2

lol @ "może być łatwiej po prostu użyć Centos"

— David Cullen

2

Coś, czego jeszcze nie widziałem w odpowiedziach, ale wciąż istnieje możliwość:

Zmień konfigurację Apache, aby nasłuchiwać na inny port, na wszelki wypadek. Możesz to zrobić, otwierając plik konfiguracyjny Apache i zmieniając linie, które mają Listen 80inny port.

— Milan Drossaerts
źródło

To „rozwiązuje” problem tak samo jak zaakceptowana odpowiedź, ale z dodatkowym problemem, który polega na konieczności wyjaśnienia / udokumentowania zmiany. Ponadto, mimo że rozwiązuje problem, żadne z nich nie rozwiązuje całego problemu. Jeśli Apache jest wyłączony, ale przy następnym uruchomieniu, aplikacja X łączy się z portem 80, to znowu ten sam błąd.

— Darren H

0

Nie mam odpowiedzi na twoje dokładne pytanie, ale może musisz spojrzeć na swoją dystrybucję. Uważam, że każda dystrybucja, która umożliwia usługi (tutaj Apache2) podczas instalacji, jest niepewna. Zastanów się nad dystrybucją, która tego nie robi. Nie mogę powiedzieć, że kiedykolwiek widziałem takie zachowanie na Archlinux, jestem pewien, że są też inni.

— phelbore
źródło

1

Co więc polecasz, aby sformatować serwer i zainstalować inną dystrybucję? I dlaczego uważasz, że ubuntu nie jest w stanie obsłużyć określonych usług, jak wskazała inna odpowiedź? Ta odpowiedź jest komentarzem religijnym i nie jest pomocna.

— Wtower

Nie sformatowałbym teraz serwera i nie zainstalowałbym nowej dystrybucji, ale z pewnością zmieniłbym się przy następnej aktualizacji serwerów. Ubuntu został właśnie pokazany w tym poście jako nieodpowiedni, ponieważ umożliwia usługi, które nie zostały skonfigurowane (wyjątki od tego to coś w rodzaju graficznego logowania lub usługi dźwiękowej, rzeczy, które normalnie działają i nie są narażone na publiczny Internet ). Obawiałem się, że odpowiedź może być nieco religijna, ale nie o to chodziło, próbowałem wskazać rozwiązanie większego problemu.

— phelbore 14.04.17

1

Chociaż zgadzam się z tobą, że zrobienie tego jest niewłaściwe, uważam, że byłoby to bardziej odpowiednie jako komentarz, ponieważ tak naprawdę nie odpowiada na pytanie.

— JoL

To słuszna kwestia.

— Lekkość ściga się z Monicą