# [conf] iptables server intranet lento

## arnor

Ciao forum,

ho un problema credo con iptables

riassunto

macchina gentoo con dischi scsi e raid 1 hardware 

kernel 2.6.10-gentoo-r6

due schede di rete eth0 e eth1

eth0 -> WAN

eth1 -> LAN

iptables configurato per fare da bridge tra le due reti. Con ip_forwarding e nat permetto la navigazione web ai client interni.

Inizialmente non avevo messo alcuni moduli del kernel e non andava con il fw. Ora va ma lento... 

ho installato i seguenti pacchetti:

```
samba 3.0.10

mysql 4.1.8

pure-ftpd 1.0.20-r1

openvpn 1.5.0-r1
```

samba -> funziona perfettamente

mysql -> funziona bene da riga di commando e lentissimo da phpmyadmin. se spengo iptables perfetto.

pure-ftpd -> e' lento ad utenticare su eth1 e su eth0. se spengo iptables è una scheggia.

ssh -> è lento ad autenticare sia su eth1 che eth0. se spengo iptable viaggia bene.

qui di seguito le mie regole su iptables:

```
# Generated by iptables-save v1.2.11 on Mon Mar 14 19:34:35 2005

*nat

:PREROUTING ACCEPT [15510:922633]

:POSTROUTING ACCEPT [1779:81314]

:OUTPUT ACCEPT [89:10304]

[492:38868] -A POSTROUTING -o eth0 -j MASQUERADE 

COMMIT

# Completed on Mon Mar 14 19:34:35 2005

# Generated by iptables-save v1.2.11 on Mon Mar 14 19:34:35 2005

*mangle

:PREROUTING ACCEPT [139653:60583867]

:INPUT ACCEPT [115134:46667638]

:FORWARD ACCEPT [24514:13915944]

:OUTPUT ACCEPT [99964:14657156]

:POSTROUTING ACCEPT [124770:28623792]

COMMIT

# Completed on Mon Mar 14 19:34:35 2005

# Generated by iptables-save v1.2.11 on Mon Mar 14 19:34:35 2005

*filter

:INPUT ACCEPT [52416:25408601]

:FORWARD ACCEPT [23922:13708447]

:OUTPUT ACCEPT [97756:14111766]

[44751:20052702] -A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT 

[175:17987] -A INPUT -m state --state ESTABLISHED -j ACCEPT 

[0:0] -A INPUT -m state --state RELATED -j ACCEPT 

[0:0] -A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT 

[0:0] -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT 

[0:0] -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT 

[0:0] -A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT 

[0:0] -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 

[10:840] -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 5/sec -j ACCEPT 

[158:27604] -A INPUT -i eth1 -j ACCEPT 

[5:220] -A INPUT -i eth0 -p tcp -m tcp --dport 80 -j ACCEPT 

[7:420] -A INPUT -i eth0 -p tcp -m tcp --dport 22 -j ACCEPT 

[33:1980] -A INPUT -i eth0 -p tcp -m tcp --dport 21 -j ACCEPT 

[0:0] -A INPUT -i eth0 -p tcp -m tcp --dport 5241 -j ACCEPT 

[0:0] -A INPUT -i ! eth1 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable 

[0:0] -A INPUT -i ! eth1 -p udp -m udp --dport 67 -j REJECT --reject-with icmp-port-unreachable 

[3361:201548] -A INPUT -i ! eth1 -p tcp -m tcp -j DROP 

[200:29543] -A INPUT -i ! eth1 -p udp -m udp -j DROP 

COMMIT

# Completed on Mon Mar 14 19:34:35 2005

```

L'impressione che manca qualcosa circa le connessioni stabilite oppure l'ordine delle regole influenza la velocità.

Ho trovato diversi guide su come fare delle mezze configurazioni di iptables ma 

L'idea finale sarebbe lasciare aperte 3 porte: 21(ftp),80(http),5241(openvpn)

tramite la vpn entro per amministrare la macchina in ssh.  

grazie a tutti in anticipo per idee o suggerimenti.

Ciao Lorenzo

Edit gutter: usiamo i bbcode

----------

## xchris

o vedo male io o hai le policy di default su ACCEPT e poi fai delle regole specifiche di ACCEPT.

Che senso ha?

La strada migliore e' quello di mettere le policy di default su DROP e consentire quello che vuoi con le regole specifiche.

Se non mastichi molto di iptables ti consiglio vivamente shorewall (anche se lo mastichi)  :Smile: 

ciao

(solitamente i problemi di lentezza sono dovuti alla risoluzione dei nomi..)

ciao

----------

## gutter

 *xchris wrote:*   

> 
> 
> Se non mastichi molto di iptables ti consiglio vivamente shorewall (anche se lo mastichi) 
> 
> 

 

Concordo  :Smile: . Lo sto provando da un paio di giorni e mi sto stupendo della sua versatilità.

----------

## codadilupo

io vorrei provarlo, ma c'ho capito meno che di iptables (e di iptables c'ho capito lo 0,01%  :Wink: )

Coda

----------

## gutter

 *codadilupo wrote:*   

> io vorrei provarlo, ma c'ho capito meno che di iptables (e di iptables c'ho capito lo 0,01% )
> 
> 

 

Il mio consiglio è di leggerti gli ottimi howto. In un paio d'ore tiri fuori una configurazione funzionante  :Wink: 

----------

## xchris

e appena lo mastichi configuri una macchina desktop in circa 2 minuti  :Very Happy: 

ma la potenza secondo me sta' tutta nella sua versatilita'.

Lavorare con n-interfacce (con n>3) senza problemi e' una cosa fantastica  :Very Happy: 

senza parlare del supporto per proxyarp e cosette del genere  :Smile: 

Sarebbe carino fare una noob guide anche se shorewall gia' di suo ha un ottima documentazione sul sito.

Una doc che spiega i concetti ultra-base.Volontari?  :Laughing: 

----------

## gutter

 *xchris wrote:*   

> 
> 
> Una doc che spiega i concetti ultra-base.Volontari? 

 

Su questo forum in genere la guida la fa chi la propone  :Very Happy: 

Quindi aspettiamo con ansia un tuo "capolavoro"  :Wink: 

----------

## xchris

arg no.... anfame  :Very Happy: 

shorewall e' molto ben documentato in inglese...

non ci credo che non ci sia nulla in italiano.

Io posso fare una guida veramente minimale....

coprire tutto shorewall mi porterebbe via un anno  :Laughing: 

ciao

----------

## .:chrome:.

 *xchris wrote:*   

