Come puoi sapere cosa fa realmente un server? [chiuso]

42

Mi sono state consegnate 3 scatole Linux, 1 frontale con apache e altre 2 che, per quanto ne so, non fanno molto. Tutti in esecuzione su Redhat.

La domanda è semplice: come posso sapere cosa sta realmente facendo il server? La documentazione zero è disponibile dal creatore.

— Bizmark
fonte

7

L'

— elenco dei processi

5

Dannazione! sicuramente qualcuno sa a cosa servono? quindi vogliono che tu li sostenga ma non sai cosa fanno ?!

— Digital Lightcraft

11

Spegnerli. Qualcuno ti farà sapere, quasi immediatamente , cosa non funziona.

— jscott,

58

NON SPEGNERE. Scollegare il cavo Ethernet, se si desidera urlare-test. Se non hai mai avuto un box con un tempo di attività di due anni non riesce a riavviare, a un certo punto. Questo non è il momento di aggiungere quella frustrazione al mix.

— Aaron Copley,

7

Ciò che tutti gli altri hanno detto, ma anche: esegui nmap contro di loro.

— Katherine Villyard,

42

Scollegare il cavo Ethernet e vedere chi si arrabbia.

Scherzi a parte, macchine misteriose come questa creano un sacco di sovraccarico mentale per una squadra e spesso non forniscono assolutamente alcun valore commerciale. Parla con il tuo capo, se nessuno sa cosa fa, forse a nessuno importa cosa fa.

— Josh Rumbut
fonte

43

NON SPEGNERE. Scollegare il cavo Ethernet, se si desidera urlare-test. Se non hai mai avuto un box con un tempo di attività di due anni non riesce a riavviare, a un certo punto. Questo non è il momento di aggiungere quella frustrazione al mix. (Copia questo qui perché deve essere letto.)

— Aaron Copley il

3

Hai ragione al 100%, ho modificato il post per riflettere ciò. Ero un po 'faceto, ma posso ancora essere faceto senza promuovere il disastro.

— Josh Rumbut,

8

Prima di scollegare la rete, è una buona idea salvare un elenco di processi in esecuzione e aprire socket su ciascun server - nel caso in cui qualcosa si basi su una connessione TCP tra i server che risulta essere STABILITA per molti mesi senza che nessuno ci pensi automatizzare tutti i passaggi necessari per aprirlo nel primo caso. (Ad esempio, se qualcuno avesse bisogno di un port forwarding SSH temporaneamente e poi se ne fosse dimenticato.)

— Kasperd,

4

Non farlo Che consiglio ridicolo. Stupide persone IT sconsiderate che fanno questo mi sono costate tanto tempo e lavoro. PRIMA CHIEDI. Se non sai a chi chiedere, CHIEDI A TUTTI .

— Corse di leggerezza con Monica il

4

Assicurati di lasciare il tempo sufficiente per qualcuno per urlare - l'unica volta che l'ho fatto con una macchina polverosa o desktop seduta su un rack della sala server - nessuno sapeva cosa facesse, ci è voluto un mese intero per notare qualcuno quando lo abbiamo staccato . Si scopre che faceva parte del sistema di gestione stipendi, senza quel server, la contabilità non poteva generare paghe mensili. Funzionava incustodito da almeno 3 anni senza che nessuno ci prestasse attenzione, quindi il "test dell'urlo" è stato un successo, se non lo avessimo fatto, il server alla fine sarebbe morto da solo. Abbiamo finito per inserirlo nel nostro cluster VMware.

— Johnny,

30

Questa è una domanda piuttosto ampia per il formato Serverfault, ma ecco un buon inizio:

Controlla i processi in esecuzione e quelli pianificati per essere eseguiti all'avvio del sistema.
- Rivedere la configurazione in esecuzione di ciascuno.
- Cerca in qualsiasi directory di dati definita. (Forse qualcuno ha installato MySQL e lo ha acceso, ma non ci sono database.)
Controlla le attività pianificate.
Controlla i log per vedere;
- che ha effettuato l'accesso di recente (e chiediglielo)
- e per avere un'idea di ciò che è stato eseguito.

Non hai menzionato la versione, quindi ho omesso i dettagli.

— Aaron Copley
fonte

8

C'è qualcosa di più importante di quali servizi sono configurati per l'avvio all'avvio del sistema. Quali servizi sono in esecuzione in questo momento? Avviare un servizio e dimenticare di configurarlo per l'avvio all'avvio non è un errore difficile da fare. In una nota correlata, è una buona idea esaminare altri stati del sistema come: punti di montaggio, tabella di routing, regole di iptables. Tutte queste sono cose che potrebbero essere facilmente modificate mentre il sistema è in esecuzione senza ricordare di aggiornare i file di configurazione utilizzati durante l'avvio.

— Kasperd,

