Dato l'accesso SSH, cosa devo fare per proteggere un server e monitorare (pericolose) azioni dell'utente?

Naviga le tue risposte
13

Contesto:

  • Piccola impresa, principalmente una software house per applicazioni web ma anche alcuni software desktop.
  • Molti collaboratori esterni, quindi una varietà di utenti esterni con accesso ai server.
  • Un singolo server fisico, con Linux e Xen come soluzione di virtualizzazione - ogni VM ha usi specifici e accesso controllato. Gli utenti esterni possono accedervi due
  • I server (virtuali) offrono una varietà di servizi: stack LAMP, email, DNS, ecc. Questa domanda riguarda i miei dubbi con l'accesso dell'utente locale
  • Gli utenti possono utilizzare SSH in due delle VM

Requisiti

  • Consente agli utenti di accedere a strumenti di sviluppo comuni, sia per il Web (PHP, Ruby on Rails, ecc.) che per le applicazioni standalone (gcc, g ++, ecc.); questo include non solo compilatori e simili, ma anche editori. Al momento, hanno accesso completo alla shell.
  • Gli utenti devono essere in grado di utilizzare il controllo del codice sorgente sul server: svn e git
  • Alcuni hanno accesso ai database MySQL

Domanda

Quali misure dovrei prendere per:

  1. Fornisci agli utenti una shell completa, se possibile, o una soluzione equivalente che soddisfi i requisiti di cui sopra in modo sicuro
  2. Automatizza il monitoraggio delle attività pericolose ove possibile (come nelle notifiche sudo / su)
  3. Riduci al minimo gli effetti se un utente mette le mani su un exploit di escalation di privilegi di 0 giorni prima che qualcuno lo patch sul server - è possibile?
posta tomeduarte 12.01.2011 - 20:52
fonte

3 risposte

9

Se gli utenti devono avere SSH sul server, uno strumento utile per proteggere la root del server è chroot - questo ti consentirà di dare loro l'apparente funzionalità del server root, senza in realtà dare loro i gioielli della corona.

In alternativa, quando usi comunque macchine virtuali, perché non fornisci loro istanze di server virtuali?

Entrambe ti permetteranno di eseguire strumenti di monitoraggio (come tripwire ) per verificare la presenza di modifiche ai file. La registrazione deve essere eseguita al di fuori dell'ambiente degli utenti.

Con le voci in / etc / sudoers puoi limitare le attività che gli utenti sono autorizzati a svolgere in su.

    
risposta data 12.01.2011 - 22:04
fonte
7

È inoltre possibile limitare gli utenti all'utilizzo di bash 4 (rimozione di altre shell) e registrare tutti i comandi e inviare copie a un server di registro separato.

Bash: cronologia a Syslog ( link )

Questo può aiutarti a controllare le attività degli utenti e, cosa ancora più importante, eseguire analisi forensi quando qualcuno fa qualcosa di male. Vorrei anche fare l'informativa completa - tutte le attività sono registrate e controllate, i trasgressori saranno perseguiti, ecc.

Anche la distribuzione di OSSEC (sistema di rilevamento delle intrusioni basato su host) sarebbe di aiuto; ha molte regole incorporate per rilevare e avvisarti di cose cattive. OSSEC può avvisarti di tutte le attività sudo / su.

    
risposta data 13.01.2011 - 03:07
fonte
6

Non dimenticare il tunneling, il port forwarding. Per impostazione predefinita AllowTcpForwarding è sì nel file sshd_config e consente agli utenti di inoltrare porte arbitrarie. Potrebbe causare molti più problemi di quanti tu possa immaginare. (Questa non è una risposta ideale per lo stile di scambio di oggetti, ma non sono riuscito a trovare una risposta migliore, è difficile riassumere il port forwarding con poche frasi) Prima di consentire l'accesso, è necessario saperne di più sul port forwarding.

Port forwarding in poche parole

SSH consente il multiplexing di flussi di dati su una singola connessione SSH. Uno o più di questi flussi possono essere port forward , in modo tale che il traffico verso una porta sul computer client dell'attaccante venga inviato tramite la connessione SSH a una porta specificata su un host specificato dal server . Ciò significa che se il server della shell ha accesso, ad esempio, a un server MySQL, quindi chiunque si connette alla casella SSH può accedere direttamente al server MySQL. Possono quindi utilizzare i propri strumenti client anziché limitarsi al software fornito nella casella SSH.

    
risposta data 12.01.2011 - 22:28
fonte

Leggi altre domande sui tag

Strumenti di attacco delle applicazioni Web accessibili C'è qualche vantaggio di bcrypt su più iterazioni di SHA-x / MD5?