Ciao
Andrea Rinaldi
"Jack" <it76...@yahoo.com> wrote in message
news:9nktlq$kit$1...@serv1.iunet.it...
"Andrea Rinaldi" <a.ri...@gattoblu.it> ha scritto nel messaggio
news:KInn7.165911$TS4.1...@news2.tin.it...
l'ultima è la 65536 credo o qualcosa di simile.
Ciao
Andrea Rinaldi
"Jack" <it76...@yahoo.com> wrote in message
news:9nl1s7$a8n$1...@serv1.iunet.it...
> Mi sfuggono le porte 443 e 3389. Inoltre qual'è l'ultima porta?
> Grazie
>
> "Andrea Rinaldi" <a.ri...@gattoblu.it> ha scritto nel messaggio
> news:KInn7.165911$TS4.1...@news2.tin.it...
> > Di solito si chiudono tutte e poi si aprono solo quelle che servono
tipo:
> > 21
> > 23
> > 25
> > 80
> > 110
> > 443
> > 3389
> > ecc...
> >
> >
> >
> > Ciao
> > Andrea Rinaldi
> >
> > "Jack" <it76...@yahoo.com> wrote in message
> > news:9nktlq$kit$1...@serv1.iunet.it...
> > > Ciao a tutti. Come posso sapere quali porte devo chiudere sul mio
> firewall
> > > per impedire l'utilizzo di applicazioni come messenger, icq e napster?
> C'è
"Andrea Rinaldi" <a.ri...@gattoblu.it> ha scritto nel messaggio
news:3ron7.166131$TS4.1...@news2.tin.it...
Risposta ad un messaggio di Andrea Rinaldi a Jack:
AR> From: a.ri...@gattoblu.it
AR> 443 ssl
AR> 3389 terminal server
AR> l'ultima è la 65536 credo o qualcosa di simile.
65535, sono 65536 porte partendo da 0
Leo
Risposta ad un messaggio di Jack a All:
J> From: it76...@yahoo.com
J> Ho chiuso tutto e ho lasciato aperto solo la 80 e la 21. Tutto
J> sembra
J> funzionare correttamente, tranne una cosa per l'ftp.Riesco a
J> connettermi a qualsiasi server ftp ma questo non riesce a
J> restituirmi
J> l'elenco delle cartelle. Mi hanno detto che c'è un'altra porta da
J> aprire. Mi sapete mica dire quale? Grazie
Devi aprire la porta di DATA dell'ftp che se non erro e' la 20
(preso dal mio /mptn/etc/service)
ftp-data 20/tcp #File Transfer [Default Data]
ftp-data 20/udp #File Transfer [Default Data]
ftp 21/tcp #File Transfer [Control]
ftp 21/udp #File Transfer [Control]
Leo
Ps la 20 viene aperta dal server.... se non va devi fare gli FTP in
passive.
>Grazie. Ho avuto anche un altro problema. Il mio mail server (che è dietro
>al firewall) non riceveva più posta. Riaprendo tutto la posta ha ripreso ad
>arrivare. Dove posso avere sbagliato? Le porte aperte erano
>20-21-23-25-80-110-119.
Il download della posta richiede *solo* la porta 110 (per i
miscredenti: "telnet ipdelpop 23" da prompt dos e vedete che vi
collegate), se non riuscivi a scaricare la posta col firewall, è il
firewall configurato male e/o un firewall da culo.
--
Massimo Bacilieri AKA Crononauta
ulib...@libero.it ; ICQ UIN: 4005815
»»» Un buon antivirus? Disinstallare Outlook Express!!!
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3b9f2f23....@news.libero.it...
>Io ho solo chiuso in uscita le porte dalla 1024 alla 65535 e non ho piu
>ricevuto posta!!
....mmhhhh ah!!! giustamente :-)
la 110 lato server :-)
il quale server cerca di risponderti coi dati che hai richiesto su una
porta del temp range (1024-65535) e non riusciva a mandarteli :-)
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3b9f4dff....@news.libero.it...
>E quindi una soluzione quale potrebbe essere? Quali porte mi conviene
>chiudere e quali lasciare aperte? Il mio obiettivo iniziale è sempre quello
>di inibire l'utilizzo di applicazioni come messenger, winmx o napster per
>risparmiare banda.
Premesso che sarebbe bene tu fossi più preciso sul tipo di rete locale
che hai e sulla sua struttura, in linea di principio se vuoi blindare
tutto, fai una cosa di questo tipo:
in uscita:
-> permetti al traffico locale tcp 1024-65535 di andare verso le porte
20, 21, 25, 53, 80, 110, 119.
-> blocca tutto ciò che da locale vuole andare a porte tcp 1024-65535
remote.
in ingresso:
-> blocca tutto ciò che dall'esterno vuole connettersi alle porte
0-1024 locali (se non hai servizi, non c'è motivo che qualcuno voglia
collegarvisi!).
-> permetti che dall'esterno *solo* le porte 20, 21, 25, 53, 80, 110 e
119 si possano collegare a 1024-65535 locali (per permettere ai server
di rispondere coi dati richiesti).
Se non ho dimenticato qualcosa, in queste condizioni dalla LAN si può
andare *solo* a usare i seguenti servizi:
1) ftp;
2) smtp;
3) dns;
4) http;
5) pop3;
6) nntp.
Ovvero, in poche parole: ftp, spedire e ricevere posta, navigare sul
web, e leggere le news. Ovvio che se hai dei servizi sul tuo server, e
usi quelli, puoi chiudere la corrispondente porta da e per l'esterno.
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3b9f81db....@news.libero.it...
Risposta ad un messaggio di Jack a All:
J> From: it76...@yahoo.com
J> Grazie. Ho avuto anche un altro problema. Il mio mail server (che č
J> dietro al firewall) non riceveva piů posta. Riaprendo tutto la
J> posta
J> ha ripreso ad arrivare. Dove posso avere sbagliato? Le porte aperte
J> erano 20-21-23-25-80-110-119. Grazie.
Beh gli serve solo la 25 per ricevere la posta, pero' se controlli
da dove arriva gli puo' servire la 53 per la risoluzione dns (se il dns
e' esterno)
20-21 nemmeno (Ftp=
23 neppure (telnet)
80 web ? hai anche quello sul server ?
110 pop3 ....
119 e' per i newsgroup e non serrve (se non hai newsgroup da leggere !)
Leo
Risposta ad un messaggio di Crononauta a All:
C> Il download della posta richiede *solo* la porta 110 (per i
C> miscredenti: "telnet ipdelpop 23"
23 ?
25 al limite, o 110 per il pop !
Leo
>Purtroppo il mio firewall è un modello economico (Watchguard Soho) e mi
>consente solamente di aprire o chiudere una porta dall'interno verso
>l'esterno. In entrata ho impostato solamente un NAT sulla porta 80, in modo
>da utilizzare un web server interno, ma questo non mi da problemi.
Allora blocca tutto il traffico che dall'interno vuole *andare* verso
le porte >1024. Dovrebbe essere sufficiente, perché così lasci
l'accesso solo alle porte dei "well known services", dove di norma non
girano i vari messenger, chat et similia che usano porte "non
riservate" (quindi >1024).
Sì hai ragione :-)
mi sono fulminato il cervello, la 23 è per fare il login remoto ;-)
E comunque dimenticavo che occorre una porta >1024 locale per la
connessione, altrimenti il server i dati dove li rimanda? =:-O
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3ba06a11....@news.libero.it...
>Ma era esattamente quello che ho fatto! Cosi facendo però non ricevo piu la
>posta. Dietro al firewall ho un server exchange 5.5 con NAT sulle porte 25 e
>110.
>> Allora blocca tutto il traffico che dall'interno vuole *andare* verso
>> le porte >1024.
Per cortesia, scrivi SOTTO il messaggio cui rispondi, così che ci sia
l'ordine cronologico (sennò non si capisce più niente, dopo).
A questo punto l'unica cosa che ti posso suggerire è quella di
analizzare i log del firewall per capire cosa ferma.
Perché è evidente che non funziona come pensi :-)
Per scaricare la posta, tutto ciò che avviene è il collegamento fra
una porta 1024-65535 locale e la 110 remota.
Qualunque cosa impedisca questo, ti impedirà di scaricare la posta.
Non è che il firewall blocca BIDIREZIONALMENTE il traffico, cioè
indiscriminatamente in entrata e in uscita?
Perché se impedisci locale(1024-65535) -> remota(110) ma
contemporaneamente anche l'inverso, capisci subito che non va più
niente...
> On Wed, 12 Sep 2001 20:07:43 GMT, "Jack" <it76...@yahoo.com> wrote:
>
> >Purtroppo il mio firewall è un modello economico (Watchguard Soho) e mi
> >consente solamente di aprire o chiudere una porta dall'interno verso
> >l'esterno. In entrata ho impostato solamente un NAT sulla porta 80, in modo
> >da utilizzare un web server interno, ma questo non mi da problemi.
>
> Allora blocca tutto il traffico che dall'interno vuole *andare* verso
> le porte >1024. Dovrebbe essere sufficiente, perché così lasci
> l'accesso solo alle porte dei "well known services", dove di norma non
> girano i vari messenger, chat et similia che usano porte "non
> riservate" (quindi >1024).
>
tenendo presente che potresti non riuscire a visualizzare
tutti quei siti web che con redirect usano
delle porte diverse dalla 80 (8080, 8000 ecc ecc )
Lyl
--
Posted from [212.17.216.53]
via Mailgate.ORG Server - http://www.Mailgate.ORG
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3ba0a0ff....@news.libero.it...
>No, il blocco è solo in uscita, di questo ne sono sicuro.
Ah! Forse ho capito :-)
Se parliamo di flusso di dati, devi bloccare quello in *entrata*,
perché il traffico di dati è in direzione opposta a quello della
connessione :-)
Cioè mi spiego... se io voglio scaricare la posta, mi _collego_ con
una porta 1024-65535 locale alla 110 remota, ma ovviamente i dati che
arrivano provengono *dal* server *verso* il client, quindi dal tuo
punto di vista è un flusso di dati _in ingresso_.
Bisogna sempre fare attenzione a queste cose quando si impostano i
rules dei firewall; dipende da come lavora il firewall.
>Ho parlato con un
>sistemista watchguard e mi ha detto stupito che non posso assolutamente
>chiudere tutte le porte dalla 1024 in avanti, altrimenti è ovvio che non mi
>funzioni piu niente.
No calma un attimo. Se ti dice "blocchi le porte dalla 1024 in avanti"
non ha senso, perché c'è una _profondissima_ differenza a seconda che
queste porte siano locali o remote; e soprattutto se sono per
l'incoming o l'outcoming.
E poi dipende anche la direzione del flusso di dati, se io voglio
navigare nel web ho bisogno che la porta 80 remota possa inviare dati
*in ingresso* alle mie 1024-65535 locali.
>Sinceramente pero' non ne capisco il motivo. Mi ha
>detto che devo chiudere solo le porte utilizzate dalle applicazioni che
>voglio bloccare, ma mi sembra una soluzione alquanto improbabile dato che di
>queste applicazioni ce ne sono a volontà e usano tutte porte diverse....
Questo è un altro discorso, infatti la buona norma è quella di
chiudere solo le porte che ci sono, mentre non ha senso chiudere porte
che non esistono.
Però effettivamente se uno vuole bloccare i programmi di chat, deve
chiudere "ad ampio spettro" perché è impossibile sapere quali vengono
usate... (poi ci sono i casi come icq che usano pressoché tutto lo
spettro possibile).
"Crononauta" <uliss...@libero.it> ha scritto nel messaggio
news:3ba1bbec....@news.libero.it...
>In definitiva...sul firewall ho chiuso tutte lo porte dalla 1024 alla 65535
>in uscita...riesco a navigare ma non ricevo posta...Mi viene da pensare che
>il problema sia il firewall...
Se riesci a ricevere dati dalla porta 80 ma non dalla 110, è
quantomeno anomalo e strano.
Lì l'unica è capire come funziona il firewall, sei sicuro della
programmazione? In che ordine hai messo le rules?
Perché certe volte è importante: abilitare la 80 e chiudere tutto è
diverso da chiudere tutto e abilitare la 80.
Controlla che l'ordine sia giusto.
se permetti ti faccio un esempio concreto ....
DNS_IP="123.452.265.11 123.452.11.789" /* i tuoi dns */
/sbin/ipchains -F input
/sbin/ipchains -P input DENY
# Attivazione DNS (53)
for dns in $DNS_IP
do
/sbin/ipchains -A input -i $INTERFACE -p tcp ! -y -s $dns 53 \
-d $LOCALIP 1024:65535 -j ACCEPT
/sbin/ipchains -A input -i $INTERFACE -p udp -s $dns 53 \
# Attivazione HTTP (80) HTTPS (443)
/sbin/ipchains -A input -i $INTERFACE -p tcp ! -y -s 0/0 80 \
-d $LOCALIP 1024:65535 -j ACCEPT
/sbin/ipchains -A input -i $INTERFACE -p tcp ! -y -s 0/0 443 \
-d $LOCALIP 1024:65535 -j ACCEPT
e cosi' via .... le altre porte che ti potrebbero interessare sono
SMTP (25), POP3 (110), NNTP (119), FTP (20/21)
e poi fai entrare icmp almeno del tipo
0 network-unreachable
3 port-unreachable
11 TOS-network-unreachable
/sbin/ipchains -A input -p icmp -s 0.0.0.0/0 0 -d $LOCALIP -j ACCEPT
/sbin/ipchains -A input -p icmp -s 0.0.0.0/0 3 -d $LOCALIP -j ACCEPT
/sbin/ipchains -A input -p icmp -s 0.0.0.0/0 11 -d $LOCALIP -j ACCEPT
ciao ...
--
Antonio barbone ...... <hind...@tiscalinet.it>
I'm not prejudiced, I hate everyone equally.
sorry ;-)))
si .... vabbuo' .....
0 echo-reply
3 destination-unreachable
11 time-exceeded
scusate, ma a Napoli stanotte non si e' dormito proprio ;-))))
ciao
non ci sono dei DOS sul tipo 3?
Uh? Da quando in qua l'FTP va anche su UDP?
AFAIK, su UDP ci va il TFTP (porta 69)...
--
BlueRaven
Scrivi su USENET? Allora:
# kill -HUP html_posting && modprobe quoting.o
Risposta ad un messaggio di BlueRaven a Leo Pedone:
>>
>> ftp-data 20/tcp #File Transfer [Default Data]
>> ftp-data 20/udp #File Transfer [Default Data]
>> ftp 21/tcp #File Transfer [Control]
>> ftp 21/udp #File Transfer [Control]
B> Uh? Da quando in qua l'FTP va anche su UDP?
B> AFAIK, su UDP ci va il TFTP (porta 69)...
Sinceramente non ci ho fatto caso, ma hai ragione !
Il services pero' e' quello del S.O., non taroccato da me ....
Leo
Cosi', pero', impedisci al suo server Web di funzionare: dovresti permettere
almeno il traffico con porta sorgente 80 e destinazione remota >1024.
Ovvio: come fa il tuo Exchange a rimandare le risposte ai client, se tu
blocchi il traffico in uscita sulle porte effimere?
Il concetto chiave e' che devi permettere il traffico sulle porte effimere
in uscita SOLO se il pacchetto proviene da un servizio che stai offrendo
esplicitamente.
In entrata, invece, blocchi tutto, poi apri selettivamente le porte dei
servizi che offri e quelle effimere, ma solo per i pacchetti che non hanno
il flag SYN impostato (ovvero, che non tentano di iniziare una connessione).
>>Allora blocca tutto il traffico che dall'interno vuole *andare* verso
>>le porte >1024. Dovrebbe essere sufficiente, perché così lasci
>
>Cosi', pero', impedisci al suo server Web di funzionare: dovresti permettere
>almeno il traffico con porta sorgente 80 e destinazione remota >1024.
Mi sfugge qualcosa, ma non mi pareva che avesse parlato di un
webserver interno...
Io avevo capito che voleva impedire che gli utenti della LAN
utilizzassero i vari messenger, netmeeting, napster et similia...
Chiaro che se ha un webserver interno che vuole essere raggiungibile
vale quello che hai detto tu.