Inoltre userei uno scanner di porte per vedere quali porte sono aperte, quindi proverei a connettermi ad esso usando i soliti strumenti. Per un (semplice) esempio, se la porta 443 è aperta, è possibile provare a utilizzare un browser Web per connettersi ad esso. Ho dovuto esplorare frequentemente server apparentemente abbandonati e uno dei miei strumenti preferiti per navigare rapidamente tra i file di configurazione in / etc e in altri luoghi è usare "lince" o "collegamenti" se preferisci. Si tratta di browser basati sui caratteri che svolgono anche un buon lavoro come browser di file, con una comoda navigazione con i tasti cursore.

— aseq,

1

@kasperd Fair play sulla corsa vs. servizi persistenti. Ma, ho pensato alle regole del firewall, ai punti di montaggio, ecc. Quelli mi sembravano componenti ausiliari che saranno già collegati a uno dei punti elenco esistenti. YMMV.

— Aaron Copley,

Aggiungi: verifica la presenza di connessioni di rete attive e annota i nomi dei servizi e i numeri di porta. Il metodo migliore per farlo varia in base al sistema operativo. Statuto netto EG Inoltre, metti una sorta di traccia sul computer in modo da poter vedere cosa fa durante il giorno. Potresti anche voler prendere in considerazione gli scenari quando le cose in esecuzione sui server POTREBBERO essere dannose.

— IceMage,

19

Ci sono alcune cose che potresti fare per provare e accertare cosa è in esecuzione sul tuo sistema.

Puoi controllare su quali porte è in ascolto il tuo server per avere un'idea di cosa c'è lì. Un buon comando da usare sarebbe:

 [root@server ~]# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             Stat    e       PID/Program name
tcp        0      0 0.0.0.0:139                 0.0.0.0:*                   LIST    EN      1880/smbd
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LIST    EN      1911/nrpe
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LIST    EN      1759/sshd

Come puoi vedere dall'output di esempio sopra, ti presenta la versione del protocollo (tcp o udp), l'indirizzo su cui si ascolta, la porta aperta e il programma in ascolto.

Nell'esempio troncato sopra (una macchina server) puoi vedere le porte tcp 139, 5666 e 22 in ascolto. Questi si risolvono rispettivamente in samba, nrpe (agente Nagios) e ssh e vengono confermati quando si controlla il programma in ascolto su quella porta.

Inoltre, puoi controllare l'elenco dei demoni che sono configurati per avviarsi all'avvio, per farlo, esegui: chkconfig --list | grep "3:on"

Esempio:

[root@server ~]# chkconfig --list | grep "3:on"
NetworkManager  0:off   1:off   2:on    3:on    4:on    5:on    6:off
acpid           0:off   1:off   2:on    3:on    4:on    5:on    6:off
sshd            0:off   1:off   2:on    3:on    4:on    5:on    6:off
sysstat         0:off   1:on    2:on    3:on    4:on    5:on    6:off
udev-post       0:off   1:on    2:on    3:on    4:on    5:on    6:off
vncserver       0:off   1:off   2:on    3:on    4:on    5:on    6:off
webmin          0:off   1:off   2:on    3:on    4:off   5:on    6:off
x2gocleansessions       0:off   1:off   2:on    3:on    4:on    5:on    6:off
.
.
.

o :

service --status-all

— Itai Ganot
fonte

5

Trovo netstat -pluntpiù facile da ricordare.

— circa

2

Inoltre, tcpdumppuò essere utile per determinare chi sta effettivamente utilizzando ciascun servizio.

— circa

18

Un altro metodo prevede il controllo della /etcdirectory e la visualizzazione delle date di modifica. Dopo una nuova installazione, tutti i file in questa directory dovrebbero avere all'incirca la stessa data / ora. E poiché un'installazione di solito installa molte cose che le persone di solito non usano, solo i file che hanno una data di modifica successiva riflettono lo scopo reale del server . Se questo è ext4 dovresti anche essere in grado di estrarre la data di nascita delle directory, quindi l'attività potrebbe essere abbastanza semplice.

Ancora un altro metodo implicherebbe il controllo dei .bash_historyfile per vedere cosa stavano facendo gli amministratori. Questo file può fornire una vasta conoscenza.

— Konrad Gajewski
fonte

7

Controlla le regole del firewall. Con un po 'di fortuna, è configurato per default-deny. Ciò significa che esiste una regola esplicita per ciascun servizio consentito.

Questo è meglio quindi netstatperché può anche mostrare porte aperte per es. Per backup notturni.

— MSalters
fonte

6

Una risposta che non ho ancora visto: controlla i file modificati più di recente. Registri, file di database, altri file di output ecc. Possono essere scritti in modo da fornire indizi:

find . -mtime -3

Ciò troverebbe i file modificati nella directory corrente e più in profondità, cambiati negli ultimi 3 giorni. Aumenta il numero 3 a un'ipotesi istruita fino a quando non ottieni un risultato che puoi esaminare.

Non a prova di errore, poiché le caselle potrebbero semplicemente elaborare alcune chiamate al servizio Web, restituendo alcuni dati senza mai scrivere nulla. Ma aggiunto al grande mix di cui sopra, potrebbe solo fornire alcuni indizi.

— JayMcTee
fonte