Newsgroup: it.comp.sicurezza.unix
Titolo: Che cosa succede

Ho un server che fa da firewall ad una rete locale, mi sono accorto che
c'era un certo
traffico anche con tutti i client spenti.
Ho controllato con iptraf quali erano gli indirizzi.
Poi visto che erano diretti dal server verso internet li ho bloccati con
ipchains.
Questi sono i log:
Oct 22 09:01:52 firewall kernel: Packet log: output DENY eth1 PROTO=6
MIO_IP:3128 
63.151.167.157:4923
 L=60 S=0x00 I=3734 F=0x4000 T=64 (#5)
Oct 22 09:02:00 firewall kernel: Packet log: output DENY eth1 PROTO=6
MIO_IP:3128 
195.130.233.45:3024
 L=60 S=0x00 I=3736 F=0x4000 T=64 (#8)
Oct 22 09:02:03 firewall kernel: Packet log: output DENY eth1 PROTO=6
MIO_IP:3128 
62.94.0.22:2549
 L=60 S=0x00 I=3738 F=0x4000 T=64 (#5)
Oct 22 09:02:10 firewall kernel: Packet log: output DENY eth1 PROTO=6
MIO_IP:3128 
213.239.150.40:2581
 L=60 S=0x00 I=3766 F=0x4000 T=64 (#8)
Attualmente li ho bloccati e non generano piu' traffico ma mi piacerebbe
sapere cosa succede.
Sembra che dalla porta di squid si interroghino alcuni indirizzi.
Ho il server compromesso ?
Cosa posso controllare?
Falco

 Sembra che dalla porta di squid si interroghino alcuni indirizzi.
Queste sono risposte del tuo server squid alle richieste provenienti da altre
macchine e non il contrario. Cosě in prima battuta mi verrebbe da dire che la
tua macchina č (era) un open-proxy e veniva utilizzato come "anonimizzatore"
da 213.239.150.40, 195.130.233.45, ecc.
Ora non funziona piů, ovviamente, anche se il sistema che hai usato non č
molto ortodosso.
Ti conviene rivedere le policy di accesso del tuo squid e, piů in generale,
del tuo firewall e del tuo sistema nel suo complesso perchč questo č un buco
molto banale e direi che a questo punto potrebbero essercene degli altri.
Fabio

 wrote in message
HKQA7.71124$1H1.7...@news.infostrada.it...

E' chiaro che l'aver impedito il traffico verso quegli indirizzi e' solo un
paliativo.
Da quello che mi dici sembra che da alcuni indirizzi pubblici vengano fatte
richieste a squid sul server.
In effetti devo negare l'accesso a squid dall'esterno, ma comunque in questa
maniera non
ne impedisco il traffico.
La cosa che mi ha insospettito e' la cosa e' cominciata dopo aver contestato
a telecom delle fatture sbagliate.
Hanno fatto una fattura che comprendeva pure del traffico in un bimestre in
cui
non avevo ancora la connessione.
Ho una hdsl con full business company con flat fino a 2.8 Gbyte e non vorrei
che
fossero loro a generarmi questo traffico fittizio.
Falco

 che fossero loro a generarmi questo traffico fittizio.
Gli indirizzi non sono di telecom e spero proprio telecom non faccia cose
simili.
Semplicemente ci vuole un po' di tempo prima che un proxy aperto venga scovato
e quindi solo dopo un po' di tempo dall'instalalzione č iniziato il traffico.
Fabio

 server.
gli unici servizi attivi sono:
netstat -a
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 firewall.rcp.it:ssh     
proxy.rcp.it:1023
ESTABLISHED
tcp        0      0 firewall.rcp.it:imap    *:*                     LISTEN
tcp        0      0 *:ndmp                  *:*                     LISTEN
tcp        0      0 *:ssh                   *:*                     LISTEN
tcp        0      0 
firewall.rcp.it:3128
    vortex.shellz.:cadsi-lm SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
    vortex.shellz.n:pammrpc SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
    vortex.s:driveappserver SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
    vortex.shellz.net:wins  SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
    vortex.shellz.:finle-lm SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
 
vortex.shellz.net:2072
  SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
 
vortex.shellz.net:2210
  SYN_RECV
tcp        0      0 
firewall.rcp.it:3128
 
vortex.shellz.net:2385
  SYN_RECV
tcp        0      0 *:3128                  *:*                     LISTEN
tcp        0      0 *:http-rman             *:*                     LISTEN
udp        0      0 *:blackjack             *:*
udp        0      0 *:ndmp                  *:*
udp        0      0 *:1024                  *:*
udp        0      0 *:icpv2                 *:*
a parte blackjak e http-rman che non mi risultavano i servizi non mi
sembrano tanti.
Ho controllato le regole di ipchains:
# accetta connessioni sul proxy (porta 3128) dalla rete interna
#
ipchains -A input -i eth0 -s 
192.168.1.0/24
 -d 192.168.1.40 3128 -p tcp -j
ACCEPT
#
# rifiuta la connessione a squid  a tutti gli altri
#
ipchains -A input -s 0/0 -d 0/0 3128 -p tcp -l -j REJECT
tra l'altro le richeste arrivano su eth1 a cui le richeste sulla 3128 sono
negate.
La cosa che comunque non mi quadra e' che ho bloccato il traffico in output.
ipchains -A output -s 0/0 -d 63.151.167.157 -i eth1 -l -j DENY
ipchains -A output -s 0/0 -d 195.130.233.45 -i eth1 -l -j DENY
ipchains -A output -s 0/0 -d 62.94.0.22 -i eth1 -l -j DENY
ipchains -A output -s 0/0 -d 213.239.150.40 -i eth1 -l -j DENY
perche negando in input non cambiava niente.
Falco

 Non capisco bene: cosa vuoi dire con "non ne impedisco il traffico"? Se neghi
Il giochino dell'HDSL funziona cosi':
NOn importa se i pacchetti che ti arrivano tu li usi, li rifiuti, o fai
finta di non averli mai visti: E' comunque traffico che la rete telecom 
porta fino al tuo router, pertanto paghi.
Immaginati di fare uno smurf ad un utente hdsl: 
tu lo attacchi, e lui paga, paga, paga,...
Insomma, non c'e' possibilita' (se non hanno cambiato politica) per usare
una connessione con pagamento a traffico, se non ti lasciano filtrare a
monte del router di tariffazione, e quando l'hanno proposta a me, non lo
lasciavano fare.
Indovina adesso se ho accettato il contratto. :-)
-- 
           |Save our planet!
  Ciao     |Save wildlife;
  roberto  |For your E-MAIL use only recycled Bytes !!
           |roberto poggi  
rpo...@softhome.net

 tu lo attacchi, e lui paga, paga, paga,...
OK, non avevo capito cosa intendeva per traffico: certo, se hai una
tariffazione a consumo paghi per qualsiasi pacchetto che transita sulla linea.
In ogni caso non mi fascerei la testa: se scarti la richiesta di connessione
senza emettere un ICMP Destination Unreachable paghi solo il pacchetto SYN in
entrata.
Se la tariffazione è sempre di 80 lire al MB come fino a poco tempo fa direi
che gli è costato di più il posting su icsu che tutto il traffico dei prossimi
6 mesi :).
Inoltre dal momento che il suo squid non sarà più raggiungibile il traffico
comincerà a diminuire vistosamente fino a raggiungere il livello di quello "di
fondo" generato dalle scansioni che tutti riceviamo sulla 3128 o 8080.
Fabio

 sembrano tanti.
Simpatici quei SYN_RECV da 
vortex.shellz.net
 :) La tua macchina piace!
Non è questione di tanti o pochi ma di mi serve o non mi serve.
Personalmente mi chiedo perchè ci debbano essere imap, ndmp (webmin?) o
http-rman su un firewall. E blackjack? L'hai installato tu?  Magari c'è un
motivo e tutto ti serve effettivamente ma ritengo che non sia una buona
pratica.
Diversi server imap, ad esempio, hanno un certo numero di buchi exploitabili:
sei sicuro che la tua versione non sia vulnerabile? Il fatto che tu usi ancora
ipchains mi fa pensare di si, se non hai aggiornato in seguiot l'imap
(probabilmente è una distribuzione datata).
Verifica comunque che tutti i servizi in ascolto siano stati installati da te.
Inoltre non capisco la connessione ssh: sembra quasi che tu abbia già un altro
proxy quindi perchè usare squid anche sul firewall?
Per quanto riguarda ipchains non dovresti negare il traffico solo per alcuni
IP ma per tutti. Personalmente nego tutti gli accessi a tutti i servizi come
policy di default e poi apro quelli che mi servono.
Comunque quelli che hai elencato sono server di chat (che in alcuni casi
forniscono anche una shell) e questo mi fa pensare che la tua macchina si
diventata un irc bouncer. Purtroppo le problematiche che riguardano irc sono
uno dei grossi buchi nella mia preparazione e quindi dovresti sperare che
qualcuno di più preparato legga questo thread e ti (ci?) dia una mano.
In ogni caso AFAIK se la tua macchina è un bouncer vuol dire che è stata
compromessa e non si può escludere che ci sia un rootkit installato: dovresti
controllare con uno scanner (tipo chkrootkit).
Forse è un atteggiamento un po' paranoide ma io nella tua situazione
reinstallerei tutto, magari partendo da una distribuzione specifica per
firewall.
Ciao
Fabio

 firewall.
scusa, quale puo' essere una distribuzione specifica per firewall?
io pensavo a debian o slack... pero' debian potato ha il kernel 2.2...
grazie,
Silvia

 io pensavo a debian o slack... pero' debian potato ha il kernel 2.2...
Esistono distribuzioni Linux specifiche: puoi provare Astaro, che è molto
completa ed è basata sul kernel 2.4 (ma che non è free per tutti gli
utilizzi). Ha dei limiti sul tipo di hardware utilizzabile.
Semplice da installare e da configurare c'è anche Mandrake Single Network
Firewall che però non gestisce in modo semplice una DMZ. Se cerchi un po' ne
trovi anche altre che però non ho mai provato.
Se vuoi partire da una distribuzione generica devi mettere in conto di perdere
un po' di tempo in ricompilazione del kernel e configurazione. Io userei una
distribuzione con kernel 2.4. Ti direi quella che conosci meglio: le modifiche
da fare sono tali che spesso le differenze tra una e l'altra diventano
abbastanza marginali. Se non hai preferenze penso che la Slack possa essere
OK.
Se hai tempo e voglia di imparare puoi anche provare con uno Unix tipo
Open/Net/FreeBSD con ipfilter (che tra l'altro è anche più in tema con questo
ng ;)) anche se ritengo che la soluzione Linux sia ormai all'altezza.
Fabio

 Silvia