> La strada migliore e' quello di mettere le policy di default su DROP e consentire quello che vuoi con le regole specifiche.
> 
> Se non mastichi molto di iptables ti consiglio vivamente shorewall (anche se lo mastichi) 

 

sono d'accordo sulla policy. quando faccio un firewall metto tutto un drop (ma proprio tutto) e poi apro solo ai servizi che mi interessano.

non concordo su shorewall. si tratta di un tool che alla fine maneggia ancora iptables. un intermediario secondo me poco utile e che aggiunge altro lavoro di gestione. personalmente preferisco avere meno tool possibili (e poi così ti fai pure le ossa).

se posso permettermi un consiglio, io cercherei una guida basilare per netfilter, giusto per capire il funzionamento generale, e poi cercherei di raffinare sempre più. tutto quello che ti serve lo trovi in man iptables  :Smile: 

----------

## xchris

guarda...

di netfilter ne ho visto abbastanza.

Io ero della tua stessa opinione fino a quando ho dovuto configurare dei Firewall che terminavano VPN openvpn,pptpd multizona ( n=5)

Con iptables puro penso che sarei invecchiato dal cliente.  :Laughing: 

(anche perche' dovevo pure lavorare con ebtables)

Con shorewall e' stata una bazzecola (o quasi).

Il punto e' che con shorewall il debug e' velocissimo... 

Un mio caro amico mi ha consigliato shorewall e all'inzio ero scettico come te.

Dopo averlo visto un po'... bhe non c'e' storia proprio.

Di base shorewall crea le regole in modo dinamico e aggiungere una nuova zona e' semplice e non richiede la modifica dello script iptables in + parti.

E' comunque buona norma capire il funzionamento di iptables e poi per comodita' usare un tool se si  devono gestire n-firewall.

Cmq... come sempre IMHO.

----------

## gutter

 *k.gothmog wrote:*   

> 
> 
> non concordo su shorewall. si tratta di un tool che alla fine maneggia ancora iptables. un intermediario secondo me poco utile e che aggiunge altro lavoro di gestione. personalmente preferisco avere meno tool possibili (e poi così ti fai pure le ossa).

 

Credo che shorewall sia un tool che permetta di mantenere e configurare in maniera semplice un firewall; questo non implica che si debba sconoscere netfilter/iptables. Io l'ho trovato davvero comodo. 

Ringrazio ancora xchris per il suggerimento  :Wink: 

----------

## fat_penguin

Voglio fare un po la voce fuori dal coro, senza pero' senza entrare in polemica.

Personalmente non uso nessuna interfaccia grafica per configurare netfilter, preferisco creare uno script con i comandi "iptables"... penso che in questo modo si abbia la massima flessibilità e inoltre  risulta molto comodo da leggere e da modificare... E' solo questione di capire i concetti di base!

... cmq si sa... per me potrebbero anche togliere X  :Wink: 

byebye

fat_penguin

----------

## codadilupo

 *fat_penguin wrote:*   

> preferisco creare uno script con i comandi "iptables"... penso che in questo modo si abbia la massima flessibilità e inoltre  risulta molto comodo da leggere e da modificare... E' solo questione di capire i concetti di base!

 

no, non é solo questione di capire i concetti: io ho capito le catene, e so da dove volgio far passare un pacchetto, quando e come maneggiarlo, rifutarlo etc. ma poi 'ste cose le devi anche fare: e se non conosci tutte le porte che devi conoscere (tolte le ovvie, dalla 21 alla 80  :Wink: ) diventa un mezzo casino, anche perché nulla é piu' facile che mettere regole in contrasto fra di loro  :Wink: 

 *Quote:*   

> Personalmente non uso nessuna interfaccia grafica per configurare netfilter

 

ehmm... shorewall non é grafico  :Wink: 

Coda

----------

## fat_penguin

@coda: ops, il grafico mi era sfuggito... 

Potremmo discutere all'infinito su cosa sia meglio o peggio... senza mai giungere ad una conclusione visto che ognuno ha la sua testa e le sue opinioni. 

Quello che mi spaventa un po invece (e vado un pelo OT) è vedere che molta gente pensa che questi tools sopperiscano alla loro carenza  di conoscenza del protocollo IP, di netfilter e dei fondamenti di networking. Spesso vedo persone lanciarsi "a panza" nella configurazione di firewall (con successo a volte...) senza avere la minma idea di cio che sta facendo... Fin che la cosa si limita ad un "gioco" casalingo va tutto bene... ma occhio a non peccare di presunzione!

byebye

fat_penguin

----------

## codadilupo

 *fat_penguin wrote:*   

> @coda: ops, il grafico mi era sfuggito... 
> 
> Potremmo discutere all'infinito su cosa sia meglio o peggio... senza mai giungere ad una conclusione visto che ognuno ha la sua testa e le sue opinioni. 
> 
> Quello che mi spaventa un po invece (e vado un pelo OT) è vedere che molta gente pensa che questi tools sopperiscano alla loro carenza  di conoscenza del protocollo IP, di netfilter e dei fondamenti di networking. Spesso vedo persone lanciarsi "a panza" nella configurazione di firewall (con successo a volte...) senza avere la minma idea di cio che sta facendo... Fin che la cosa si limita ad un "gioco" casalingo va tutto bene... ma occhio a non peccare di presunzione!

 

hai perfettamente ragione: ma considera che non c'e' altro modo di sapere queste cose, se non sapendole  :Wink: 

Voglio dire, con tutta la documentazione libera che c'e', spesso mi imbatto in questioni fuori dalla mia capacità di comprensione: shorewall, che come ho detto ho trovato piu' incasinato di iptables (ma che ieri sera sono riuscito a configurare: alleluja !!!) facilità questo tipo di problemi, anche perché ti dice lui cosa vuol dire packet filtering, tcpdump etc.. sono d'accordo sul non fare bungee jumping senza un elastico attorcigliato in vita, ma non credo, per quanto ho sentito parlare di shorewall qui e altrove, che sia questo il caso  :Wink: 

Coda

----------

## xchris

 *fat_penguin wrote:*   

> Quello che mi spaventa un po invece (e vado un pelo OT) è vedere che molta gente pensa che questi tools sopperiscano alla loro carenza  di conoscenza del protocollo IP, di netfilter e dei fondamenti di networking. Spesso vedo persone lanciarsi "a panza" nella configurazione di firewall (con successo a volte...) senza avere la minma idea di cio che sta facendo... Fin che la cosa si limita ad un "gioco" casalingo va tutto bene... ma occhio a non peccare di presunzione!
> 
> 

 

si e no...

ti faccio un esempio

io so configurare bridge,proxyarp e cose simili..

Quando mi reco dai miei clienti una configurazione con shorewall e' + veloce (e' inutile che configuri un proxy-arp 50 volte... ormai ho capito come si fa  :Wink: )

