Impedire ad altre applicazioni di collegarsi alle porte 80 e 443


16

La scorsa settimana ho ricevuto una chiamata da un cliente spaventato perché pensava che il suo sito Web fosse stato violato. Quando ho cercato il suo sito Web ho visto la apache2pagina predefinita. Quella notte il mio server ( Ubuntu 16.04 LTS) si era aggiornato e riavviato. Normalmente quando qualcosa va storto sarei stato avvisato durante la notte. Questa volta no, perché il sistema di monitoraggio verifica il codice di stato HTTP 200 e la apache2pagina predefinita viene fornita con il codice di stato 200.

Ciò che è accaduto è che durante l'avvio è apache2stato più veloce associarsi alle porte 80 e 443 rispetto al mio nginx server web reale. Non ho installato apache2 da solo. Attraverso aptitude why apache2ho scoperto che il pacchetto php7.0 lo richiede.

La semplice rimozione apache2non funzionerà perché apparentemente php7.0 lo richiede. È in qualche modo possibile creare una restrizione in modo che solo nginx sia autorizzato a collegarsi alle porte 80 e 443?

Anche altre soluzioni sono più che benvenute.


15
Ecco perché dovresti configurare i tuoi server live per l'aggiornamento solo quando richiedi esplicitamente un aggiornamento, in modo da poter prima testare gli aggiornamenti su una macchina di sviluppo.
Nzall,

2
Non collaudo prima gli aggiornamenti su una macchina di prova, ma controllo sempre i log delle modifiche prima di pianificare manualmente l'aggiornamento. Inoltre, sembra che apache2 sia passato durante un aggiornamento precedente. È solo che questa volta ha riavviato apache2 è stato il primo a collegarsi alle porte http e https.
Boyd,