Io ho usato tutte le Slack fino alla versione 7, e ti posso dire che
come sistema operativo e' uno tra i piu' sicuri ed affidabili che si
possano trovare come distro commerciale anche con il kernel 2.2, pero'
uso da sempre i sistemi bsd commerciali, e quindi la mia preferenza e'
caduta su questi
sistemi, anche se la Slack ha le sembianze di una Bsd come tipo di
installazione e configurazione.
Va' detto che una distro linux sicura, devi configurartela poi da sola,
sei client o server?
Devi in pratica valutare l'utilizzo che dovrai farne, in modo da poter
impostare poi una policy si sicurezza per il sistema/distro che
deciderai di usare.
Le policy di security, devono essere impostate diversamente per ogni
tipo di sistema, anche se le cfg rimangono comunque quelle standard per
tutti.
Se decidi di lavore solo come client, la policy migliore consiste nella
revisione del sistema scelto, in modo da eliminare anche programmi di
sistema che non ti servono visto che dovrai usare i servizi del tuo isp.
Se decidi di lavorare come server, le cose cambiano radicalmente, e qui
oltre che valutare i servizi che dovrai offrire ai tuoi utenti, dovrai
passare molto tempo a ricompilare patches e a scrivere script per il
firewall dedicati ai singoli servizi installati.
Se vuoi uno unix free abbastanza buono come sicurezza, ti consiglio di
installare OpenBSD, ha un'installazione molto semplice(install.sh), ma
come client avresti qualche difficolta' se non sei abituata ad usare
questo tipo particolare di sistema operativo.
Le cose sono migliori con FreeBSD 4.xx, in quanto hai la possibilita' di
usare un wm sicuro e botare direttamente in modalita' grafica sicura.
FreeBSD

 ng ;)) anche se ritengo che la soluzione Linux sia ormai all'altezza.