Poi... da non trascurare.. e' + mantenibile!

Uno script iptables per quanto bene sia fatto non e' cosi' chiaro come una configurazione di shorewall.

E' piu' sicuro a mio avviso.Il team che lo ha sviluppato e' sicuramente molto competente e la miriade di utenti che la usano fanno testing e inondano le mailing-list di configurazioni tipo,suggerimenti... critiche...ecc .ecc

Non voglio (e non lo faccio) dubitare della tua abilita' a scrivere script iptables ma sappiamo tutti che e' facile sbagliare.

E mantenere nel tempo uno script che per diverse esigenze deve essere modificato non e' banale.

Altro aspetto degno di nota..

Se vogliamo che linux si diffonda e' bene che ci sia qualche tipo di semplificazione.

Non e' detto che per forza debba fare un Cisco Training per utilizzare linux in sicurezza  :Smile: 

Perche' mi piace tanto shorewall?

- per l'utente inesperto limita moltissimo i danni e gli permette di non inbarcarsi in quel incubo di iptables (la prima volta non vi siete spaventati? NO? non ci credo)

- per l'utente esperto e' una manna dal cielo. Mi permette di andare a casa prima in tutta sicurezza a giocare con il mio bimbo invece di passare la notte su uno script dove per errore ho invertito 2 righe  :Laughing: 

Vorrei ripetermi: la pensavo esattamente come te e i firewall li facevo solo con miei script. Provato shorewall... mai + senza!

Per quanto riguarda la guida.. non so se ha senso vista la documentazione ottima che c'e' e cmq l'impossibilita di fare una guida esauriente.Che ne dite?

Ciao

----------

## grentis

Ma c'è qualcosa in italiano da qualche parte?

Io ora uso script per iptables ma se dite che è così comodo shorewall... :Laughing: 

----------

## arnor

grazie a tutti per i suggerimenti. Penso che approfondirò shorewall, un utility che non conoscevo.

Quanto ha iptables ho provedduro a scaricare la documentazione... non rimane che leggerla  :Smile: 

ciao lo

----------

## xchris

ho provato a fare una guida semplice.

E' solo una intro e non vuole in nessun modo coprire l'argomento.

Mi auguro che sia piu' che altro uno stimolo per andare a vedere la documentazione ufficiale  :Smile: 

In futuro includero' qualche altra configurazione tipica.

Sono una chiavica a scrivere guide.

In caso di inesattezze o parti poco chiare scivetemi/postate pure  :Smile: 

http://www.xchris.net/index.php?page=Shorewall_1

ciauz

EDIT:dimenticavo di ringraziare gutter e earcar per aver letto la prima parte  :Smile: 

----------

## arnor

Domani pomeriggio conto di essere un tester della tua guida.  :Smile: 

Al momento l'ho letta e mi sembra utile con ottimi spunti.

Una sola domanda.

In che modo shorewall tocca i settaggi di iptables che sono stati già stati inseriti es. ip_forwarding nel file /etc/sysctl.conf

Magari nell'introduzione due righe in più su come shorewall si interfaccia a iptables da un punto di vista più tecnico farebbero stare più tranquilli che ci mette le mani per la prima volta.

Ciao lorenzo

----------

## xchris

shorewall controlla l'ip_forwarding con entry in shorewall.conf

Diciamo che tutti i punti "critici" vengono sovrascritti da shorewall.

Per maggiorni info guarda il codice direttamente.

Come si interfaccia? In che senso?

semplicemente esegue una serie di iptables bla bla bla  :Smile: 

o forse non ho capito la domanda  :Smile: 

----------

## grentis

xchris sei un tesoro... :Laughing: 

grazie mille per la guida!

----------

## xchris

 :Smile: 

Chiamarla guida e' un po' troppo.

Direi che e' un introduzione.

Dovrebbe mostrare in modo semplice come "ragiona" shorewall.

Una volta presa la mano diventa veramente facile aggiornare il proprio firewall.

Ciao  :Smile: 

----------

## arnor

ottima guida/introduzione!  :Wink: 

Ora ho il fw up sul portatile. Peraltro con "#shorewall check" mi ha segnalato gentilmente di compilare iptables che era meglio  :Wink: 

apparte la mia sbadatagine sarebbe carino segnalare nella parte iniziali quali moduli del kernel devono essere presenti.

Domani proverò ad usarlo su un server che sto preparando dove le problematiche sono un po' più complesse... cmq sono fiducioso  :Smile: 

grazie ancora Lorenzo

----------

## xchris

mettero' magari solo un avviso che serve avere il kernel compilato adeguatamente.

Ogni configurazione puo' richiedere una diversa configurazione e quindi non ho proprio voglia di impazzire dietro ai moduli (o -) da mettere.

Sono contento che sia andato tutto bene  :Smile: 

Che tipo di server e'? quale utilizzo?

----------

## rota

bella pero ricordiamoci  unacosa .. che qualsiasi sia il firewall dobbiamo vedere qaunta memoria a  di defoult  la cache ( creddo che si chiami cosi .. ) perche  probabilmente la lentezza di iptables dipende da questo ..cioe che a finito la cache a suadisposizzione..

o io creddo di vere detto una cosa sensata.. pero da profano posso  sbagliare .che nessuno me ne voglia

----------

## xchris

la cache di cosa?

Non mi pare proprio che iptables abbia dei requisiti esosi di sistema.

Un 486 gia' fa il suo dovere senza problemi  :Rolling Eyes: 

che intendi?

ciao

----------

## arnor

per ora ho fatto il portatile, questo pomeriggio spero di riuscire a mettere le mani sul server.

la macchina server ha 2 interfacce di rete eth0 e eth1

eth0 -> WAN

eth1 -> LAN

su eth0 tutto chiuso tranne openvpn,ftp, https

su eth1 che apre sulla rete LAN interna abilitare una navigazione full verso l'esterno e l'accesso a diversi servizi:

- samba

- ssh

- cvsd

- http

non credo che ci metterò 5' ma l'obbiettivo è questo  :Smile: 

ciao lorenzo

----------

## xchris

per openvpn usa il file /etc/shorewall tunnel  :Smile: 

ciao

----------

## arnor

sul portatile ho configurato e funziona egregiamente.

C'è solo una cosa che non capisco. Nel file /etc/shorewall/rules ho inserito queste righe:

####################################################################################################