9
Come nota a margine - This time not, because the monitoring system checks for HTTP status code 200. È possibile migliorare il sistema di monitoraggio facendolo controllare il contenuto effettivo della pagina Web (una particolare stringa nel corpo o nell'intestazione), questo sarà più affidabile.
VL-80,

2
@Boyd Non collaudo prima gli aggiornamenti su una macchina di prova, ma controllo sempre i log delle modifiche Ma hai appena provato quanto sia inaffidabile quel metodo. La lettura di un log delle modifiche non può dirti quale sarà l'impatto su un sistema distribuito, né parlerà di bug o incompatibilità introdotti.
Andrew Henle,

5
@Nzall per essere onesti sembra che questo tipo di problema potrebbe non essere apparso su una macchina di prova ... ha effettivamente una condizione di competizione sul fatto che apache2 o nginx legheranno le porte, e la macchina di prova potrebbe teoricamente finire con nginx vince (solo per caso) per la durata del test in modo che il problema non venga scoperto.
Doktor J,

Risposte:


29

Non è possibile impedire a una porta di essere vincolata dal servizio sbagliato. Nel tuo caso, basta rimuovere apache dall'avvio automatico e dovresti essere bravo.

Per il 16.04 e successivi:

sudo systemctl disable apache2

Per le versioni precedenti di Ubuntu:

sudo update-rc.d apache2 disable

2
Lo farò, ma speravo di potermi difendere da situazioni future in cui un altro pacchetto che si collega alle porte 80 e 443 è installato inconsapevolmente sul mio sistema come dipendenza di un altro pacchetto.
Boyd,

1
Dato che è il 16.04, anche:systemctl disable apache2
muru,

12
@Boyd: Perché stai installando ciecamente pacchetti "inconsapevolmente"? Come mai, sul tuo server live utilizzato dai clienti, non stai nemmeno leggendo quali pacchetti e dipendenze vengono installati? E come mai non stai testando tutto su un server mirror prima di eseguire? Questi sono principi operativi di base e risolveranno tutti i tuoi problemi.
Corse di leggerezza con Monica il

6
@BoundaryImposition Volere difendersi dal binding del software alle porte non significa che sto solo installando ciecamente pacchetti. Ma anche noi siamo persone, vengono fatti degli errori. Sfortunatamente non siamo in grado di testare prima ogni operazione su un server fittizio ma in questo caso non avrebbe mostrato immediatamente il problema, perché apache2 è stato installato una settimana prima della comparsa del problema (il sistema è stato anche riavviato nel frattempo senza problemi ). Pur non potendo testare ogni aggiornamento, eseguiamo comunque l'aggiornamento settimanale. Preferiamo patch di sicurezza aggiornate rispetto al rischio di downtime limitato (attraverso il monitoraggio).
Boyd,

3
@Boyd: "Sfortunatamente non siamo in grado di testare prima ogni operazione su un server fittizio" Perché no? I tuoi clienti sono consapevoli che salti questa procedura?
Lightness Races con Monica il

27

Se davvero non lo stai utilizzando apache2, ed è PHP 7.0 che lo richiede, sembra che tu abbia libapache2-mod-php7.0installato. Quel pacchetto è inutile senza Apache. Dal momento che stai usando nginx, probabilmente hai anche php7.0-fpmo php7.0-cgiinstallato, uno dei quali è sufficiente per soddisfare php7.0i requisiti di dipendenza:

$ 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>

Se hai php7.0-{fpm,cgi}installato uno dei due , puoi andare avanti e disinstallare Apache.


6
Oggi ho davvero imparato che nella mia situazione sto meglio con l'installazione php7.0-fpme non con il php7.0pacchetto. Questo è consigliato anche da Ondřej Surý github.com/oerdnj/deb.sury.org/wiki/…
Boyd

5
Questa è la vera soluzione al vero problema: come installare nginx e PHP su Ubuntu senza installare Apache.
David Cullen,

2

Per rispondere alla tua domanda, puoi probabilmente limitare una porta a un'applicazione specifica usando SElinux. Non l'ho usato da solo e ho solo una conoscenza superficiale delle sue capacità, ma ecco un puntatore che ho trovato in questo sito:

/server//a/257056/392230

In quella risposta, wzzrd sembra mostrare come autorizzare un'applicazione specifica (foo) a collegarsi a una porta specifica (803). Dovresti solo avere il criterio impostato in modo che solo alla tua applicazione (nginx) siano consentite le porte specificate (80 e 443).

Basandomi sulla risposta di wzzrd, potrebbe essere semplice come aggiungere questo alla politica

allow nginx_t nginx_port_t:tcp_socket name_bind;

e eseguendo questo

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

Tuttavia, immagino che avrai anche bisogno di una linea nella politica che specifichi che nessun altro programma può legarsi a quelle porte.

Alla fine, sto solo indovinando quale sia la configurazione appropriata.

Comunque, non penso che ci sia stato un Ubuntu con SElinux installato e abilitato di default. Poiché credo che richieda l'applicazione di alcune patch a varie utility e un'opzione del kernel, potrebbe essere più semplice utilizzare semplicemente Centos che ha installato SElinux e abilitato fin dall'inizio.

Mi dispiace, non sono di ulteriore aiuto. Forse un'altra volta, scaricherò un'immagine di Centos e proverò questo; sarà un buon passo di apprendimento. Aggiornerò questa risposta se lo faccio.


2
lol @ "potrebbe essere più semplice usare semplicemente Centos"
David Cullen,

2

Qualcosa che non ho ancora visto nelle risposte, ma è ancora una possibilità:

Cambia la configurazione di Apache per ascoltare un'altra porta, per ogni evenienza. Puoi farlo aprendo il file di configurazione di Apache e cambiando le linee che hanno Listen 80su un'altra porta.


Ciò "risolve" il problema esattamente come la risposta accettata, ma con l'ulteriore problema di dover spiegare / documentare la modifica. Inoltre, mentre risolve un problema, nessuno dei due risolve l'intero problema. Se apache è disabilitato ma al successivo riavvio, l'applicazione X si collega alla porta 80, si verifica nuovamente lo stesso errore.
Darren H,

0

Non ho una risposta alla tua domanda esatta, ma forse devi guardare la tua distribuzione. Considererei qualsiasi distro che abilita i servizi (apache2 qui) all'installazione ad essere insicuri. Considera di esaminare una distro che non lo fa. Non posso dire di aver mai visto quel comportamento su Archlinux, sono sicuro che ce ne sono altri.


1
Quindi cosa mi consigliate, per formattare il server e installare qualche altra distribuzione? E perché credi che Ubuntu non sia in grado di gestire servizi specifici, come indicato da un'altra risposta? Questa risposta è un commento religioso e non è affatto utile.
Wtower,

Non formattare il server in questo momento e installare una nuova distribuzione, ma cambierei sicuramente la prossima volta che dovrò aggiornare i server. Ubuntu è stato appena mostrato in questo post come inadatto poiché sta abilitando servizi che non sono stati configurati (eccezioni a questo sarebbero qualcosa come un accesso grafico o un servizio audio, cose che normalmente funzionano e non sono esposte a Internet pubblico ). Temevo che la risposta potesse apparire un po 'religiosa, ma non era questo l'intento, stava cercando di indicare una soluzione a quello che vedevo come il problema più grande.
phelbore,

1
Anche se concordo con te sul fatto che non è corretto effettuare una distro, penso che sarebbe stato più appropriato come commento, in quanto non risponde alla domanda.
JoL

È un punto giusto.
Corse di leggerezza con Monica il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.