tempo non so quanto ne ho, non so quando dovra' essere tutto pronto...
voglia, si, certo, altrimenti non avrei spinto una soluzione cosi'
"innovativa" per noi, basata su un sistema non proprietario.
Devo dire che comincia a stuzzicarmi l'idea di FreeBSD...
alla peggio, mancando il tempo, ci giochero' a casa, anche se non so se sono
pronta, perche' gia' linux non lo conosco molto... per lavoro mi ritrovo
pero' a volte su unix "commerciali", che dal punto di vista del sistema sono
molto diversi... magari BSD mi risulta piu' semplice, chissa' :-)
Non e' che sapresti accennarmi (o linkarmi) la differenza tra i vari BSD
(tra loro) e (con) linux?
e chi e' meglio tra ipfilter e ipfw? (giusto per tornare in topic ;-) )
grazie,
Silvia

 usare un wm sicuro e botare direttamente in modalita' grafica sicura.
non mi spaventa tanto la linea di comando, ma se posso dare soddisfazioni
anche all'occhio (io metto i colori anche a un client telnet :-) )
Anche te la fatidica domanda: a grandi linee quali sono le differenze tra i
vari *BSD? e con linux?
e' gradito anche solo un link, grazie!
(non migliaia che poi e' come non averne)
ciao,
Silvia

 e chi e' meglio tra ipfilter e ipfw? (giusto per tornare in topic ;-) )
La scelta tra i due dovrebbe essere fatta non solo per le caratteristiche e le
performance ma anche (IHMO) per la portabilità: IPFilter è disponibile per un
molti Unix, consentendoti di non vincolare quello che hai imparato ad una sola
piattaforma.
Per adesso la differenza tra xBSD e Linux 2.4 che mi secca di più è che la
valutazione delle opzioni tcp in netfilter è ancora in fase sperimentale
mentre per ipfilter è una funzionalità matura. Molti danno molto peso al fatto
che il filtraggio e l'inoltro degli xBSD sia più performante ma Linux può
essere ricompilato con diverse ottimizzazioni e, comunque, per le connessioni
a bassa velocità ritengo che la differenza non sia comunque apprezzabile.
Purtroppo non ho dei link pronti da darti ma troverai sicuramente qualcosa con
un motore di ricerca.
Fabio

In realtà basta una porta aperta...
Ciao.


 un motore di ricerca.
fatto, grazie :-)
e come risultato direi che OpenBSD si propone come ottimale per sicurezza,
velocita' e affidabilita'.
Ai fatti la conferma... cmq mi aspetta una lunga documentazione sul so e su
ipfilter!
ciao,
Silvia

 Ciao.
Scusa?
Stamattina sono poco perspicace :)
Fabio

Silvia wrote:

hai provatola gnatbox? sta su un dischetto.
www.team2it.com
oppure
www.gnatbox.com
è basata su freebsd ma non è free,
una  versione light perfettamente funnzionante la puoi scaricare dal sito
ciao, Marco

Di Slack ho sempre sentito buone cose (cose buone e terribili! :P )
Io la uso da sempre e non e' la bestiaccia che vogliono far credere. :-)
-- 
BlueRaven
"Information anarchy basically means that
Microsoft cannot charge you for it..."

Falco wrote:

vortex.shellz.net
 (statistiche?)
irc.tiscalinet.it
irc.edisontel.com
chaos.cb3rob.net
 (chaos? che si tratti del famoso gruppo?)