#ACTION  SOURCE         DEST            PROTO   DEST    SOURCE     ORIGINAL     RATE            USER/

#                                               PORT    PORT(S)    DEST         LIMIT           GROUP

ACCEPT  net             all             tcp    22,80

ACCEPT  net             all             icmp

ho fatto un nmap e mi risulta che c'è aperta la porta 143. perchè?  è un default?

cmq se ho detto chiudi tutto non dovebbe farlo?  :Smile: 

cmq grazie. Ora provo sul server  :Smile: 

ciao lorenzo

----------

## xchris

premesso che quelle regole andrebbero modificate...

net all e' sempre da evitare!

meglio

net fw .....

dovrei vedere la config per valutare...

se fai un tar.gz e me lo mandi ti posso aiutare.

oppure posta i soliti 3-4 file  :Smile: 

ciao

----------

## arnor

sono molto soddisfatto, dopo 1 ora ho gia la macchina configurata e funzionante. Mi manca capire alcuni dettagli.

questo il mio scan con nmap:

```
PORT    STATE  SERVICE

21/tcp  open   ftp

22/tcp  open   ssh

113/tcp closed auth

443/tcp closed https
```

tutto giusto tranne la porta 113 che io non ho aperto... almeno non volontariamente.

i miei file di configurazione che ho toccato:

/etc/shorewall/zones

```
#ZONE   DISPLAY         COMMENTS

net     Net             Internet

loc     Local           Local networks

```

/etc/shorewall/interfaces

```
#ZONE    INTERFACE      BROADCAST       OPTIONS

net     eth0    192.168.2.255

loc     eth1    192.168.3.255
```

/etc/shorewall/policy

```
#SOURCE         DEST            POLICY          LOG             LIMIT:BURST

#                                               LEVEL

loc             net             ACCEPT

net             all             DROP            info

#

# THE FOLLOWING POLICY MUST BE LAST

#

all             all             REJECT          info

#LAST LINE -- DO NOT REMOVE
```

/etc/shorewall/rules

```
####################################################################################################

#ACTION  SOURCE         DEST            PROTO   DEST    SOURCE     ORIGINAL     RATE            USER/

#                                               PORT    PORT(S)    DEST         LIMIT           GROUP

ACCEPT  net             fw             tcp    21,443,22

ACCEPT  net             fw             icmp

ACCEPT  fw              net

ACCEPT  loc             net

ACCEPT  loc             fw
```

/etc/shorewall/masq

```

###############################################################################

#INTERFACE              SUBNET          ADDRESS         PROTO   PORT(S)

eth0    eth1

```

/etc/shorewall/shorewall.conf

```

##############################################################################

#  /etc/shorewall/shorewall.conf V2.0 - Change the following variables to

#  match your setup

#

#  This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]

#

#  This file should be placed in /etc/shorewall

#

#  (c) 1999,2000,2001,2002,2003,2004 - Tom Eastep (teastep@shorewall.net)

##############################################################################

#                              L O G G I N G

##############################################################################

#

# General note about log levels. Log levels are a method of describing

# to syslog (8) the importance of a message and a number of parameters

# in this file have log levels as their value.

#

# Valid levels are:

#

#   7   debug

#   6   info

#   5   notice

#   4   warning

#   3   err

#   2   crit

#   1   alert

#   0   emerg

#

# For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall

# log messages are generated by NetFilter and are logged using facility

# 'kern' and the level that you specifify. If you are unsure of the level

# to choose, 6 (info) is a safe bet. You may specify levels by name or by

# number.

#

# If you have built your kernel with ULOG target support, you may also

# specify a log level of ULOG (must be all caps). Rather than log its

# messages to syslogd, Shorewall will direct netfilter to log the messages

# via the ULOG target which will send them to a process called 'ulogd'.

# ulogd is available from http://www.gnumonks.org/projects/ulogd and can be

# configured to log all Shorewall message to their own log file

################################################################################

#

# LOG FILE LOCATION

#

# This variable tells the /sbin/shorewall program where to look for Shorewall

# log messages. If not set or set to an empty string (e.g., LOGFILE="") then

# /var/log/messages is assumed.

#

# WARNING: The LOGFILE variable simply tells the 'shorewall' program where to

#          look for Shorewall messages.It does NOT control the destination for

#          these messages. For information about how to do that, see

#

#              http://www.shorewall.net/shorewall_logging.html

LOGFILE=/var/log/shorewall/shorewall.log

#

# LOG FORMAT

#

# Shell 'printf' Formatting template for the --log-prefix value in log messages

# generated by Shorewall to identify Shorewall log messages. The supplied

# template is expected to accept either two or three arguments; the first is

# the chain name, the second (optional) is the logging rule number within that

# chain and the third is the ACTION specifying the disposition of the packet

# being logged. You must use the %d formatting type for the rule number; if your

# template does not contain %d then the rule number will not be included.

#

# If you want to integrate Shorewall with fireparse, then set LOGFORMAT as:

#

#   LOGFORMAT="fp=%s:%d a=%s "

#

# If not specified or specified as empty (LOGFORMAT="") then the value

# "Shorewall:%s:%s:" is assumed.

# 

# CAUTION: /sbin/shorewall uses the leading part of the LOGFORMAT string (up 

# to but not including the first '%') to find log messages in the 'show log',

# 'status' and 'hits' commands. This part should not be omitted (the 

# LOGFORMAT should not begin with "%") and the leading part should be

# sufficiently unique for /sbin/shorewall to identify Shorewall messages.

LOGFORMAT="Shorewall:%s:%s:"

#

# LOG RATE LIMITING

#

# The next two variables can be used to control the amount of log output

# generated. LOGRATE is expressed as a number followed by an optional

# `/second',  `/minute', `/hour', or `/day' suffix and specifies the maximum

# rate at which a particular message will occur. LOGBURST determines the

# maximum initial burst size that will be logged. If set empty, the default

# value of 5 will be used.

#

# If BOTH variables are set empty then logging will not be rate-limited.

#

# Example:

#

#   LOGRATE=10/minute

#   LOGBURST=5

#

# For each logging rule, the first time the rule is reached, the packet

# will be logged; in fact, since the burst is 5, the first five packets

# will be logged. After this, it will be 6 seconds (1 minute divided by

# the rate of 10) before a message will be logged from the rule, regardless

# of how many packets reach it. Also, every 6 seconds which passes without

# matching a packet, one of the bursts will be regained; if no packets hit

# the rule for 30 seconds, the burst will be fully recharged; back where

# we started.

#

LOGRATE=10/minute

LOGBURST=5

 

#

