Pagina 1 di 5 1 2 3 ... ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 43

Discussione: Sicurezza server Linux

  1. #1

    Sicurezza server Linux

    Beh, stamane mi son messo a tavolino ed ho cercato di creare una bella soluzione per Linux nel modo piu' possibile sicura per quanto posso fare io.

    - GCC SSP per compilare i servizi in modo da proteggerli dal buffer overflow
    - Jail senza root nello shadow e con shell /bin/false in passwd, senza includes e librerie limitate al massimo necessarie per far funzionare i nostri servizi
    - Utente in jail per eseguire i servizi usando il sudo con password (per sostituire il root in modo sicuro)
    - Filesystem proc in jail montato in una cartella diversa da /proc
    - PS modificato per visualizzare i processi dal procfs montato in un'altra cartella visualizzando solo i processi di uno specifico utente (e se non se ne ha bisogno si puo' anche fare a meno del PS)
    - Cron job per eseguire ogni tot tempo un backup dei dati variabili all'interno della jail
    - Cambiamento attributi con chattr, chmod e chown delle configurazioni statiche che non richiedono cambiamenti, e modificabili solo da root
    - PATH dei binari modificati e non settati automaticamente al login dell'utente in jail
    - GRSecurity fuori jail come modulo di sicurezza nel kernel ulteriore e preventivare azioni maliziose all'interno del chroot jail ed utilizzare altre opzioni utili al fine di rendere piu' sicuro il sistema
    - Togliere tutti i binari che non servono nella jail (iptables, telnet, nc, chroot, su, ecc.) sia per sicurezza che per spazio
    - Utilizzare iptables per bloccare tutte le richieste tcp, icmp e udp, e mettere le regole ACCEPT solo per i servizi che vengono utilizzati in jail (in modo da bloccare possibili accessi su altre porte in caso un utente malizioso buchi la jail ed esegua un suo server) possibilmente utilizzando la flag -m stealth offerta da GRSecurity con la patch per iptables
    - Aggiornare continuamente tutti i servizi facendo a meno di utilizzare il PAM (sui sistemi che lo supportano)
    - Assicurare l'impossibilita' di sovrascrivere i files binari utilizzando l'opzione chattr adatta

    Pensate sia il caso di mettere questa configurazione su un server Slackware 10 o si puo' fare di meglio? Fate conto che ci stanno utenti in locale anche eh (shell, bnc e schifezze varie per racimolare un po' di soldini) e sto pensando seriamente di mettere un subjail, in modo che i servizi principali stanno nella jail root e quelli degli utenti nella subjail, ce' un po' di spreco di spazio ma penso sia abbastanza sicuro, voi avete idee migliori?

  2. #2
    Utente di HTML.it L'avatar di Sym81
    Registrato dal
    Jan 2002
    Messaggi
    114
    No, però se potessi mandarmi in pvt qualche link sulle configurazioni te ne sarei grato Ciao
    "Dream on
    Do you believe...all the things that you are seeing are true?
    The Start's where the End's leading you
    Do you believe...all's as twisted as one would perceive?
    Seek the Answer and soon you'll believe"

  3. #3
    Come ti ho spiegato per benino oggi in chat il rischio, seppur minimo, di compromissione del server c'è.
    Lo spiego a tutti:
    Il problema stà nella gestione del trasporto delle informazioni nell'intera struttura di rete.
    L'intera rete (ovviamente routerata) per comunicare fra se utilizza i DNS.
    In gran parte dei casi, la gestione della comunicazione tra un client e un server avviene richiedento da parte dell'interessato la conversione dell'FQDN ad un indirizzo ip (nel caso vigili la forma url testuale).
    Queste query generano inevitabilmente traffico UDP che, come saprete, con il medesimo non è prevista fase di 3-Way handshake.
    Mettiamoci nei panni dell'ipotetico attaccante A, il quale, sfruttando diverse tecniche che illustrerò tra poco, riesce a "mettersi nel mezzo" della comunicazione e, in seguito, camuffarsi come client lecito.
    Risultato: Il server, supponendo di inviare i dati al client leggittimo continua lo scambio, dall'altra parte l'attaccante ha a sua completa disposizione il server: è root.
    Il bello di tutto ciò è che questa applicazione trova pane per i suoi denti con tutti i maggiori servizi (telnet, ssh, smtp...).
    Facciamo un altro esempio:
    A= attaccante
    B= client lecito
    C= server
    Come saprete l'ssh è crittato e, in quanto tale, per la codifica/decodifica ha bisogno di una chiave.
    La chiave è a conoscenze del server e del client lecito...
    Mettiamo che il client lecito (b) volla collegarsi con pippo.it, invierà la query al server (C) per risolvere il dns; qui entra in gioco l'attaccante che, tramite hijacking, si camuffa al client, risultato: Il client lecito pensa di comunicare col server... ha inizio la trattativa ssh, l'attaccante ha modo di intercettare i dati del client lecito...
    La tecnica si ripropone all'inverso... stavolta l'attaccante, falsificando il proprio mac address, tramite l'ausilio della tecnica denomintata man in the middle ovvero: uomo nel mezzo riesce ad isolare dalla rete il client lecito, sfruttandolo come proxy per scindere le richieste del server e ridirigere da suo arbitrio le richieste.
    Unico accorgimento da parte dell'attaccante: eseguire l'attacco immediatamente dopo che il server ed il client lecito abbiamo scambiato le chiavi ssh, in maniera da trovarsi al posto del client in PIENA COMUNICAZIONE.

    Molti di voi si chiederanno, come essere sicuri ? beh, questo è uno dei tanti modi per generare un attacco passivo come conseguenza di uno sniffing, ho preferito non scendere nel dettaglio per curare più quanto riguarda un possibile modo per proteggersi.

    Per proteggerci da hijacking in generale è opportuno eseguire costantemente un controllo di basso livello alle query ARP ed alle variazioni del MAC address.
    Per fare ciò posso consigliare ARPWATCH, questo tool permette di scandagliare esclusivamente il traffico ARP anomalo.
    Inoltre sarebbe accortenza del client lecito monitorare, tramite l'ausilio di software come tcpdump, il traffico a basso carico interrompendo tempestivamente la connessione (è obbligatorio inviare tempestivamente un RST al server onde evitare che l'attaccante prenda il vostro posto) in caso di traffico anomalo.

    Inoltre è bene leggere e documentarsi su tutto quello che riguarda ARP Poisoning, Man in the middle, ARP Sniffing e tutto quello che riguarda gli attacchi passivi in generale.

    Se mi ricordo bene esiste un plugin per ettercap che permette di sfruttare le tecniche descritte: phantom.

    Saluti,

  4. #4
    @mozako Si, questo e' tutto vero, ma sono tecniche anche scontate... non nel senso che non ci si deve pensare ma che comunque e con qualsivoglia metodo di protezione quel metodo e' adottabile in quasi tutti i casi!

    Comunque grazie del consiglio, e cerchero' di provvedere

    @sym sto facendo una guida (iniziata teoricamente) e che la finiro' con la pratica su fare queste configurazioni. Non la faro' interamente passo passo per i novizi, sarebbe facile configurare un server con tutti i comandi gia' pronti, pero' l'essenziale con qualche spiegazione la mettero' sicuramente! (se ti puo' interessare)

  5. #5
    Ee vuoi ti scrivo qualche paginetta di ARP Poisoning e MITM.
    Cmq, un corretto controllo sulle richieste ARP e MAC sia a livello software che hardware li previene sicuramente questi attacchi, tutto dipende dalla pigrizia dell'admin

    Saluti,
    P.s.: Sfrutto questo post per presentarmi, salve HTML.it

  6. #6
    Utente di HTML.it
    Registrato dal
    Jan 2002
    Messaggi
    411
    Mmmmhh...

    La "tua" teoria fa' un po' acqua...

    Ti spiego le mie perplessita':

    -Le reti orma sono quasi tutte switchate(hai voglia a sniffare il traffico che non ti arriva)

    -Su UDP viaggano le richieste DNS , ma tutti gli altri servizi(tranne tftp, snmp e pochi altri) viaggiano su TCP (predire i numeri di sequenza non e' da tutti).

    -Su una rete "routerata" l'ARPWATCH non ti serve a una mazza.
    RTFM.
    Pessimismo e fastidio.

  7. #7
    Utente di HTML.it L'avatar di makuro
    Registrato dal
    Apr 2004
    Messaggi
    676
    Sarebbe interessante si!

    Magari facci sapere qualcosa se la scrivi anche sul forum sicurezza...

    Desine fata deum flecti sperare precando.

  8. #8
    @b00malek

    - L'attacco viene eseguito sul SUO PC, che è il client e non all'INTERNO della rete.

    - l'arpwatch deve essere eseguito sulla sua macchina.

    Evidentemente mi hai frainteso.



    Saluti e piacere.

  9. #9
    Utente di HTML.it L'avatar di makuro
    Registrato dal
    Apr 2004
    Messaggi
    676
    Originariamente inviato da b00malek
    Mmmmhh...

    La "tua" teoria fa' un po' acqua...

    Ti spiego le mie perplessita':

    -Le reti orma sono quasi tutte switchate(hai voglia a sniffare il traffico che non ti arriva)

    -Su UDP viaggano le richieste DNS , ma tutti gli altri servizi(tranne tftp, snmp e pochi altri) viaggiano su TCP (predire i numeri di sequenza non e' da tutti).

    -Su una rete "routerata" l'ARPWATCH non ti serve a una mazza.
    E' vero, non è tutto così semplice come a parole, ma se la rete non è monitorata troppo bene e si vuole rischiare di fare un pò di "rumore", ettercap fa "magie"...anche su reti switchate (STP Mangling docet)...
    Desine fata deum flecti sperare precando.

  10. #10
    Ecco, infatti non ho detto che è semplice da fare anzi...
    Ho solo sottolineato che l'attacco hijack è possibile.

    Saluti,

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.