# BLACKLIST LOG LEVEL

#

# Set this variable to the syslogd level that you want blacklist packets logged

# (beware of DOS attacks resulting from such logging). If not set, no logging

# of blacklist packets occurs.

#

# See the comment at the top of this section for a description of log levels

#

BLACKLIST_LOGLEVEL=

#

# LOGGING 'New not SYN' rejects

#

# This variable only has an effect when NEWNOTSYN=No (see below).

#

# When a TCP packet that does not have the SYN flag set and the ACK and RST

# flags clear then unless the packet is part of an established connection,

# it will be rejected by the firewall. If you want these rejects logged,

# then set LOGNEWNOTSYN to the syslog log level at which you want them logged.

#

# See the comment at the top of this section for a description of log levels

#

# Example: LOGNEWNOTSYN=debug

LOGNEWNOTSYN=info

#

# MAC List Log Level

#

# Specifies the logging level for connection requests that fail MAC

# verification. If set to the empty value (MACLIST_LOG_LEVEL="") then

# such connection requests will not be logged.

#

# See the comment at the top of this section for a description of log levels

#

MACLIST_LOG_LEVEL=info

#

# TCP FLAGS Log Level

#

# Specifies the logging level for packets that fail TCP Flags

# verification. If set to the empty value (TCP_FLAGS_LOG_LEVEL="") then

# such packets will not be logged.

#

# See the comment at the top of this section for a description of log levels

#

TCP_FLAGS_LOG_LEVEL=info

#

# RFC1918 Log Level

#

# Specifies the logging level for packets that fail RFC 1918

# verification. If set to the empty value (RFC1918_LOG_LEVEL="") then

# RFC1918_LOG_LEVEL=info is assumed.

#

# See the comment at the top of this section for a description of log levels

#

RFC1918_LOG_LEVEL=info

#

# SMURF Log Level

#

# Specifies the logging level for smurf packets dropped by the

#'nosmurfs' interface option in /etc/shorewall/interfaces and in

# /etc/shorewall/hosts. If set to the empty value ( SMURF_LOG_LEVEL=""

# ) then dropped smurfs are not logged. 

#

# See the comment at the top of this section for a description of log levels

#

SMURF_LOG_LEVEL=info

#

# BOGON Log Level

#

# Specifies the logging level for bogon packets dropped by the

#'nobogons' interface option in /etc/shorewall/interfaces and in

# /etc/shorewall/hosts. If set to the empty value

# ( BOGON_LOG_LEVEL="" ) then packets whose TARGET is 'logdrop'

# in /usr/share/shorewall/bogons are logged at the 'info' level.

#

# See the comment at the top of this section for a description of log levels

#

BOGON_LOG_LEVEL=info

################################################################################

#       L O C A T I O N   O F   F I L E S   A N D   D I R E C T O R I E S

################################################################################

#

# PATH - Change this if you want to change the order in which Shorewall

#        searches directories for executable files.

#

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin

#

# SHELL

#

# The firewall script is normally interpreted by /bin/sh. If you wish to change

# the shell used to interpret that script, specify the shell here.

SHOREWALL_SHELL=/bin/sh

# SUBSYSTEM LOCK FILE

#

# Set this to the name of the lock file expected by your init scripts. For

# RedHat, this should be /var/lock/subsys/shorewall. If your init scripts don't

# use lock files, set this to "".

#

SUBSYSLOCK=/var/lock/subsys/shorewall

#

# SHOREWALL TEMPORARY STATE DIRECTORY

#

# This is the directory where the firewall maintains state information while

# it is running

#

STATEDIR=/var/lib/shorewall

#

# KERNEL MODULE DIRECTORY

#

# If your netfilter kernel modules are in a directory other than

# /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter then specify that

# directory in this variable. Example: MODULESDIR=/etc/modules.

MODULESDIR=

#

# CONFIGURATION SEARCH PATH

#

# This option holds a list of directory names separated by colons

# (":"). Shorewall will search each directory in turn when looking for a

# configuration file. When processing a 'try' command or a command

# containing the "-c" option, Shorewall will automatically add the

# directory specified in the command to the front of this list.

#

# If not specified or specified as null ("CONFIG_PATH=""),

# CONFIG_PATH=/etc/shorewall:/usr/share/shorewall is assumed.

CONFIG_PATH=/etc/shorewall:/usr/share/shorewall

#

# RESTORE SCRIPT

#

# This option determines the script to be run in the following cases:

#

# shorewall -f start

# shorewall restore

# shorewall save

# shorewall forget

#   Failure of shorewall start or shorewall restart

#

# The value of the option must be the name of an executable file in the

# directory /var/lib/shorewall. If this option is not set or if it is

# set to the empty value (RESTOREFILE="") then RESTOREFILE=restore is

# assumed.

RESTOREFILE=

################################################################################

#                       F I R E W A L L   O P T I O N S

################################################################################

# NAME OF THE FIREWALL ZONE

#

# Name of the firewall zone -- if not set or if set to an empty string, "fw"

# is assumed.

#

FW=fw

#

# ENABLE IP FORWARDING

#

# If you say "On" or "on" here, IPV4 Packet Forwarding is enabled. If you

# say "Off" or "off", packet forwarding will be disabled. You would only want

# to disable packet forwarding if you are installing Shorewall on a

# standalone system or if you want all traffic through the Shorewall system

# to be handled by proxies.

#

# If you set this variable to "Keep" or "keep", Shorewall will neither

# enable nor disable packet forwarding.

#

IP_FORWARDING=On

#

# AUTOMATICALLY ADD NAT IP ADDRESSES

#

# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses

# for each NAT external address that you give in /etc/shorewall/nat. If you say

# "No" or "no", you must add these aliases youself.

#

ADD_IP_ALIASES=Yes

#

# AUTOMATICALLY ADD SNAT IP ADDRESSES

#

# If you say "Yes" or "yes" here, Shorewall will automatically add IP addresses

# for each SNAT external address that you give in /etc/shorewall/masq. If you say

# "No" or "no", you must add these aliases youself. LEAVE THIS SET TO "No" unless

# you are sure that you need it -- most people don't!!!

#

ADD_SNAT_ALIASES=No

#

# ENABLE TRAFFIC SHAPING

#

# If you say "Yes" or "yes" here, Traffic Shaping is enabled in the firewall. If

# you say "No" or "no" then traffic shaping is not enabled. If you enable traffic

# shaping you must have iproute[2] installed (the "ip" and "tc" utilities).

TC_ENABLED=No

#

# Clear Traffic Shapping/Control

#

# If this option is set to 'No' then Shorewall won't clear the current

# traffic control rules during [re]start. This setting is intended

# for use by people that prefer to configure traffic shaping when

# the network interfaces come up rather than when the firewall

# is started. If that is what you want to do, set TC_ENABLED=Yes and

# CLEAR_TC=No and do not supply an /etc/shorewall/tcstart file. That

# way, your traffic shaping rules can still use the 'fwmark'

# classifier based on packet marking defined in /etc/shorewall/tcrules.

#

# If omitted, CLEAR_TC=Yes is assumed.

CLEAR_TC=Yes

#

# Mark Packets in the forward chain

#

# When processing the tcrules file, Shorewall normally marks packets in the

# PREROUTING chain. To cause Shorewall to use the FORWARD chain instead, set

# this to "Yes". If not specified or if set to the empty value (e.g.,

# MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No is assumed.

#

# Marking packets in the FORWARD chain has the advantage that inbound

# packets destined for Masqueraded/SNATed local hosts have had their destination

# address rewritten so they can be marked based on their destination. When

# packets are marked in the PREROUTING chain, packets destined for

# Masqueraded/SNATed local hosts still have a destination address corresponding

# to the firewall's external interface.

#

# Note: Older kernels do not support marking packets in the FORWARD chain and

#       setting this variable to Yes may cause startup problems.

MARK_IN_FORWARD_CHAIN=No

#

# MSS CLAMPING

#

# Set this variable to "Yes" or "yes" if you want the TCP "Clamp MSS to PMTU"

# option. This option is most commonly required when your internet

# interface is some variant of PPP (PPTP or PPPoE). Your kernel must

# have CONFIG_IP_NF_TARGET_TCPMSS set.

#

# [From the kernel help:

#

#    This option adds a `TCPMSS' target, which allows you to alter the

#    MSS value of TCP SYN packets, to control the maximum size for that

#    connection (usually limiting it to your outgoing interface's MTU

#    minus 40).

#

#    This is used to overcome criminally braindead ISPs or servers which

#    block ICMP Fragmentation Needed packets.  The symptoms of this

#    problem are that everything works fine from your Linux

#    firewall/router, but machines behind it can never exchange large

#    packets:

#        1) Web browsers connect, then hang with no data received.

#  2) Small mail works fine, but large emails hang.

#  3) ssh works fine, but scp hangs after initial handshaking.

# ]

#

# If left blank, or set to "No" or "no", the option is not enabled.

#

CLAMPMSS=No

#

# ROUTE FILTERING

#

# Set this variable to "Yes" or "yes" if you want kernel route filtering on all

# interfaces started while Shorewall is started (anti-spoofing measure).

#

# If this variable is not set or is set to the empty value, "No" is assumed.

# Regardless of the setting of ROUTE_FILTER, you can still enable route filtering

# on individual interfaces using the 'routefilter' option in the

# /etc/shorewall/interfaces file.

ROUTE_FILTER=No

# DNAT IP ADDRESS DETECTION

#

# Normally when Shorewall encounters the following rule:

#

#   DNAT   net   loc:192.168.1.3   tcp   80

#

# it will forward TCP port 80 connections from the net to 192.168.1.3

# REGARDLESS OF THE ORIGINAL DESTINATION ADDRESS. This behavior is

# convenient for two reasons:

#

#   a) If the the network interface has a dynamic IP address, the

#      firewall configuration will work even when the address

#      changes.

#

#   b) It saves having to configure the IP address in the rule

#      while still allowing the firewall to be started before the

#      internet interface is brought up.

#

# This default behavior can also have a negative effect. If the

# internet interface has more than one IP address then the above

# rule will forward connection requests on all of these addresses;

# that may not be what is desired.

#

# By setting DETECT_DNAT_IPADDRS=Yes, rules such as the above will apply

# only if the original destination address is the primary IP address of

# one of the interfaces associated with the source zone. Note that this

# requires all interfaces to the source zone to be up when the firewall

# is [re]started.

DETECT_DNAT_IPADDRS=No

#

# MUTEX TIMEOUT

#

# The value of this variable determines the number of seconds that programs

# will wait for exclusive access to the Shorewall lock file. After the number

# of seconds corresponding to the value of this variable, programs will assume

# that the last program to hold the lock died without releasing the lock.

#

# If not set or set to the empty value, a value of 60 (60 seconds) is assumed.

#

# An appropriate value for this parameter would be twice the length of time

# that it takes your firewall system to process a "shorewall restart" command.

MUTEX_TIMEOUT=60

#

# NEWNOTSYN

#

# TCP connections are established using the familiar three-way "handshake":

#

#   CLIENT         SERVER

#

#   SYN-------------------->

#            <------------------SYN,ACK

#       ACK-------------------->

#

# The first packet in that exchange (packet with the SYN flag on and the ACK

# and RST flags off) is referred to in Netfilter terminology as a "syn" packet.

# A packet is said to be NEW if it is not part of or related to an already

# established connection.

#

# The NETNOTSYN option determines the handling of non-SYN packets (those with

# SYN off or with ACK or RST on) that are not associated with an already

# established connection.

# 

# If NEWNOTSYN is set to "No" or "no", then non-SYN packets that are not

# part of an already established connection will be dropped by the

# firewall. The setting of LOGNEWNOTSYN above determines if these packets are

# logged before they are dropped.

#

# If NEWNOTSYN is set to "Yes" or "yes" then such packets will not be

# dropped but will pass through the normal rule/policy processing.

#

# Users with a High-availability setup with two firewall's and one acting

# as a backup should set NEWNOTSYN=Yes. Users with asymmetric routing may

# also need to select NEWNOTSYN=Yes.

#

# The behavior of NEWNOTSYN=Yes may also be enabled on a per-interface basis 

# using the 'newnotsyn' option in /etc/shorewall/interfaces and on a

# network or host basis using the same option in /etc/shorewall/hosts.

#

# I find that NEWNOTSYN=No tends to result in lots of "stuck"

# connections because any network timeout during TCP session tear down

# results in retries being dropped (Netfilter has removed the

# connection from the conntrack table but the end-points haven't

# completed shutting down the connection).  I therefore have chosen

# NEWNOTSYN=Yes as the default value.

NEWNOTSYN=Yes

#

# FOR ADMINS THAT REPEATEDLY SHOOT THEMSELVES IN THE FOOT

#

# Normally, when a "shorewall stop" command is issued or an error occurs during

# the execution of another shorewall command, Shorewall puts the firewall into

# a state where only traffic to/from the hosts listed in

# /etc/shorewall/routestopped is accepted. 

#

# When performing remote administration on a Shorewall firewall, it is

# therefore recommended that the IP address of the computer being used for

# administration be added to the firewall's /etc/shorewall/routestopped file.

#

# Some administrators have a hard time remembering to do this with the result

# that they get to drive across town in the middle of the night to restart

# a remote firewall (or worse, they have to get someone out of bed to drive 

# across town to restart a very remote firewall).

#

# For those administrators, we offer ADMINISABSENTMINDED=Yes. With this setting,

# when the firewall enters the 'stopped' state:

#

# All traffic that is part of or related to established connections is still

# allowed and all OUTPUT traffic is allowed. This is in addition to traffic

# to and from hosts listed in /etc/shorewall/routestopped.

#

# If this variable is not set or it is set to the null value then

# ADMINISABSENTMINDED=No is assumed.

#

ADMINISABSENTMINDED=Yes

#

# BLACKLIST Behavior

#

# Shorewall offers two types of blacklisting:

#

# - static blacklisting through the /etc/shorewall/blacklist file together

#   with the 'blacklist' interface option.

#   - dynamic blacklisting using the 'drop', 'reject' and 'allow' commands.

#

# The following variable determines whether the blacklist is checked for each

# packet or for each new connection.

#

#   BLACKLISTNEWONLY=Yes   Only consult blacklists for new connection

#            requests

#

#   BLACKLISTNEWONLY=No   Consult blacklists for all packets.

#

# If the BLACKLISTNEWONLY option is not set or is set to the empty value then

# BLACKLISTNEWONLY=No is assumed.

#

BLACKLISTNEWONLY=Yes

# MODULE NAME SUFFIX

#

# When loading a module named in /etc/shorewall/modules, Shorewall normally

# looks in the MODULES DIRECTORY (see MODULESDIR above) for files whose names

# end in ".o", ".ko", ".gz", "o.gz" or "ko.gz" . If your distribution uses a

# different naming convention then you can specify the suffix (extension) for

# module names in this variable.

#

# To see what suffix is used by your distribution:

#

#     ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter

#

# All of the file names listed should have the same suffix (extension). Set

# MODULE_SUFFIX to that suffix.

#

# Examples: 

#

#   If all file names end with ".kzo" then set MODULE_SUFFIX="kzo"

#   If all file names end with ".kz.o" then set MODULE_SUFFIX="kz.o"

#

MODULE_SUFFIX=

#

# DISABLE IPV6

#

# Distributions (notably SuSE) are beginning to ship with IPV6

# enabled. If you are not using IPV6, you are at risk of being

# exploited by users who do. Setting DISABLE_IPV6=Yes will cause

# Shorewall to disable IPV6 traffic to/from and through your 

# firewall system. This requires that you have ip6tables installed.

DISABLE_IPV6=Yes

#

# BRIDGING

#

# If you wish to control traffic through a bridge (see http://bridge.sf.net),

# then set BRIDGING=Yes. Your kernel must have the physdev match option 

# enabled; that option is available at the above URL for 2.4 kernels and

# is included as a standard part of the 2.6 series kernels. If not

# specified or specified as empty (BRIDGING="") then "No" is assumed.

#

BRIDGING=No

#

# DYNAMIC ZONES

#

# If you need to be able to add and delete hosts from zones dynamically then

# set DYNAMIC_ZONES=Yes. Otherwise, set DYNAMIC_ZONES=No.

DYNAMIC_ZONES=No

#

# USE PKTTYPE MATCH 

#

# Some users have reported problems with the PKTTYPE match extension not being

# able to patch certain broadcast packets. 

#

# Other users have complained of the following message when 

# starting Shorewall:

#

#     modprobe: cant locate module ipt_pkttype

#

# If you set PKTTYPE=No then Shorewallwill use IP addresses to detect

# broadcasts rather than pkttype. If not given or if given as empty

# (PKTTYPE="") then PKTTYPE=Yes is assumed.

PKTTYPE=Yes

################################################################################

#                       P A C K E T   D I S P O S I T I O N

################################################################################

#

# BLACKLIST DISPOSITION

#

# Set this variable to the action that you want to perform on packets from

# Blacklisted systems. Must be DROP or REJECT. If not set or set to empty,

# DROP is assumed.

#

BLACKLIST_DISPOSITION=DROP

#

# MAC List Disposition

#

# This variable determines the disposition of connection requests arriving

# on interfaces that have the 'maclist' option and that are from a device

# that is not listed for that interface in /etc/shorewall/maclist. Valid

# values are ACCEPT, DROP and REJECT. If not specified or specified as

# empty (MACLIST_DISPOSITION="") then REJECT is assumed

MACLIST_DISPOSITION=REJECT

#

# TCP FLAGS Disposition

#

# This variable determins the disposition of packets having an invalid

# combination of TCP flags that are received on interfaces having the

# 'tcpflags' option specified in /etc/shorewall/interfaces or in

# /etc/shorewall/hosts. If not specified or specified as empty

# (TCP_FLAGS_DISPOSITION="") then DROP is assumed.

TCP_FLAGS_DISPOSITION=DROP

#LAST LINE -- DO NOT REMOVE
```

Un altra nota per la tua guida. Se aggiungi due righe sul perchè inserisci la zona fw è una buona cosa. Sul portatile infatti non ho messo fw ma solo loc intendendolo come localhost. quando poi ho configurato il server leggendo il shorewall.conf ho capito cosa intendeva e l'ho aggiunto.

Ho seguito il consiglio di evitare all 2 loc mettendo come mediazione fw.

il proplema della porta 113 aperta lo tengo sia sul server che sul portatile. I file di configurazione sono in relazione del server.

ultima quest poi scrivo il tuo nome sulle finestre,  rimuovo iptables da "rc-update" e metto shorewall oppure vanno lasciati entrambi?

grazie 1000 per la guida e per il supporto 

ciao lorenzo

Edit gutter: usiamo i bbcode

----------

## xchris

alura..

la prossima volta il codice mettilo tra tag [code]  [ / code]

che non si capisce una mazza  :Smile: 

la porta 113 non e' aperta!

e' solo che nel file common.def e' specificato di fare un reject... quindi la macchina che scanna da correttamente closed!

ho notato un errore in rules:

se metti:

zona1 zona2 ACCEPT

mettilo in policy che ha + senso  :Smile: 

riguardo il discorso fw non ho capito cosa intendi  :Smile: 

puoi fare in 2 modi per lo startup script.

o lasci solo shorewall

o lasci iptables con la configuarazione salvata dopo aver lanciato shorewall (+ veloce)

io preferisco lasciare shorewall di default perche' a ogni riavvio mi legge la config aggiornata.

----------

## rota

o solo detto la mia ..... :Embarassed:   :Embarassed: 

pero potrebbe vedere quanta memoria occupano i servizzi aperti no ????

sempre da profano...

----------

## xchris

rota...

non ti ho mica aggredito  :Smile: 

diciamo che quanta memoria portano via i servizi e' qualche cosa che esula dal argomento firewall.

ciao

----------

## rota

ok... soc stato un po permaloso ... :Shocked:   :Shocked:  non me nevolere ...

----------

## AlterX

uhm...se vuoi un mio parere, lascia perdere iptables come modulo nel kernel 

o quasiasi altra forma di automatismo.

Anche perchè cavolo ci sono trentamila regole!!

Io uso iptables separatamente, mi creo il mio scriptino e lo avvio

come servizio. Risultato: 10/15 regole e ora (su mandrake) una scheggia!!

Trasparenza assoluta e nessuna lentezza!

Scarico a banca larga e massimale nonostante il filtraggio/natting

Ora sto ultimando la stessa configurazione con una gentoo (molto più performante perchè da stage1 e prelinkata  :Wink:  )

e la sto per mettere in produzione...

se vuoi ti faccio sapere come va con la gentoo, ma se va come una spada una mandrake, figurati una gentoo!!!  :Wink: 

----------

## xchris

non sono molto d'accordo.

primo: con 15 regole la vedo dura ignorare IP rfc1918

secondo: se lanci shorewall - salvi il tutto con iptables-save che differenza abbiamo in fase di start? 10 ms? ... no troppo

terzo: firewall con 3,4,5,6 zone: 15 regole non bastano di sicuro (a meno che non usi 3 policy di default di DROP  :Laughing: )

(e con shorewall ti assicuro che scrivi molto,molto meno)

Parlare di regole pesanti o meno mi sembra proprio assurdo.

Un 486 che lavori come firewall a 3 zone (e non offra servizi pesanti come VPN) e sempre adeguato.

Il che la dice lunga sulla pesantezza  :Smile: 

Se cerchiamo di snellire la macchina... cerchiamo altrove.. che e' meglio!

del tutto IMHO

ciao

----------

## AlterX

 *xchris wrote:*   

> non sono molto d'accordo.
> 
> primo: con 15 regole la vedo dura ignorare IP rfc1918
> 
> secondo: se lanci shorewall - salvi il tutto con iptables-save che differenza abbiamo in fase di start? 10 ms? ... no troppo
> ...

 

Mah...non so che dirti!

Certo che le mie firewall/nat (due mandrake e una TSL) separate, gestisce tutto il traffico come

ho detto in modo ottimale e se le pinghi non ti rispondono ne accettano connessioni,

semplicemente perchè è tutto droppato su ogni catena di ingresso.

Permette serivizio ssh e di vnc, server web, oltre che di nat per una decina di computer, e sia

su macchine linux che win va come se non ci fosse neanche. Sono due anni che uso

e nessun blocco o tentativo di intrusione.

ovviamente è imho la cosa  :Laughing: 

Inoltre perferisco sempre mettere io le mani sulle configurazioni.

----------

## xchris

scusa...

ma hai su http e vnc e ti preoccupi per il carico delle regole di iptables?  :Rolling Eyes: 

cmq.. ognuno e' libero di pensarla come vuole.

Resta di fatto che iptables non e' uno strumento per tutti.

iptables per la sua totale configurabilita' e' complesso da utilizzare e mantenere

Quindi a mio avviso sia i principianti che gli advanced user possono trarre vantaggio da un tool come shorewall.

ciao

EDIT: nessun tentativo di intrusione? a che serve il firewall?

----------

## AlterX

 *xchris wrote:*   

> scusa...
> 
> ma hai su http e vnc e ti preoccupi per il carico delle regole di iptables? 
> 
> 

 

Non è che li ho su....abbiamo dei servizi, quali posta e web, per cui viene garantito l'accesso da rete esterna

da macchine che ne facciano richiesta; ovviamente ci sono delle regole che stabiliscono dove instradare i pacchetti  :Wink: 

 *Quote:*   

> 
> 
> cmq.. ognuno e' libero di pensarla come vuole.
> 
> Resta di fatto che iptables non e' uno strumento per tutti.
> ...

 

Per il resto la penso come te.  :Laughing: 

----------

## arnor

grazie ho coretto il file con le rules.

Per quanto riguarda la zone "fw" l'incomprensione nasce perchè nel file di gentoo /etc/shorewall/zones di default "fw" non è presente. Viene citato in shorewall.conf

A me questo cosa a inizialmente disorientato.

Tutto qui.... ora mi sto lanciando ad installare il nostro nuovo webserver e userò nuovamente shorewall  :Smile: 

Veramente bello, ancora grazie per avermi fatto conoscere questa utility 

... la vpn l'ho rimandata di qualche giorno perchè mi pare un po' più ostica...  :Wink: 

ciao lo

----------

## xchris

si posso comprendere...

infatti nella guida dicevo che una "zona logica" e' gia' definita di default  :Smile: 

sono contento che lo apprezzi.

Altra cosa comoda... il debug in caso di problemi e' banale  :Wink: 

la vpb con openvpn viene su che e' una bellezza  :Smile: 

Ricorda il file tunnels. (oppure se preferisci avere tutto nelle rules metti ACCET net:altro_host fw udp 5000

ciao

----------

## makoomba

shorewall gestisce anche configurazioni bridged ?

----------

## xchris

dipende a che livello vuoi il firewall...

se vuoi fare filtering sulle 2 (supponiamo) interfacce che fanno il bridge la risposta e' no. (perche' devi usare ebtables)

se e' sufficiente considerare br0 allora si... e' come una qualunque interfaccia.

ciao  :Smile: 

----------

## makoomba

 *xchris wrote:*   

> dipende a che livello vuoi il firewall...
> 
> se vuoi fare filtering sulle 2 (supponiamo) interfacce che fanno il bridge la risposta e' no. (perche' devi usare ebtables)
> 
> se e' sufficiente considerare br0 allora si... e' come una qualunque interfaccia.
> ...

 

con physdev non devi necessariamente utilizzare ebtables per filtrare sulle singole interfacce.

vabbè, allora mi sa che devo continuare ad usare script ad hoc.

----------

## xchris

mi correggo!

non sapevo si potesse fare senza ebtables...

ecco con shorewall:

http://www.shorewall.net/bridge.html

ciao

----------

## makoomba

ok, allora c'è speranza 

grazie per il link

----------

