[WORKLOG] - Installazione e configurazione di un serverino domestico / small office

Pagina 2 di 5
prima
1 2 3 4 5 ultimo
Visualizzazione dei risultati da 11 a 20 su 44
  1. #11
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.3_ Installazione e configurazione di webmin

    Personalmente apprezzo molto il terminale e la configurazione del sistema da linea di comando ma effettivamente qualche volta può risultare ostica o scomoda.
    Esistono diversi tool per l'amministrazione di un sistema da remoto tramite una comoda interfaccia web ed uno di questi è webmin e la sua installazione è tanto semplice da risultare quasi imbarazzante, essendo disponibili binari precompilati per le maggiori distribuzioni...
    Il paccheto non è incluso nel repository di Debian quindi deve essere scaricato ed installato manualmente. apt non è in grado di identificare automaticamente i prerequisiti quindi li installo io manualmente:
    codice:
    sudo apt-get install libapt-pkg-perl libnet-ssleay-perl libauthen-pam-perl libio-pty-perl apt-show-versions
    Quando l'ho fatto io l'ultima versione disponibile era la 1.550, ora c'è già la 1.560. Mi connetto via ssh alla mia linux-box per scaricare il pacchetto ed installarlo, con i comandi:
    codice:
    wget http://prdownloads.sourceforge.net/webadmin/webmin_1.550_all.deb
    per scaricare il pacchetto da installare sul nostro server. Al termine dovremmo trovare il pacchetto di installazione all'interno della directory corrente. Per verificare lanciamo il comando
    codice:
    ls
    (Livorno - Siena) per elencare il contenuto della directory corrente.
    Se il file c'è è possibile procedere all'installazione, con il comando
    codice:
    sudo dpkg -i webmin_1.550_all.deb
    Ora è possibile accedere all'interfaccia web tramite un normale browser usando l'url https://:10000/ e amministrare il sistema. Almeno fino a quando non avrò completato la configurazione del DNS, difficilmente sarà possibile raggiungere il mio server puntandolo col nome, quindi per il momento sostituisco l'URL con l'indirizzo IP. Ovviamente il certificato è autofirmato quindi il browser restituirà il solito errore. Importato il certificato, posso fare login con l'utente root o con qualunque altro utente autorizzato ad utilizzare "sudo".
    Spulciando i menù disponibili ed i moduli installabili, è evidente che webmin è un'interfaccia completa che rende possibile la completa gestione del sistema: Gestione array raid, partizionamento dischi, configurazione utente, servizi ed applicazioni. Un accesso amministrativo a questa interfaccia permette un comodo accesso completo al nostro serverino ed è pertanto raccomandabile un minimo di tuning delle impostazioni dell'interfaccia, sempre per migliorarne la sicurezza.
    Come prima cosa mi creo un utente amministratore e rimuovo root. Dal menù
    "WebMin→ WebMin Users → Root" seleziono "Clone" e creo il nuovo utente denominato "matteo" e setto la password in "Unix Authentication" per utilizzare quella di sistema. E' anche possibile specificarne un'altra. Ora faccio logout e rientro con il nuovo utente. Dal menù "WebMin→ WebMin Users" ora posso eliminare root e verificare che non sia più autorizzato all'accesso.


    Ora dal menù "WebMin→ WebMin Configuration → IP Access control" posso restringere il range di IP autorizzati all'accesso alla sola mia rete locale impostando (nel mio caso) 192.168.100.0/24 per autorizzare all'accesso solo il range di IP da 192.168.100.1 a 192.168.100.254
    Infine dal menù "WebMin→ WebMin Configuration → Ports and Addresses" cambio l'IP di ascolto del programma da "Any address" a "Only address..." specificando l'indirizzo IP della mia porta LAN, in modo che il tool di configurazione non sia raggiungibile dalla rete WAN. Per eccesso di sicurezza possiamo anche cambiare la porta su cui il tool lavora, dalla 10000 ad un'altra porta a piacere, possibilmente sopra la 1024.


    La configurazione forse non sarà perfetta ma dovrebbe essere sufficiente per le mie esigenze, quindi direi che posso prenderla per buona e andare avanti. Ho notato, inoltre, che spesso è bene scegliere un modo di operare e continuare con quello: Ad esempio, operare sul firewall un pò da Webmin e un pò da linea di comando non sempre ha gli esiti sperati...
    Ultima modifica di frakka : 22-08-2011 a 13:09


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #12
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.4_ Configurazione del sistema per operare come router.

    Il serverino dovrà operare come gateway quindi è necessario che sistema operativo sia in grado di effettuare il tipo di NAT (una manipolazione degli indirizzi di rete nei pacchetti in transito) che si chiama "Masquerading" ossia il mascheramento degli indirizzi della rete locale dietro all'IP della macchina router.
    Per fare, questo la solita guida dall'inesauribile sito suggerisce diverse possibilità, io preferisco in questa sede utilizzare la modalità più manuale, principalmente perchè non sono molto pratico di networking e ho necessità di capire bene come funziona la gestione delle reti sul mio sistema, per poterlo anche manutenere quando ce ne sarà necessità.

    Apro il mio terminale e faccio login via ssh sulla mio serverino.
    codice:
     ssh matteo@192.168.100.1
    ora che sono loggato posso anche diventare root. Va bene che non mi piace, ma quasi tutte le operazioni saranno da fare come root, perciò è inutile usare sudo davanti ad ogni comando... Sulla macchina root non è abilitato a loggarsi via ssh ma una volta che l'utente ha fatto login, nessuno mi vieta di cambiare utente con il comando
    codice:
    su
    seguito dalla password di root.

    Ovviamente stò cercando di gestire la macchina via rete e stò cercando di capire come funziona il firewall: E' necessario fare attenzione perchè un comando sbagliato (come una regola troppo restrittiva) potrebbe interrompere la connessione e tagliarmi fuori, obbligandomi a fare login sulla macchina o a riavviarla per annullare la modifica.
    NETFILTER, il componente del kernel di Linux che si occupa di filtrare i pacchetti, è configurato "Live" quindi ogni comando impartito con "iptables" è immediatamente applicato, salvo alcune condizioni particolari. Tali configurazioni vengono però perse al riavvio del sistema ed è pertanto necessario, una volta ottenuto un set di regole adeguato, utilizzare uno script che ad ogni reboot ripassi a netfilter tutte le istruzioni su come gestire il traffico di rete. Intanto però dobbiamo ottenerlo, questo set di istruzioni...

    Il comando
    codice:
    iptables -L
    mostra le regole attualmente definite nel firewall. La policy di default è "ACCEPT" quindi ora il nostro firewall stà accettando tutto il traffico in transito. Il comando
    codice:
    iptables -F
    invece effettua il flush di tutte le regole definite, riportando le policy tutte su "ACCEPT" ed è utile per ripulire la configurazione e rincominciare.

    eth0 è la mia interfaccia pubblica quindi in base alla guida di prima utilizzo il comando
    codice:
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    per abilitare il mascheramento degli IP attraverso questa interfaccia. Dopo aver premuto "Invio" il sistema non restituisce nessun messaggio di errore e questo è generalmente buono.
    Ora il firewall è configurato per il Masquerading dei pacchetti che transitano per eth0 ma la la mia rete locale è collegata su eth1.
    Il sistema deve poter operare come router e quindi essere abilitato a girare i pacchetti in ingresso dalla LAN eth1 che non sono direttamente destinati a lui verso l'interfaccia WAN eth0 e viceversa. Per fare questo è necessario operare su un parametro del kernel definito "ip-forwarding". La modifica si può fare al volo ma andrebbe persa al reboot. Questa preferisco renderla subito permanente quindi faccio una copia di backup del file /etc/sysctl.conf e con il solito editor di testo apporto le necessarie modifiche
    codice:
     cp /etc/sysctl.conf /etc/sysctl.conf.backup
     nano /etc/sysctl.conf
    Come detto in precedenza, per abilitare una riga è sufficiente cancellare il simbolo "#" che la inizia. Ho decommentato/aggiunto le righe in rosso:
    codice:
    #
    # /etc/sysctl.conf - Configuration file for setting system variables
    # See /etc/sysctl.d/ for additonal system variables
    # See sysctl.conf (5) for information.
    #
    
    #kernel.domainname = example.com
    
    # Uncomment the following to stop low-level messages on console
    #kernel.printk = 3 4 1 3
    
    ##############################################################
    # Functions previously found in netbase
    #
    
    # Uncomment the next two lines to enable Spoof protection (reverse-path filter)
    # Turn on Source Address Verification in all interfaces to
    # prevent some spoofing attacks
    net.ipv4.conf.default.rp_filter=1
    net.ipv4.conf.all.rp_filter=1
    
    # Uncomment the next line to enable TCP/IP SYN cookies
    # See http://lwn.net/Articles/277146/
    # Note: This may impact IPv6 TCP sessions too
    net.ipv4.tcp_syncookies=1
    
    # Uncomment the next line to enable packet forwarding for IPv4
    net.ipv4.ip_forward=1
    
    # Uncomment the next line to enable packet forwarding for IPv6
    #  Enabling this option disables Stateless Address Autoconfiguration
    #  based on Router Advertisements for this host
    #net.ipv6.conf.all.forwarding=1
    
    ###################################################################
    # Additional settings - these settings can improve the network
    # security of the host and prevent against some network attacks
    # including spoofing attacks and man in the middle attacks through
    # redirection. Some network environments, however, require that these
    # settings are disabled so review and enable them as needed.
    #
    # Do not accept ICMP redirects (prevent MITM attacks)
    #net.ipv4.conf.all.accept_redirects = 0
    #net.ipv6.conf.all.accept_redirects = 0
    # _or_
    # Accept ICMP redirects only for gateways listed in our default
    # gateway list (enabled by default)
    net.ipv4.conf.all.secure_redirects = 1
    #
    # Do not send ICMP redirects (we are not a router)
    #net.ipv4.conf.all.send_redirects = 0
    # E invece sei un router, quindi mandale!!
    net.ipv4.conf.all.send_redirects = 1
    
    #
    # Do not accept IP source route packets (we are not a router)
    #net.ipv4.conf.all.accept_source_route = 0
    #net.ipv6.conf.all.accept_source_route = 0
    # E invece sei un router, quindi accettale!!
    net.ipv4.conf.all.accept_source_route = 1
    
    #
    # Log Martian Packets
    #net.ipv4.conf.all.log_martians = 1
    #
    
    ## Ignora finti messaggi di errore ICMP
    net.ipv4.icmp_ignore_bogus_error_responses = 1
    ## Non risponde ai ping inviati al broadcast della subnet
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    Per ora IPv6 non mi interessa quindi ignoro le righe relative. Non sò perchè ma la guida di debianizzati usa degli "/" al posto dei "." nei comandi di configurazione. La sintassi corretta però dovrebbero essere i "."
    Dalla guida ho preso solo gli ultimi due comandi e la protezione anti-spoofing: non sono del tutto convinto che la riga
    codice:
    ## Non accetta pacchetti ICMP di route redirection
    net/ipv4/conf/all/accept_redirects = 0
    sia corretta, dovendo operare come router. A questo punto o riavvio il sistema oppure ricarico la configurazione per applicare le modifiche con il comando:
    codice:
    sysctl -p /etc/sysctl.conf


    Per verificare che tutto funzioni il metodo più semplice è provare: Configuro un client per usare il serverino come gateway e provo un trace route. Questo comando mostra tutto il percorso che un pacchetto di rete segue dal pc di partenza ad una specifica destinazione.
    codice:
    tracert www.nexthardware.com
    da un pc Windows oppure da una macchina Linux
    codice:
    traceroute www.nexthardware.com
    Funziona!


    Quello che mi interessa sono sostanzialmente le prime 3 righe: Il primo hop va verso l'IP che ho configurato come gateway (il serverino), il secondo all'IP del mio router Wi-Max su una rete diversa (192.168.50.X invece che la rete 192.168.100.x di partenza) ed il terzo al gateway del mio ISP.
    Se avessi riavviato il serverino per applicare le modifiche che ho fatto al file /etc/sysctl.conf avrei dovuto, prima di provare a navigare, riapplicare il comando iptables che abilitata il Masquerading in quanto, non avendo ancora definito uno script che ricarichi la configurazione di netfilter, il nostro serverino dopo il riavvio non avrebbe applicato il mascheramento degli ip e non ci avrebbe permesso di navigare.
    Il router è pronto!
    Ultima modifica di frakka : 22-08-2011 a 13:10


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #13
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.5.1_ Introduzione a NETFILTER

    Inizio ora la parte forse più importante e delicata per mettere davvero in funzione il mio serverino e cioè il setup del firewall.

    Per quanto se ne dica Linux, al pari di tutti gli altri sistemi operativi, è tutt'altro che invulnerabile alle infiltrazioni indesiderate. E' perfettamente possibile bucare un sistema Linux così come è possibile bucare qualunque altro sistema se questo è mal configurato: Anzi, la disponibilità a tutti del codice sorgente permette a chiunque ne abbia le capacità di analizzare il codice di qualunque software disponibile per il nostro sistema e scoprire eventuali falle o vulnerabilità che possono essere sfruttate per compromettere un sistema. Inoltre, identificare una compromissione (a meno che questa non sia plateale) e ripristinare completamente un sistema Linux è estremamente difficile, forse molto più che non intervenire su un sistema Windows. Proprio perchè il sistema è tutto composto da file di configurazione, script modificabili con un semplice editor di testo e binari di cui è disponibile il sorgente e che possono quindi essere ricompilati a piacere rende quasi impossibile sanificare con sicurezza con sistema a cui un malintenzionato abbia avuto un accesso amministrativo e spesso la soluzione più veloce e sicura è proprio la formattazione e reinstallazione del sistema, con la sostituzione di tutti gli script e i file anche degli stessi dati che compongono, ad esempio, un sito web.
    Stiamo appunto parlando di un sistema che verrà esposto sulla rete pubblica e quando verificheremo i log del nostro sistema non sarà improbabile rilevare ogni giorno le tracce di almeno uno o due tentativi di intrusione...

    Per contrastare questi attacchi il metodo migliore è muoversi in anticipo, riducendo al minimo la superficie d'attacco e cioè lo spettro di possibilità che un eventuale attaccante può sfruttare. Questo significa adottare una serie di accorgimenti che vanno dal non lasciare attivi ed esposti servizi inutili, proteggere al meglio possibile gli accessi al sistema, adottare sistemi di autenticazione efficaci (password lunghe, nomi utente non banali o conosciuti da tutti come "root" appunto) o complessi fino all'adozione di sistemi di ban automatizzato che analizzano i log del sistema e inseriscono tramite iptables dei ban per gli indirizzi IP da cui provengono i potenziali attacchi ma alla base di tutto c'è quindi una corretta implementazione e gestione del firewall.

    netfilter è il componente del kernel Linux che si occupa di fare questo ed iptables lo strumento che mi permette di configurarne il comportamento. Purtroppo netfilter ed iptables sono strumenti molto potenti ma piuttosto complessi quindi se qualcuno avesse delle critiche da muovere alla mia configurazione è pregato di farlo e suggerire le eventuali modifiche.

    Come detto in precedenza, è utile creare uno script da caricare all'avvio che inserisca in netfilter tramite iptables le regole che mi servono. Ci sono in giro un'infinità di guide che suggeriscono possibili configurazioni ma una configurazione standard difficilmente potrà adattarsi a tutti i casi. E' pertanto necessario capire come funziona questo strumento e adattare quello che si trova alle proprie esigenze. Io ho fatto riferimento principalmente a questa guida sempre di debianizzati.org e questo tool che è uno splendido wizard per la generazione di uno script iptables.

    La struttura di netfilter prevede di default tre tabelle ("tables" FILTER, NAT e MANGLE) che a loro volta contengono alcune catene "chain" predefinite. Per la verità è stata introdotta anche un quarta table (RAW) la cui applicazione è però un pò particolare.
    Ogni pacchetto in transito su un sistema attraversa obbligatoriamente una o più tables e nell'ambito di queste una o più chain. Una "chain" è una sequenza di regole che il pacchetto deve attraversare: Quando il pacchetto trova una regola che gli corrisponde subisce l'azione associata alla regola. La tabella "FILTER" è quella che principalmente di occupa dell'analisi del traffico di rete e del firewall, le altre servono principalmente per la configurazione di router più avanzati. Quello che mi interessa ora si trova nelle tabelle "FILTER" e "NAT".

    Intanto devo partire da una situazione nota quindi azzero tutte le regole eventualmente presenti nel firewall:
    codice:
    #Cancellazione delle regole presenti nelle
    #chain predefinite delle tabelle di netfilter
    iptables -t filter -F
    iptables -t nat -F
    iptables -t mangle -F
    iptables -t raw -F
    #Eliminazione delle chain non standard vuote
    iptables -t filter -X
    iptables -t nat -X
    iptables -t mangle -X
    Il comando
    codice:
    iptables -F
    è generalmente equivalente a
    codice:
    iptables -t filter -F
    quindi se non si specifica una table con il parametro "-t" iptables opera sulla tabella "FILTER". Il comando "-F" esegue il flush di tutte le regole nella tabella. In questa configurazione, tutto il traffico di rete è permesso (occhio che anche il masquerading viene cancellato).

    Come prima cosa imposto il firewall per droppare tutte le connessioni su tutte le interfacce di rete. Con questa configurazione, il mio serverino è assolutamente "muto" sulla rete, il firewall scarta tutti i pacchetti di rete in ingresso, uscita e transito senza dare alcuna risposta. E' un metodo in pò brutale ma è più efficace negare tutto e permettere solo quello che mi interessa piuttosto che ragionare al contrario e autorizzare tutto, negando solo quello che non si vuole. In questo modo, a meno che non impostiamo una regola che autorizzi il transito di un determinato tipo di traffico di rete, il pacchetto attraverserà tutta la chain senza trovare corrispondenze e cozzerà contro la policy di default, venendo droppato.

    Uso questi 3 comandi per impostare quindi quella che è la policy di default (per la tabella FILTER) del firewall:
    codice:
    # Imposta le policy predefinite per il sistema
    # Drop di tutte le connessioni in ingresso al sistema
    iptables -P INPUT DROP
    # Drop di tutte le connessioni che attraversano il sistema, quindi quelle
    # generate dai client della LAN o dirette verso essi.
    iptables -P FORWARD DROP
    # Drop di tutte le connessioni in uscita dal sistema
    iptables -P OUTPUT DROP
    Al posto di DROP si potrebbe usare REJECT (che ha lo stesso effetto ma con un messaggio di errore) ma, come prima cosa, rifiutare un pacchetto richiede più risorse al sistema che dropparlo ed in secondo luogo se il nostro sistema restituisce un messaggio di reject svela innanzi tutto la propria esistenza e la presenza di un firewall configurato. Magari non è molto ma sempre per il discorso della superficie d'attacco meno informazioni non necessarie si danno e meglio è...

    Questa regola fà eccezione: L'interfaccia di Loopback non è una vera e propria interfaccia di rete ma un'interfaccia fittizia che il sistema e alcune le applicazioni utilizzano per il loro funzionamento interno. Autorizzarne tutto il traffico è sicuro e consigliabile però la policy di default che ho inserito droppa anche il traffico su questa interfaccia quindi inserisco queste regole per "liberare" il traffico sul loopback:
    codice:
    # Autorizzo tutto il traffico di rete su lo
    iptables -A INPUT -i lo -j ACCEPT
    iptables -A OUTPUT -o lo -j ACCEPT
    Dalla guida prendo pari pari anche il codice che aggiunge alla tabella "FILTER" una chain personalizzata a quelle di default, per la neutralizzazione gli attacchi SYN flood. A quanto ho capito, i pacchetti SYN sono essenzialmente il traffico "buono" della rete ma questo traffico può essere utilizzato in volumi massicci per saturare un sistema, portandolo sostanzialmente al blocco. Sono sincero, non ho idea di cosa siano: Però mi fido, la catena esegue dei "DROP" e non degli ACCEPT e se mi dovesse dare problemi la posso sempre rimuovere...
    codice:
    # Chain personalizzata per il contrasto degli attacchi syn-flood
    iptables -N syn-flood
    iptables -A INPUT -i eth0 -p tcp syn -j syn-flood
    iptables -A syn-flood -m limit limit 1/s limit-burst 4 -j RETURN
    iptables -A syn-flood -j DROP
    "Iptables -N" genera una nuova chain denominata, in questo caso, "syn-flood" definisce prima di tutto l'interfaccia di riferimento (eth0) ed il tipo di traffico cui si riferisce la chain (SYN), la regola di accettabilità del traffico e la policy di default per la chain (DROP).
    La guida ora utilizza un funzionalità di ispezione dei pacchetti del nostro firewall per esaminare il traffico di rete in ingresso dalla WAN. Individuare precocemente il traffico utile e scartare il resto è un ottimo modo per ridurre il carico sul sistema quindi la adotto anche io:
    codice:
    ## Uso la Stateful Inspection droppare tutto il traffico TCP non di tipo SYN:
    iptables -A INPUT -i eth0 -p tcp syn -m state state NEW -j DROP
    Inizio ora a popolare di regole le mie chain predefinite.
    Un prima regola necessaria al funzionamento del mio server come router e quindi da applicare al firewall l'ho già definita ed è appunto quella per abilitare il masquerading:
    codice:
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    Commentare ogni singola riga sarebbe un lavoro molto lungo soprattutto perchè, come detto, non sono un esperto di networking e finirei per fare un gran copia incolla, dovendo ammettere molta ignoranza. Suggerisco di sfruttare il firewall generator che ho linkato sopra, esaminando le varie regole che propone.
    Ultima modifica di frakka : 22-08-2011 a 13:10


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #14
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.5.2_ Scelta delle funzionalità del firewall

    Ho preso una configurazione "semplice" dal wizard, tanto per iniziare. Ho assegnato IP statici ad entrambe le interfacce e specificato che il sistema opererà come firewall/gateway. L'impostazione del firewall e modifiche alla configurazione adottata ci accompagneranno fino alla fine, dell'installazione quindi è inutile sperare di prendere ora una configurazione che vada bene fino alla fine.
    Lo script è piuttosto lungo e la presenza dei commenti tende ad essere dispersiva ma è necessaria. In sostanza lo script inizialmente imposta le variabili che utilizzerà per definire le regole (indirizzi IP e percorsi dei file utilizzati per inviare i comandi al firewall), carica dei moduli del kernel specifici che potrebbero non essere attivati di default e reimposta il firewall ad una configurazione di base, eliminando tutte le regole eventualmente presenti, eliminando tutte le chain non standard eventualmente presenti ed impostando la policy di default per tutte le chain predefinite su "DROP".

    In questa configurazione il nostro firewall è assolutamente "muto" ed inaccessibile via rete. Il passo successivo potrebbe essere già autorizzare i servizi che ci interessano ma il wizard è piuttosot avanzato e fà prima una cosa diversa: Genera delle chain personalizzate in cui farà confluire determinate tipologie di traffico. Questo permette diverse cose, da un miglioramento delle prestazioni generali (perchè traffico identificato da subito come malevolo viene droppato immediatamente) ad una approfondita analisi dei log, per individuare comportamenti anomali o tentativi reiterati di attacco. iRedMail, il tool che utilizzerò per configurare il server di posta installa e configura fail2ban, che è un tool di analisi dei log per il ban automatico degli IP o degli host sospettati di essere malevoli e fà largo uso proprio di chain personalizzate. E' quindi utile inserirne fin da subito nel nostro script e capire come funzionino perchè dopo dovremmo rimetterci mano.

    Nello specifico lo script definisce le seguenti chain personalizzate e le popola con le regole indicate nella sezione "Populate User Chains":
    codice:
    # User-Specified Chains
    # Create a chain to filter INVALID packets
    $IPT -N bad_packets
    # Create another chain to filter bad tcp packets
    $IPT -N bad_tcp_packets
    # Create separate chains for icmp, tcp (incoming and outgoing),
    # and incoming udp packets.
    $IPT -N icmp_packets
    # Used for UDP packets inbound from the Internet
    $IPT -N udp_inbound
    # Used to block outbound UDP services from internal network
    # Default to allow all
    $IPT -N udp_outbound
    # Used to allow inbound services if desired
    # Default fail except for established sessions
    $IPT -N tcp_inbound
    # Used to block outbound services from internal network
    # Default to allow all
    $IPT -N tcp_outbound
    Le regole definiscono una serie di "parametri" che per permettono di identificare il traffico che arriva al nostro firewall, principalmente sulla base delle caratteristiche del pacchetto stesso. Non sono in grado di disquisire sulla correttezza o meno delle regole utilizzate, semplicemente mi limito a leggerle e modificare quelle che voglio agiscano diversamente.
    Ad esempio, mi interessa che il mio sistema risponda ai ping, almeno dalla rete locale. Identifico quindi la sezione relativa al traffico ICMP e modifico le regole relative (elimino parte dei commenti per questioni di spazio).

    codice:
    # icmp_packets chain
    ...
    # Echo - uncomment to allow your system to be pinged.
    # Uncomment the LOG command if you also want to log PING attempts
    # 
    # $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j LOG \
    #    --log-prefix "Ping detected: "
    # $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
    $IPT -A icmp_packets -p ICMP -i !$INET_IFACE --icmp-type 8 -j ACCEPT
    
    # By default, however, drop pings without logging. Blaster
    # and other worms have infected systems blasting pings.
    # Comment the line below if you want pings logged, but it
    # will likely fill your logs.
    #$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j DROP
    $IPT -A icmp_packets -p ICMP -i $INET_IFACE --icmp-type 8 -j DROP
    Ho commentato le righe presenti di default e le ho sostituite con comandi personalizzati: "$IPT -A icmp_packets -p ICMP -i !$INET_IFACE --icmp-type 8 -j ACCEPT" accetta tutto il traffico ICMP type 8 (il classico ping) che non viene dall'interfaccia $INET_IFACE che abbiamo deciso essere quella esterna. Il "!" davanti ad un valore ne inverte il senso quindi questo comando si legge: "Nella chain "icmp_packets" se identifichi un pacchetto nel protocollo ICMP di tipo 8 che non proviene dall'interfaccia $INET_IFACE accettalo". Lo stesso risultato si poteva ottenere indicando "-i $LOCAL_IFACE" al posto di "-i !$INET_IFACE" ma il metodo che ho utilizzato è più generale e dovrebbe funzionare bene anche in presenza di più di una interfaccia LAN.
    Analogamente, dobbiamo droppare il solo traffico ICMP type 8 proveniente dalla interfaccia $INET_IFACE ed è quello che fà la regola "$IPT -A icmp_packets -p ICMP -i $INET_IFACE --icmp-type 8 -j DROP" definita subito dopo.
    Le sezioni successive iniziano finalmente a lavorare sul filtering vero e proprio dei servizi. Dopo aver sostanzialmente abilitato tutto il traffico in uscita, inizia a popolare le chain relative ai pacchetti in INPUT.

    codice:
    # INPUT Chain
    #
    echo "Process INPUT chain ..."
    
    # Allow all on localhost interface
    $IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT
    
    # Drop bad packets
    $IPT -A INPUT -p ALL -j bad_packets
    ...
    # Rules for the private network (accessing gateway system itself)
    $IPT -A INPUT -p ALL -i $LOCAL_IFACE -s $LOCAL_NET -j ACCEPT
    $IPT -A INPUT -p ALL -i $LOCAL_IFACE -d $LOCAL_BCAST -j ACCEPT
    
    # Inbound Internet Packet Rules
    # Accept Established Connections
    $IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
         -j ACCEPT
    ...
    La prima regola abilita tutto il traffico "INPUT" sul loopback, come avevamo deciso in precedenza e subito dopo ci mostra il primo utilizzo delle chain personalizzate definite prima: per droppare i bad packet non si limita a istruire il firewall per dropparli ma li reindirizza alla chain denominata "bad_packet" e quindi il pacchetto seguirà dal quel momento uscità dalla chain "INPUT" per seguire le regole definite nella chain bad_packet.
    Le successive regole sostanzialmente accettano tutto il traffico proveniente dall'interfaccia sulla lan proveniente dalla range di IP della rete locale e il traffico proveniente dalla stessa rete e destinato al braodcast della stessa rete locale.
    Interessante la prossima regola: Viene accettato tutto il traffico proveniente dall'interfaccia di rete esterna (internet) ma solo se relativo a connessioni esistenti o già stabilite. Questo blocca tutto il traffico in ingresso che non sia stato richiesto dall'interno della nostra rete. E' una regola fondamentale, perchè, per capirci, in assenza di questo trust un eventuale browser sul firewall non sarebbe in grado di visualizzare alcuna pagina web in quanto il traffico di risposta proveniente dal server esterno verrebbe droppato.

    codice:
    #
    # FORWARD Chain
    # Drop bad packets
    $IPT -A FORWARD -p ALL -j bad_packets
    
    # Accept TCP packets we want to forward from internal sources
    $IPT -A FORWARD -p tcp -i $LOCAL_IFACE -j tcp_outbound
    
    # Accept UDP packets we want to forward from internal sources
    $IPT -A FORWARD -p udp -i $LOCAL_IFACE -j udp_outbound
    
    # If not blocked, accept any other packets from the internal interface
    $IPT -A FORWARD -p ALL -i $LOCAL_IFACE -j ACCEPT
    
    # Deal with responses from the internet
    $IPT -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
         -j ACCEPT
    Questa chain invece processa il traffico relativo che transita sul nostro firewall ma che è invece relativo ai client della nostra rete. Anche qui i bad_packet vengono girati alla chain competente (e quindi non vengono inoltrati ai client della nostra rete) ed i pacchetti validi vengono instradati attraverso le chain competenti ad analizzarli. Anche qui viene accettato il traffico in ingresso se relativo a connessioni esistenti o richieste dall'interno della rete.
    codice:
    # OUTPUT Chain
    #
    
    echo "Process OUTPUT chain ..."
    
    # Generally trust the firewall on output
    
    # However, invalid icmp packets need to be dropped
    # to prevent a possible exploit.
    $IPT -A OUTPUT -m state -p icmp --state INVALID -j DROP
    
    # Localhost
    $IPT -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
    $IPT -A OUTPUT -p ALL -o $LO_IFACE -j ACCEPT
    
    # To internal network
    $IPT -A OUTPUT -p ALL -s $LOCAL_IP -j ACCEPT
    $IPT -A OUTPUT -p ALL -o $LOCAL_IFACE -j ACCEPT
    
    # To internet
    $IPT -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT
    
    # Log packets that still don't match
    $IPT -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
        --log-prefix "OUTPUT packet died: "
    Questa chain chiude la tabella "FILTER" e riguarda il traffico in uscita.
    In questo caso stiamo autorizzando tutto il traffico valido proveniente dal nostro sistema e diretto all'esterno. Come dice il commento alla prima regola, il traffico non valido viene comunque droppato per evitare che possa essere veicolo di eventuali attacchi, magari verso altri sistemi.

    Il contenuto delle tabelle "NAT" e "MANGLE" è davvero scarno ma per ora è tutto quello che ci serve, si limita ad abilitare il masquerading nella tabella NAT e lascia vuota la tabella MANGLE.
    Lo script utilizza una sintassi diversa per abilitare il masquerading rispetto a quella che avevo indicato in precedenza. A quanto ho capito cercando informazioni, questa sintassi è preferibile nel caso l'interfaccia esterna abbia un IP statico, mentre quelle che avevo indicato è preferibile in presenza di un IP dinamico. Io ho IP statico quindi la adotto ma me lo segno lo stesso:
    codice:
    ###############################################################################
    #
    # nat table
    #
    ###############################################################################
    
    echo "Load rules for nat table ..."
    
    ###############################################################################
    #
    # PREROUTING chain
    #
    
    
    ###############################################################################
    #
    # POSTROUTING chain
    #
    
    # Sintassi per abilitare il masquerading da preferire in presenza di un IP
    # statico sull'interfaccia esterna:
    $IPT -t nat -A POSTROUTING -o $INET_IFACE \
         -j SNAT --to-source $INET_ADDRESS
    
    # Sintassi per abilitare il masquerading da preferire in presenza di un IP
    # dinamico sull'interfaccia esterna:
    # $IPT -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE
    
    ###############################################################################
    #
    # mangle table
    #
    ###############################################################################
    
    # The mangle table is used to alter packets.  It can alter or mangle them in
    # several ways.  For the purposes of this generator, we only use its ability
    # to alter the TTL in packets.  However, it can be used to set netfilter
    # mark values on specific packets.  Those marks could then be used in another
    # table like filter, to limit activities associated with a specific host, for
    # instance.  The TOS target can be used to set the Type of Service field in
    # the IP header.  Note that the TTL target might not be included in the
    # distribution on your system.  If it is not and you require it, you will
    # have to add it.  That may require that you build from source.
    
    echo "Load rules for mangle table ..."
    Questi due screen sono dei port-scan effettuati sulle due interfacce di rete del server di test appena avviato (e quindi senza firewall configurato) e dopo aver attivato il firewall ottenuto con lo script generato dal wizard:



    Per ottenere i primi due screen, con l'elenco completo dei servizi disponibili sul server, sono stati sufficienti meno di 10 secondi ciascuno. Per gli ultimi due, ho invece fermato a mano lo scanner dopo circa 2 ore ciascuno.
    Notiamo innanzitutto due cose: Nei primi due screen i servizi ssh e webmin (spostato dalla 10000 alla 15000) sono presenti solo per la rete interna (192.168.100.150) quindi la configurazione che avevo impostato per restringere l'accesso ssh e webmin effettivamente funziona, negli ultimi due screen invece non ci sono porte aperte quindi il nostro sistema, pur effettuando correttamente il forwarding ed il routing per i client della rete, è assolutamente irraggiungibile via rete quindi neppure via ssh o webmin per l'amministrazione.

    Dobbiamo aggiungere allo script i servizi che vogliamo poter utilizzare sul nostro server: Nello specifico io voglio che la macchina svolga i compiti di server di posta (quindi SMTP, POP3, IMAP con SSL), server web (con e senza SSL), server DNS e DHCP per la rete locale. Devo inoltre ricordarmi di abilitare la porta che ho assegnato a webmin, in questo caso solo protocollo TCP.
    Sfruttando il solito wizard, otteniamo un nuovo script che aggiunge le seguenti regole alla tabella FILTER, sotto varie chain:

    codice:
    # DNS Server
    # Configure the server to use port 53 as the source port for requests
    # Note, if you run a caching-only name server that only accepts queries
    # from the private network or localhost, you can comment out this line.
    $IPT -A udp_inbound -p UDP -s 0/0 --destination-port 53 -j ACCEPT
    
    # If you don't query-source the server to port 53 and you have problems,
    # uncomment this rule.  It specifically allows responses to queries
    # initiated to another server from a high UDP port.  The stateful
    # connection rules should handle this situation, though.
    # $IPT -A udp_inbound -p UDP -s 0/0 --source-port 53 -j ACCEPT
    ...
    # DNS Server - Allow TCP connections (zone transfers and large requests)
    # This is disabled by default.  DNS Zone transfers occur via TCP.
    # If you need to allow transfers over the net you need to uncomment this line.
    # If you allow queries from the 'net, you also need to be aware that although
    # DNS queries use UDP by default, a truncated UDP query can legally be
    # submitted via TCP instead.  You probably will never need it, but should
    # be aware of the fact.
    # $IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 53 -j ACCEPT
    
    # Web Server
    
    # HTTP
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 80 -j ACCEPT
    
    # HTTPS (Secure Web Server)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 443 -j ACCEPT
    
    # Email Server (SMTP)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 25 -j ACCEPT
    
    # Email Server (POP3)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 110 -j ACCEPT
    
    # Email Server (IMAP4)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 143 -j ACCEPT
    
    # SSL Email Server (POP3)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 995 -j ACCEPT
    
    # SSL Email Server (IMAP4)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 993 -j ACCEPT
    
    # sshd
    $IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 22 -j ACCEPT
    
    # User specified allowed TCP protocol
    $IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 15000 -j ACCEPT
    ...
    # Allow DHCP client request packets inbound from internal network
    $IPT -A INPUT -p UDP -i $LOCAL_IFACE --source-port 68 --destination-port 67 \
         -j ACCEPT
    Ho evidenziato in rosso quello che non mi convince o devo cambiare.
    Il mio DNS sarà solo locale, quindi posso commentare la regola "$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 53 -j ACCEPT", come da istruzioni dell'autore del wizard. Inoltre, se mi va bene che web e mail siano fruibili da qualunque rete (-s 0/0), non mi va assolutamente bene che lo siano il servizio ssh e la porta su cui è in ascolto webmin quindi cambio le due regole relative come segue:

    codice:
    # sshd
    $IPT -A tcp_inbound -p TCP -i $LOCAL_IFACE --destination-port 22 -j ACCEPT
    
    # User specified allowed TCP protocol
    $IPT -A tcp_inbound -p TCP -i $LOCAL_IFACE --destination-port 15000 -j ACCEPT
    In questo modo, il servizio ssh e webmin dovrebbero essere raggiungibili solo dall'interfaccia di rete interna.
    Ultima modifica di frakka : 22-08-2011 a 13:11


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  5. #15
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.5.3_ Definizione dello script di configurazione del firewall

    Sintetizzando il lavoro svolto finora, lo script da utilizzare che configura il firewall secondo le mie esigenze dovrebbe essere il seguente:
    codice:
    #!/bin/sh
    #
    # Generated iptables firewall script for the Linux 2.4 kernel
    # Script generated by Easy Firewall Generator for IPTables 1.15
    # copyright 2002 Timothy Scott Morizot
    # 
    # Redhat chkconfig comments - firewall applied early,
    #                             removed late
    # chkconfig: 2345 08 92
    # description: This script applies or removes iptables firewall rules
    # 
    # This generator is primarily designed for RedHat installations,
    # although it should be adaptable for others.
    #
    # It can be executed with the typical start and stop arguments.
    # If used with stop, it will stop after flushing the firewall.
    # The save and restore arguments will save or restore the rules
    # from the /etc/sysconfig/iptables file.  The save and restore
    # arguments are included to preserve compatibility with
    # Redhat's or Fedora's init.d script if you prefer to use it.
    
    # Redhat/Fedora installation instructions
    #
    # 1. Have the system link the iptables init.d startup script into run states
    #    2, 3, and 5.
    #    chkconfig --level 235 iptables on
    #
    # 2. Save this script and execute it to load the ruleset from this file.
    #    You may need to run the dos2unix command on it to remove carraige returns.
    #
    # 3. To have it applied at startup, copy this script to
    #    /etc/init.d/iptables.  It accepts stop, start, save, and restore
    #    arguments.  (You may wish to save the existing one first.)
    #    Alternatively, if you issue the 'service iptables save' command
    #    the init.d script should save the rules and reload them at runtime.
    #
    # 4. For non-Redhat systems (or Redhat systems if you have a problem), you
    #    may want to append the command to execute this script to rc.local.
    #    rc.local is typically located in /etc and /etc/rc.d and is usually
    #    the last thing executed on startup.  Simply add /path/to/script/script_name
    #    on its own line in the rc.local file.
    
    ###############################################################################
    # 
    # Local Settings
    #
    
    # sysctl location.  If set, it will use sysctl to adjust the kernel parameters.
    # If this is set to the empty string (or is unset), the use of sysctl
    # is disabled.
    
    SYSCTL="/sbin/sysctl -w" 
    
    # To echo the value directly to the /proc file instead
    # SYSCTL=""
    
    # IPTables Location - adjust if needed
    
    IPT="/sbin/iptables"
    IPTS="/sbin/iptables-save"
    IPTR="/sbin/iptables-restore"
    
    # Internet Interface
    INET_IFACE="eth0"
    INET_ADDRESS="192.168.50.150"
    
    # Local Interface Information
    LOCAL_IFACE="eth1"
    LOCAL_IP="192.168.100.150"
    LOCAL_NET="192.168.100.0/24"
    LOCAL_BCAST="192.168.100.255"
    
    # Localhost Interface
    
    LO_IFACE="lo"
    LO_IP="127.0.0.1"
    
    # Save and Restore arguments handled here
    if [ "$1" = "save" ]
    then
    	echo -n "Saving firewall to /etc/sysconfig/iptables ... "
    	$IPTS > /etc/sysconfig/iptables
    	echo "done"
    	exit 0
    elif [ "$1" = "restore" ]
    then
    	echo -n "Restoring firewall from /etc/sysconfig/iptables ... "
    	$IPTR < /etc/sysconfig/iptables
    	echo "done"
    	exit 0
    fi
    
    ###############################################################################
    #
    # Load Modules
    #
    
    echo "Loading kernel modules ..."
    
    # You should uncomment the line below and run it the first time just to
    # ensure all kernel module dependencies are OK.  There is no need to run
    # every time, however.
    
    # /sbin/depmod -a
    
    # Unless you have kernel module auto-loading disabled, you should not
    # need to manually load each of these modules.  Other than ip_tables,
    # ip_conntrack, and some of the optional modules, I've left these
    # commented by default.  Uncomment if you have any problems or if
    # you have disabled module autoload.  Note that some modules must
    # be loaded by another kernel module.
    
    # core netfilter module
    /sbin/modprobe ip_tables
    
    # the stateful connection tracking module
    /sbin/modprobe ip_conntrack
    
    # filter table module
    # /sbin/modprobe iptable_filter
    
    # mangle table module
    # /sbin/modprobe iptable_mangle
    
    # nat table module
    # /sbin/modprobe iptable_nat
    
    # LOG target module
    # /sbin/modprobe ipt_LOG
    
    # This is used to limit the number of packets per sec/min/hr
    # /sbin/modprobe ipt_limit
    
    # masquerade target module
    # /sbin/modprobe ipt_MASQUERADE
    
    # filter using owner as part of the match
    # /sbin/modprobe ipt_owner
    
    # REJECT target drops the packet and returns an ICMP response.
    # The response is configurable.  By default, connection refused.
    # /sbin/modprobe ipt_REJECT
    
    # This target allows packets to be marked in the mangle table
    # /sbin/modprobe ipt_mark
    
    # This target affects the TCP MSS
    # /sbin/modprobe ipt_tcpmss
    
    # This match allows multiple ports instead of a single port or range
    # /sbin/modprobe multiport
    # Attenzione: Il nome corretto/corrente di questo modulo dovrebbe essere il seguente:
    # /sbin/modprobe ipt_multiport
    
    # This match checks against the TCP flags
    # /sbin/modprobe ipt_state
    
    # This match catches packets with invalid flags
    # /sbin/modprobe ipt_unclean
    
    # The ftp nat module is required for non-PASV ftp support
    /sbin/modprobe ip_nat_ftp
    
    # the module for full ftp connection tracking
    /sbin/modprobe ip_conntrack_ftp
    
    # the module for full irc connection tracking
    /sbin/modprobe ip_conntrack_irc
    
    
    ###############################################################################
    #
    # Kernel Parameter Configuration
    #
    # See http://ipsysctl-tutorial.frozentux.net/chunkyhtml/index.html
    # for a detailed tutorial on sysctl and the various settings
    # available.
    
    # Required to enable IPv4 forwarding.
    # Redhat users can try setting FORWARD_IPV4 in /etc/sysconfig/network to true
    # Alternatively, it can be set in /etc/sysctl.conf
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/ip_forward
    else
        $SYSCTL net.ipv4.ip_forward="1"
    fi
    
    # This enables dynamic address hacking.
    # This may help if you have a dynamic IP address \(e.g. slip, ppp, dhcp\).
    #if [ "$SYSCTL" = "" ]
    #then
    #    echo "1" > /proc/sys/net/ipv4/ip_dynaddr
    #else
    #    $SYSCTL net.ipv4.ip_dynaddr="1"
    #fi
    
    # This enables SYN flood protection.
    # The SYN cookies activation allows your system to accept an unlimited
    # number of TCP connections while still trying to give reasonable
    # service during a denial of service attack.
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/tcp_syncookies
    else
        $SYSCTL net.ipv4.tcp_syncookies="1"
    fi
    
    # This enables source validation by reversed path according to RFC1812.
    # In other words, did the response packet originate from the same interface
    # through which the source packet was sent?  It's recommended for single-homed
    # systems and routers on stub networks.  Since those are the configurations
    # this firewall is designed to support, I turn it on by default.
    # Turn it off if you use multiple NICs connected to the same network.
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter
    else
        $SYSCTL net.ipv4.conf.all.rp_filter="1"
    fi
    
    # This option allows a subnet to be firewalled with a single IP address.
    # It's used to build a DMZ.  Since that's not a focus of this firewall
    # script, it's not enabled by default, but is included for reference.
    # See: http://www.sjdjweis.com/linux/proxyarp/ 
    #if [ "$SYSCTL" = "" ]
    #then
    #    echo "1" > /proc/sys/net/ipv4/conf/all/proxy_arp
    #else
    #    $SYSCTL net.ipv4.conf.all.proxy_arp="1"
    #fi
    
    # The following kernel settings were suggested by Alex Weeks. Thanks!
    
    # This kernel parameter instructs the kernel to ignore all ICMP
    # echo requests sent to the broadcast address.  This prevents
    # a number of smurfs and similar DoS nasty attacks.
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
    else
        $SYSCTL net.ipv4.icmp_echo_ignore_broadcasts="1"
    fi
    
    # This option can be used to accept or refuse source routed
    # packets.  It is usually on by default, but is generally
    # considered a security risk.  This option turns it off.
    if [ "$SYSCTL" = "" ]
    then
        echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
    else
        $SYSCTL net.ipv4.conf.all.accept_source_route="0"
    fi
    
    # This option can disable ICMP redirects.  ICMP redirects
    # are generally considered a security risk and shouldn't be
    # needed by most systems using this generator.
    #if [ "$SYSCTL" = "" ]
    #then
    #    echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
    #else
    #    $SYSCTL net.ipv4.conf.all.accept_redirects="0"
    #fi
    
    # However, we'll ensure the secure_redirects option is on instead.
    # This option accepts only from gateways in the default gateways list.
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/conf/all/secure_redirects
    else
        $SYSCTL net.ipv4.conf.all.secure_redirects="1"
    fi
    
    # This option logs packets from impossible addresses.
    if [ "$SYSCTL" = "" ]
    then
        echo "1" > /proc/sys/net/ipv4/conf/all/log_martians
    else
        $SYSCTL net.ipv4.conf.all.log_martians="1"
    fi
    
    
    ###############################################################################
    #
    # Flush Any Existing Rules or Chains
    #
    
    echo "Flushing Tables ..."
    
    # Reset Default Policies
    $IPT -P INPUT ACCEPT
    $IPT -P FORWARD ACCEPT
    $IPT -P OUTPUT ACCEPT
    $IPT -t nat -P PREROUTING ACCEPT
    $IPT -t nat -P POSTROUTING ACCEPT
    $IPT -t nat -P OUTPUT ACCEPT
    $IPT -t mangle -P PREROUTING ACCEPT
    $IPT -t mangle -P OUTPUT ACCEPT
    
    # Flush all rules
    $IPT -F
    $IPT -t nat -F
    $IPT -t mangle -F
    
    # Erase all non-default chains
    $IPT -X
    $IPT -t nat -X
    $IPT -t mangle -X
    
    if [ "$1" = "stop" ]
    then
    	echo "Firewall completely flushed!  Now running with no firewall."
    	exit 0
    fi
    
    ###############################################################################
    #
    # Rules Configuration
    #
    
    ###############################################################################
    #
    # Filter Table
    #
    ###############################################################################
    
    # Set Policies
    
    $IPT -P INPUT DROP
    $IPT -P OUTPUT DROP
    $IPT -P FORWARD DROP
    
    ###############################################################################
    #
    # User-Specified Chains
    #
    # Create user chains to reduce the number of rules each packet
    # must traverse.
    
    echo "Create and populate custom rule chains ..."
    
    # Create a chain to filter INVALID packets
    
    $IPT -N bad_packets
    
    # Create another chain to filter bad tcp packets
    
    $IPT -N bad_tcp_packets
    
    # Create separate chains for icmp, tcp (incoming and outgoing),
    # and incoming udp packets.
    
    $IPT -N icmp_packets
    
    # Used for UDP packets inbound from the Internet
    $IPT -N udp_inbound
    
    # Used to block outbound UDP services from internal network
    # Default to allow all
    $IPT -N udp_outbound
    
    # Used to allow inbound services if desired
    # Default fail except for established sessions
    $IPT -N tcp_inbound
    
    # Used to block outbound services from internal network
    # Default to allow all
    $IPT -N tcp_outbound
    
    ###############################################################################
    #
    # Populate User Chains
    #
    
    # bad_packets chain
    #
    
    # Drop packets received on the external interface
    # claiming a source of the local network
    $IPT -A bad_packets -p ALL -i $INET_IFACE -s $LOCAL_NET -j LOG \
        --log-prefix "Illegal source: "
    
    $IPT -A bad_packets -p ALL -i $INET_IFACE -s $LOCAL_NET -j DROP
    
    # Drop INVALID packets immediately
    $IPT -A bad_packets -p ALL -m state --state INVALID -j LOG \
        --log-prefix "Invalid packet: "
    
    $IPT -A bad_packets -p ALL -m state --state INVALID -j DROP
    
    # Then check the tcp packets for additional problems
    $IPT -A bad_packets -p tcp -j bad_tcp_packets
    
    # All good, so return
    $IPT -A bad_packets -p ALL -j RETURN
    
    # bad_tcp_packets chain
    #
    # All tcp packets will traverse this chain.
    # Every new connection attempt should begin with
    # a syn packet.  If it doesn't, it is likely a
    # port scan.  This drops packets in state
    # NEW that are not flagged as syn packets.
    
    # Return to the calling chain if the bad packets originate
    # from the local interface. This maintains the approach
    # throughout this firewall of a largely trusted internal
    # network.
    $IPT -A bad_tcp_packets -p tcp -i $LOCAL_IFACE -j RETURN
    
    # However, I originally did apply this filter to the forward chain
    # for packets originating from the internal network.  While I have
    # not conclusively determined its effect, it appears to have the
    # interesting side effect of blocking some of the ad systems.
    # Apparently some ad systems have the browser initiate a NEW
    # connection that is not flagged as a syn packet to retrieve
    # the ad image.  If you wish to experiment further comment the
    # rule above. If you try it, you may also wish to uncomment the
    # rule below.  It will keep those packets from being logged.
    # There are a lot of them.
    # $IPT -A bad_tcp_packets -p tcp -i $LOCAL_IFACE ! --syn -m state \
    #     --state NEW -j DROP
    
    $IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG \
        --log-prefix "New not syn: "
    $IPT -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL NONE -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL ALL -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
    
    $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j LOG \
        --log-prefix "Stealth scan: "
    $IPT -A bad_tcp_packets -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
    
    # All good, so return
    $IPT -A bad_tcp_packets -p tcp -j RETURN
    
    # icmp_packets chain
    #
    # This chain is for inbound (from the Internet) icmp packets only.
    # Type 8 (Echo Request) is not accepted by default
    # Enable it if you want remote hosts to be able to reach you.
    # 11 (Time Exceeded) is the only one accepted
    # that would not already be covered by the established
    # connection rule.  Applied to INPUT on the external interface.
    # 
    # See: http://www.ee.siue.edu/~rwalden/networking/icmp.html
    # for more info on ICMP types.
    #
    # Note that the stateful settings allow replies to ICMP packets.
    # These rules allow new packets of the specified types.
    
    # ICMP packets should fit in a Layer 2 frame, thus they should
    # never be fragmented.  Fragmented ICMP packets are a typical sign
    # of a denial of service attack.
    $IPT -A icmp_packets --fragment -p ICMP -j LOG \
        --log-prefix "ICMP Fragment: "
    $IPT -A icmp_packets --fragment -p ICMP -j DROP
    
    # Echo - uncomment to allow your system to be pinged.
    # Uncomment the LOG command if you also want to log PING attempts
    # 
    # $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j LOG \
    #    --log-prefix "Ping detected: "
    # $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j ACCEPT
    $IPT -A icmp_packets -p ICMP ! -i $INET_IFACE --icmp-type 8 -j ACCEPT
    
    # By default, however, drop pings without logging. Blaster
    # and other worms have infected systems blasting pings.
    # Comment the line below if you want pings logged, but it
    # will likely fill your logs.
    #$IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 8 -j DROP
    $IPT -A icmp_packets -p ICMP -i $INET_IFACE --icmp-type 8 -j DROP
    
    # Time Exceeded
    $IPT -A icmp_packets -p ICMP -s 0/0 --icmp-type 11 -j ACCEPT
    
    # Not matched, so return so it will be logged
    $IPT -A icmp_packets -p ICMP -j RETURN
    
    # TCP & UDP
    # Identify ports at:
    #    http://www.chebucto.ns.ca/~rakerman/port-table.html
    #    http://www.iana.org/assignments/port-numbers
    
    # udp_inbound chain
    #
    # This chain describes the inbound UDP packets it will accept.
    # It's applied to INPUT on the external or Internet interface.
    # Note that the stateful settings allow replies.
    # These rules are for new requests.
    # It drops netbios packets (windows) immediately without logging.
    
    # Drop netbios calls
    # Please note that these rules do not really change the way the firewall
    # treats netbios connections.  Connections from the localhost and
    # internal interface (if one exists) are accepted by default.
    # Responses from the Internet to requests initiated by or through
    # the firewall are also accepted by default.  To get here, the
    # packets would have to be part of a new request received by the
    # Internet interface.  You would have to manually add rules to
    # accept these.  I added these rules because some network connections,
    # such as those via cable modems, tend to be filled with noise from
    # unprotected Windows machines.  These rules drop those packets
    # quickly and without logging them.  This prevents them from traversing
    # the whole chain and keeps the log from getting cluttered with
    # chatter from Windows systems.
    $IPT -A udp_inbound -p UDP -s 0/0 --destination-port 137 -j DROP
    $IPT -A udp_inbound -p UDP -s 0/0 --destination-port 138 -j DROP
    
    # DNS Server
    # Configure the server to use port 53 as the source port for requests
    # Note, if you run a caching-only name server that only accepts queries
    # from the private network or localhost, you can comment out this line.
    #$IPT -A udp_inbound -p UDP -s 0/0 --destination-port 53 -j ACCEPT
    
    # If you don't query-source the server to port 53 and you have problems,
    # uncomment this rule.  It specifically allows responses to queries
    # initiated to another server from a high UDP port.  The stateful
    # connection rules should handle this situation, though.
    # $IPT -A udp_inbound -p UDP -s 0/0 --source-port 53 -j ACCEPT
    
    
    # Not matched, so return for logging
    $IPT -A udp_inbound -p UDP -j RETURN
    
    # udp_outbound chain
    #
    # This chain is used with a private network to prevent forwarding for
    # UDP requests on specific protocols.  Applied to the FORWARD rule from
    # the internal network.  Ends with an ACCEPT
    
    
    # No match, so ACCEPT
    $IPT -A udp_outbound -p UDP -s 0/0 -j ACCEPT
    
    # tcp_inbound chain
    #
    # This chain is used to allow inbound connections to the
    # system/gateway.  Use with care.  It defaults to none.
    # It's applied on INPUT from the external or Internet interface.
    
    # DNS Server - Allow TCP connections (zone transfers and large requests)
    # This is disabled by default.  DNS Zone transfers occur via TCP.
    # If you need to allow transfers over the net you need to uncomment this line.
    # If you allow queries from the 'net, you also need to be aware that although
    # DNS queries use UDP by default, a truncated UDP query can legally be
    # submitted via TCP instead.  You probably will never need it, but should
    # be aware of the fact.
    # $IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 53 -j ACCEPT
    
    # Web Server
    
    # HTTP
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 80 -j ACCEPT
    
    # HTTPS (Secure Web Server)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 443 -j ACCEPT
    
    # Email Server (SMTP)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 25 -j ACCEPT
    
    # SSL Email Server (Secure SMTP - SSMTP)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 465 -j ACCEPT
    
    # Email Server (POP3)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 110 -j ACCEPT
    
    # Email Server (IMAP4)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 143 -j ACCEPT
    
    # SSL Email Server (POP3)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 995 -j ACCEPT
    
    # SSL Email Server (IMAP4)
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 993 -j ACCEPT
    
    # sshd
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 22 -j ACCEPT
    $IPT -A tcp_inbound -p TCP -i $LOCAL_IFACE --destination-port 22 -j ACCEPT
    
    # User specified allowed TCP protocol
    #$IPT -A tcp_inbound -p TCP -s 0/0 --destination-port 15000 -j ACCEPT
    $IPT -A tcp_inbound -p TCP -i $LOCAL_IFACE --destination-port 15000 -j ACCEPT
    
    # Not matched, so return so it will be logged
    $IPT -A tcp_inbound -p TCP -j RETURN
    
    # tcp_outbound chain
    #
    # This chain is used with a private network to prevent forwarding for
    # requests on specific protocols.  Applied to the FORWARD rule from
    # the internal network.  Ends with an ACCEPT
    
    
    # No match, so ACCEPT
    $IPT -A tcp_outbound -p TCP -s 0/0 -j ACCEPT
    
    ###############################################################################
    #
    # INPUT Chain
    #
    
    echo "Process INPUT chain ..."
    
    # Allow all on localhost interface
    $IPT -A INPUT -p ALL -i $LO_IFACE -j ACCEPT
    
    # Drop bad packets
    $IPT -A INPUT -p ALL -j bad_packets
    
    # DOCSIS compliant cable modems
    # Some DOCSIS compliant cable modems send IGMP multicasts to find
    # connected PCs.  The multicast packets have the destination address
    # 224.0.0.1.  You can accept them.  If you choose to do so,
    # Uncomment the rule to ACCEPT them and comment the rule to DROP
    # them  The firewall will drop them here by default to avoid
    # cluttering the log.  The firewall will drop all multicasts
    # to the entire subnet (224.0.0.1) by default.  To only affect
    # IGMP multicasts, change '-p ALL' to '-p 2'.  Of course,
    # if they aren't accepted elsewhere, it will only ensure that
    # multicasts on other protocols are logged.
    # Drop them without logging.
    $IPT -A INPUT -p ALL -d 224.0.0.1 -j DROP
    # The rule to accept the packets.
    # $IPT -A INPUT -p ALL -d 224.0.0.1 -j ACCEPT
    
    # Rules for the private network (accessing gateway system itself)
    $IPT -A INPUT -p ALL -i $LOCAL_IFACE -s $LOCAL_NET -j ACCEPT
    $IPT -A INPUT -p ALL -i $LOCAL_IFACE -d $LOCAL_BCAST -j ACCEPT
    
    # Allow DHCP client request packets inbound from internal network
    $IPT -A INPUT -p UDP -i $LOCAL_IFACE --source-port 68 --destination-port 67 \
         -j ACCEPT
    
    
    # Inbound Internet Packet Rules
    
    # Accept Established Connections
    $IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
         -j ACCEPT
    
    # Route the rest to the appropriate user chain
    $IPT -A INPUT -p TCP -i $INET_IFACE -j tcp_inbound
    $IPT -A INPUT -p UDP -i $INET_IFACE -j udp_inbound
    $IPT -A INPUT -p ICMP -i $INET_IFACE -j icmp_packets
    
    # Drop without logging broadcasts that get this far.
    # Cuts down on log clutter.
    # Comment this line if testing new rules that impact
    # broadcast protocols.
    $IPT -A INPUT -m pkttype --pkt-type broadcast -j DROP
    
    # Log packets that still don't match
    $IPT -A INPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
        --log-prefix "INPUT packet died: "
    
    ###############################################################################
    #
    # FORWARD Chain
    #
    
    echo "Process FORWARD chain ..."
    
    # Used if forwarding for a private network
    
    # Drop bad packets
    $IPT -A FORWARD -p ALL -j bad_packets
    
    # Accept TCP packets we want to forward from internal sources
    $IPT -A FORWARD -p tcp -i $LOCAL_IFACE -j tcp_outbound
    
    # Accept UDP packets we want to forward from internal sources
    $IPT -A FORWARD -p udp -i $LOCAL_IFACE -j udp_outbound
    
    # If not blocked, accept any other packets from the internal interface
    $IPT -A FORWARD -p ALL -i $LOCAL_IFACE -j ACCEPT
    
    # Deal with responses from the internet
    $IPT -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED \
         -j ACCEPT
    
    # Log packets that still don't match
    $IPT -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG \
        --log-prefix "FORWARD packet died: "
    
    ###############################################################################
    #
    # OUTPUT Chain
    #
    
    echo "Process OUTPUT chain ..."
    
    # Generally trust the firewall on output
    
    # However, invalid icmp packets need to be dropped
    # to prevent a possible exploit.
    $IPT -A OUTPUT -m state -p icmp --state INVALID -j DROP
    
    # Localhost
    $IPT -A OUTPUT -p ALL -s $LO_IP -j ACCEPT
    $IPT -A OUTPUT -p ALL -o $LO_IFACE -j ACCEPT
    
    # To internal network
    $IPT -A OUTPUT -p ALL -s $LOCAL_IP -j ACCEPT
    $IPT -A OUTPUT -p ALL -o $LOCAL_IFACE -j ACCEPT
    
    # To internet
    $IPT -A OUTPUT -p ALL -o $INET_IFACE -j ACCEPT
    
    # Log packets that still don't match
    $IPT -A OUTPUT -m limit --limit 3/minute --limit-burst 3 -j LOG \
        --log-prefix "OUTPUT packet died: "
    
    ###############################################################################
    #
    # nat table
    #
    ###############################################################################
    
    # The nat table is where network address translation occurs if there
    # is a private network.  If the gateway is connected to the Internet
    # with a static IP, snat is used.  If the gateway has a dynamic address,
    # masquerade must be used instead.  There is more overhead associated
    # with masquerade, so snat is better when it can be used.
    # The nat table has a builtin chain, PREROUTING, for dnat and redirects.
    # Another, POSTROUTING, handles snat and masquerade.
    
    echo "Load rules for nat table ..."
    
    ###############################################################################
    #
    # PREROUTING chain
    #
    
    
    ###############################################################################
    #
    # POSTROUTING chain
    #
    
    # Sintassi per abilitare il masquerading da preferire in presenza di un IP
    # statico sull'interfaccia esterna:
    $IPT -t nat -A POSTROUTING -o $INET_IFACE \
         -j SNAT --to-source $INET_ADDRESS
    
    # Sintassi per abilitare il masquerading da preferire in presenza di un IP
    # dinamico sull'interfaccia esterna:
    # $IPT -t nat -A POSTROUTING -o $INET_IFACE -j MASQUERADE
    
    
    ###############################################################################
    #
    # mangle table
    #
    ###############################################################################
    
    # The mangle table is used to alter packets.  It can alter or mangle them in
    # several ways.  For the purposes of this generator, we only use its ability
    # to alter the TTL in packets.  However, it can be used to set netfilter
    # mark values on specific packets.  Those marks could then be used in another
    # table like filter, to limit activities associated with a specific host, for
    # instance.  The TOS target can be used to set the Type of Service field in
    # the IP header.  Note that the TTL target might not be included in the
    # distribution on your system.  If it is not and you require it, you will
    # have to add it.  That may require that you build from source.
    
    echo "Load rules for mangle table ..."
    Ho deciso di lasciare nello script anche la parte di configurazione dei parametri del kernel, anche se in parte lo avevo già fatto prima. Male non fà e mi mette al riparo da eventuali errori di configurazione.

    E' ora necessario impostare il sistema per caricare lo script del firewall automaticamente: Ci sono diversi modi per farlo ma personalmente preferisco aggiungere una riga ad hoc al file di configurazione delle interfacce di rete, in modo che ad ogni reload della scheda di rete pubblica lo script venga rieseguito ed il firewall riapplicato.

    Per copiare lo script sul firewall, è sufficiente ricorrere alla solita connessione ssh, e con i diritti di root (devo scrivere in una directory per cui servono i privilegi) lancio i comandi:
    codice:
     touch /etc/firewall
     chmod +x /etc/firewall
     nano /etc/firewall
    per creare il file "firewall" nella directory "/etc", renderlo eseguibile ed infine aprirlo con nano. A questo punto è sufficiente un copia-incolla e salvare il nuovo file con "Ctrl + x". Il file così creato sarà leggibile ed eseguibile da tutti gli utenti del server quindi aggiungo anche i comandi:
    codice:
     chmod g= /etc/firewall
     chmod o= /etc/firewall
    per togliere a tutti gli utenti tutti i permessi sul file. Solo "root" o un utente abilitato sudo possono così lanciare e/o modificare/consultare lo script di configurazione del firewall.
    Per aggiungere il firewall allo script di avvio dell'interfaccia di rete edito il file "/etc/network/interfaces" con il comando
    codice:
    nano /etc/network/interfaces
    per aggiungervi il comando di pre-up
    codice:
    pre-up /etc/firewall
    Il mio file /etc/network/interfaces diventa quindi:
    codice:
    # This file describes the network interfaces available on your system
    # and how to activate them. For more information, see interfaces(5).
    
    # The loopback network interface
    auto lo
    iface lo inet loopback
    
    # The primary network interface - Outside -
    auto eth0
    allow-hotplug eth0
    iface eth0 inet static
                 address 192.168.50.2
                 netmask 255.255.255.0
                 gateway 192.168.50.1
                 dns-nameservers 208.57.222.222 151.99.125.2 8.8.8.8
                 broadcast 192.168.50.255
                 pre-up /etc/firewall
    
    # Scheda di rete secondaria - Inside -
    auto eth1
    allow-hotplug eth1
    iface eth1 inet static
                 address 192.168.100.150
                 netmask 255.255.255.0
                 dns-search fracassetti.lan
                 broadcast 192.168.100.255
    [EDIT:]
    Lo script era lungi dall'essere perfetto o non migliorabile e col tempo vi ho apportato alcune modifiche e correzioni.

    Come prima cosa, ho rimosso il servizio "iptables" dal caricamento al boot: Nell'installazione base non mi dà alcun fastidio ma installando altri servizi che si aspettavano che il firewall venisse gestito con questo daemon, mi sono trovato le regole impostate dal pre-up sovrascritte dalla configurazione prevista da queste applicazioni. Non ho disinstallato iptables, ho semplicemente rimosso il caricamento del servizio al boot. Il firewall viene quindi configurato esclusivamente dal mio script "/etc/firewall" richiamato dal automaticamente quando viene attivata la scheda di rete eth0.
    Il metodo più "elegante" sarebbe forse quello di modificare la configurazione iniziale di iptables per caricare le mie regole ma anche procedere in questo modo non è necessariamente sbagliato e modificare la configurazione di iptables chiederebbe un pò di adattamento e revisione della sintassi di questo script che non ho ne tempo ne voglia di fare, per ora.

    Per togliere il servizio dall'esecuzione al boot ho usato, come root, il comando:
    # update-rc.d iptables remove
    Ricordo che nel caso si volesse arrestare il firewall la procedura corretta non è cancellare tutte le regole usando il comando "iptables -F" (lo script imposta la policy di default in "DROP" quindi il flush delle regole isola completamente il server dalla rete!!) ma aggiungere il parametro "stop" allo script, usando quindi il comando "sh /etc/firewall stop" (sempre come root o usando sudo). In questo modo l'esecuzione dello script si ferma alla sezione "Flush Any Existing Rules or Chains".


    [EDIT del 13/06/2012:]
    Ho notato un errore/mancato aggiornamento nella sezione iniziale dello script: Il modulo che permette di indicare più porte per ogni comando in realtà ora dovrebbe chiamarsi ipt_multiport quindi il comando:
    codice:
    # /sbin/modprobe multiport
    in realtà dovrebbe essere:
    codice:
    # /sbin/modprobe ipt_multiport
    Ultima modifica di frakka : 13-06-2012 a 00:28 Motivo: Aggiornamento.


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  6. #16
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.5.4_ Impostazione di un port-forwarding tramite iptables

    Nella mia configurazione, l'Ip pubblico è assegnato al router Wi-Max che, per la configurazione che gli è stata fatta, di default "gira" tutte le chiamate sull'IP di rete locale 192.168.50.2
    Quindi, se volessi installare un server WEB o un server di posta o un accesso FTP o VNC che risulti raggiungibile dalla rete internet dovrei assegnare per forza alla macchina che ospita il servizio l'IP locale 192.168.50.2.
    Configurando il server come ruoter/gateway ho la possibilità di decidere dove voglio instradare il mio traffico di rete e quindi la possibilità di fornire l'accesso VNC da remoto ad un pc della lan, installare il server di posta su un altra macchina ed il server web su una terza ancora. Nel mio caso specifico ho necessità di aprire le porte di eMule nel firewall ed instradare il traffico su quelle porte al pc della mia cara sorellina...
    Anche questo si fà con netfilter ed iptables e può essere inserito nello script che imposta il firewall.

    In questo caso, le porte che mi servono solo quella della configurazione standard di emule, le porte TCP 4662 ed UDP 4665 e 4672.
    Per prima cosa è necessario autorizzare il traffico di rete su quelle porte nella catena di FORWARD. il traffico, infatti, non deve avere come destinazione il serverino ma una macchina che gli stà dietro:

    codice:
    iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 4662 -j ACCEPT
    iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 4665 -j ACCEPT
    iptables -A FORWARD -i eth0 -o eth1 -p udp --dport 4672 -j ACCEPT
    poi devo dire a netfilter di modificare la destinazione dei pacchetti di rete in arrivo su quelle porte per raggiungere il computer di mia sorella. Per fare una cosa del genere, è necessario che il pc di destinazione abbia un IP statico o che il DHCP sia configurato per assegnare a quella macchina sempre lo stesso indirizzo IP altrimenti ad ogni cambio di indirizzo è necessario modificare anche questi comandi:

    codice:
    iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 4662 -j DNAT --to 192.168.100.201:4662
    iptables -A PREROUTING -t nat -p udp -i eth0 --dport 4665 -j DNAT --to 192.168.100.201:4665
    iptables -A PREROUTING -t nat -p udp -i eth0 --dport 4672 -j DNAT --to 192.168.100.201:4672
    Forse è possibile implementare una specie di servizio o di script che, all'avvio del pc della sorellina, apra in automatico sul mio firewall le porte necessarie per il pc ma mi sembra un pò oltre i miei scopi, per ora.


    Le regole di cui sopra si traducono, per l'inserimento del mio script di impostazione del firewall, in questo modo:
    codice:
    ## Port-Forwarding porte emule verso pc salotto
    $IPT -A FORWARD -i $INET_IFACE -o $LOCAL_IFACE -p tcp --dport 4662 -j ACCEPT
    $IPT -A FORWARD -i $INET_IFACE -o $LOCAL_IFACE -p udp --dport 4665 -j ACCEPT
    $IPT -A FORWARD -i $INET_IFACE -o $LOCAL_IFACE -p udp --dport 4672 -j ACCEPT
    
    $IPT -A PREROUTING -t nat -p tcp -i $INET_IFACE --dport 4662 -j DNAT --to 192.168.100.201:4662
    $IPT -A PREROUTING -t nat -p udp -i $INET_IFACE --dport 4665 -j DNAT --to 192.168.100.201:4665
    $IPT -A PREROUTING -t nat -p udp -i $INET_IFACE --dport 4672 -j DNAT --to 192.168.100.201:4672
    Possiamo inserirle più o meno dove vogliamo nello script (dopo, ovviamente, la sezione che fà il flush delle regole!!! ): tutte insieme oppure in una sezione apposita, dipende da come ci troviamo meglio in termini di organizzazione dello script. Siccome intendo rimuoverle prima o poi io me le metto tutte insieme in una sezione apposita in fondo allo script.

    Rilanciando lo script così modificato ora ottengo questo nella catena di FORWARD:
    codice:
    # iptables -L
    [...]
    Chain FORWARD (policy DROP)
    target     prot opt source               destination         
    bad_packets  all  --  anywhere             anywhere            
    tcp_outbound  tcp  --  anywhere             anywhere            
    udp_outbound  udp  --  anywhere             anywhere            
    ACCEPT     all  --  anywhere             anywhere            
    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
    LOG        all  --  anywhere             anywhere            limit: avg 3/min burst 3 LOG level warning prefix `FORWARD packet died: ' 
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:4662 
    ACCEPT     udp  --  anywhere             anywhere            udp dpt:4665 
    ACCEPT     udp  --  anywhere             anywhere            udp dpt:4672
    [...]
    e questo nella tabella nat del firewall:
    codice:
    # iptables -t nat -L
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination         
    DNAT       tcp  --  anywhere             anywhere            tcp dpt:4662 to:192.168.100.201:4662 
    DNAT       udp  --  anywhere             anywhere            udp dpt:4665 to:192.168.100.201:4665 
    DNAT       udp  --  anywhere             anywhere            udp dpt:4672 to:192.168.100.201:4672 
    
    Chain POSTROUTING (policy ACCEPT)
    target     prot opt source               destination         
    SNAT       all  --  anywhere             anywhere            to:192.168.50.2 
    
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination
    Il ragionamento, ovviamente, vale uguale anche per il forwarding di ogni porta anche per gli altri servizi, come appunto VNC, HTTP o SMTP.
    Ultima modifica di frakka : 22-08-2011 a 13:12


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  7. #17
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.6_ Configurazione del daemon ntp - Client ntp e server orario di riferimento per la rete locale

    Un aspetto fondamentale ma spesso ignorato dei sistemi informatici è la puntualità: Avere l'orario di sistema sempre a punto è fondamentale per molte cose, tra cui i sistemi di autenticazione in rete, che usano ticket con validità limitata nel tempo. Perchè un dominio Active Directory possa funzionare regolarmente, ad esempio, è necessario che gli scarti orari dei sistemi che lo compongono non superino i 5 minuti, altrimenti l'autenticazione fallisce oppure se l'orologio del pc è troppo sballato, il servizio aggiornamenti di Windows non permette di scaricare gli aggiornamenti da WindosUpdate.
    Esistono diversi modi per mantenere sincronizzati gli orologi di server sparsi per il mondo ed uno dei modi più semplici ed economici è far si che tutti i sistemi verifichino periodicamente la sincronia del loro orologio di sistema con una fonte oraria ritenuta attendibile. Alcuni server forniscono in continuazione il timestamp ottenuto da una sorgente oraria affidabile (un orologio atomico, ad esempio) e che possono essere utilizzati per sincronizzare su un valore affidabile gli orologi dei sistemi che si connettono al servizio. Questo servizio di chiama NTP (Network Time Protocol) ed in Italia esiste l'INRIM (Istituto Nazionale di ricerca Metrologica) che fornisce questo servizio manutenendo dei server ntp di "stratum 2".
    "Stratum 2" significa che il server che fornisce il servizio ntp è sincronizzato in hardware direttamente da quella che è ritenuta una sorgente oraria affidabile (lo "stratum 1" è la sorgente oraria affidabile stessa) ed i server NTP dell'INRIM sono sincronizzati con un orologio atomico al Cesio. Se poi usassi il mio server per sincronizzare col suo orario i client della mia LAN il mio server risulterebbe un server di "stratum 3" e così via...

    Per sincronizzare il mio sistema con i server NTP dell'INRIM installo per prima cosa il client "ntpdate" con la sua dipendenza "lockfile-progs" con il comando
    codice:
    sudo apt-get install lockfile-progs ntpdate
    Lancio poi il comando
    codice:
    sudo ntpdate 193.204.114.232 193.204.114.233
    per sincronizzare il mio sistema con il server dell'inrim e questo è il risultato:
    codice:
    30 Jul 17:07:25 ntpdate[13939]: adjust time server 193.204.114.233 offset 0.029652 sec
    Leggendo qualche articolo in giro, a quanto pare la soluzione di usare ntpdate per sincronizzare un server con un job cron non è più considerata la soluzione migliore. Intendiamoci: Funziona bene ma l'uso di un daemon ntp sembra essere consigliabile, anche perchè utilizza algoritmi più raffinati per la sincronizzazione.

    Decido quindi di installare il daemon ntp.
    Per installare il daemon e la sua dipendenza "libopts25" ed editare il file di configurazione è sufficiente lanciare i comandi
    codice:
    sudo apt-get install ntp libopts25
    sudo nano /etc/ntp.conf
    codice:
    # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
    
    driftfile /var/lib/ntp/ntp.drift
    
    
    # Enable this if you want statistics to be logged.
    #statsdir /var/log/ntpstats/
    
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable
    
    
    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example
    
    # pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
    # pick a different set every time it starts up.  Please consider joining the
    # pool: 
    server 0.debian.pool.ntp.org iburst
    server 1.debian.pool.ntp.org iburst
    server 2.debian.pool.ntp.org iburst
    server 3.debian.pool.ntp.org iburst
    
    
    # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
    # details.  The web page 
    # might also be helpful.
    #
    # Note that "restrict" applies to both servers and clients, so a configuration
    # that might be intended to block requests from certain clients could also end
    # up blocking replies from your own upstream servers.
    
    # By default, exchange time with everybody, but don't allow configuration.
    restrict -4 default kod notrap nomodify nopeer noquery
    restrict -6 default kod notrap nomodify nopeer noquery
    
    # Local users may interrogate the ntp server more closely.
    restrict 127.0.0.1
    restrict ::1
    
    # Clients from this (example!) subnet have unlimited access, but only if
    # cryptographically authenticated.
    #restrict 192.168.123.0 mask 255.255.255.0 notrust
    
    
    # If you want to provide time to your local subnet, change the next line.
    # (Again, the address is an example only.)
    #broadcast 192.168.123.255
    
    # If you want to listen to time broadcasts on your local subnet, de-comment the
    # next lines.  Please do this only if you trust everybody on the network!
    #disable auth
    #broadcastclient
    Come si vede, questo daemon può essere anche configurato per operare come time server per la rete locale... In questo caso, il mio serverino diventerebbe un server di "stratum 3" per la macchine della mia rete locale. Il protocollo NTP opera sulla porta 123 ma, visto che mi interessa servire solo la rete locale, non ho bisogno di operare modifiche sul firewall.
    Per quanto mi riguarda, ho sostituito i server indicati con i due server dell'INRIM e con un it.pool.ntp.org e abilitato la distribuzione del servizio orario per la rete locale. I server della rete di pool.ntp.org sono una serie di server che forniscono un servizio NTP ma, diversamente dai server dell'INRIM, forniscono già uno "stratum 3" quindi il mio serverino scenderebbe a "stratum 4". Vanno comunque bene per la maggior parte degli usi ma preferisco metterli solo come "backup" per i primi due.

    L'opzione "iburst" è una specie di sincronizzazione rapida: Il daemon ntp, a grandi linee, lavora in continuazione, tenendo traccia degli scarti orari e correggendo l'orologio del sistema a poco a poco. Se è utilizzata l'opzione "iburst" la sincronizzazione dell'orologio avviene in una decina di secondi, in caso contrario, il daemon va in timeout e si interrompe senza apportare modifiche.

    Il mio file di configurazione è quindi diventato:
    codice:
    # /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
    
    driftfile /var/lib/ntp/ntp.drift
    
    # Enable this if you want statistics to be logged.
    #statsdir /var/log/ntpstats/
    
    statistics loopstats peerstats clockstats
    filegen loopstats file loopstats type day enable
    filegen peerstats file peerstats type day enable
    filegen clockstats file clockstats type day enable
    
    # You do need to talk to an NTP server or two (or three).
    #server ntp.your-provider.example
    server ntp1.inrim.it iburst
    server ntp2.inrim.it  iburst
    
    # pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
    # pick a different set every time it starts up.  Please consider joining the
    # pool: 
    server it.pool.ntp.org iburst
    
    # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
    # details.  The web page 
    # might also be helpful.
    #
    # Note that "restrict" applies to both servers and clients, so a configuration
    # that might be intended to block requests from certain clients could also end
    # up blocking replies from your own upstream servers.
    
    # By default, exchange time with everybody, but don't allow configuration.
    restrict -4 default kod notrap nomodify nopeer noquery
    restrict -6 default kod notrap nomodify nopeer noquery
    
    # Local users may interrogate the ntp server more closely.
    restrict 127.0.0.1
    restrict ::1
    
    # Clients from this (example!) subnet have unlimited access, but only if
    # cryptographically authenticated.
    #restrict 192.168.123.0 mask 255.255.255.0 notrust
    
    # If you want to provide time to your local subnet, change the next line.
    # (Again, the address is an example only.)
    broadcast 192.168.150.255
    
    # If you want to listen to time broadcasts on your local subnet, de-comment the
    # next lines.  Please do this only if you trust everybody on the network!
    #disable auth
    #broadcastclient
    Per far sì che l'orologio di sistema (quello del server linux) e l'orologio hardware del bios del server siano sincronizzati tra loro, è bene eseguire periodicamente il comando
    codice:
    /sbin/hwclock --systohc
    per far sì che anche l'orologio del CMOS venga aggiornato con l'impostazione oraria corretta. Credo che una una volta al giorno sia sufficiente, ho quindi impostato un cron job apposito sempre dall'interfaccia di webmin.

    E questo è il risultato (stato del server ntp, client linux configurato per prendere l'orario del server, client Windows7 configurato per prendere l'orario dal server, job cron per la sincronizzazione dell'orologio CMOS)



    [EDIT 01 Novembre 2011]

    Potrebbe essere una buona idea, se il server opera come server orario per la rete locale, aggiungere anche il "local clock" come riferimento in modo che il server continui a fornire un riferimento orario ai client delle rete anche in assenza di connessione internet. Questo può essere usato anche e soprattutto se il server dispone di un dispositivo orario affidabile che sincronizza l'orologio hardware in altro modo e rende quindi il server un riferimento orario affidabile.
    Per farlo, è sufficiente aggiungere le seguenti righe al file di configurazione, subito sotto i server configurati in precedenza:
    server 127.127.1.0
    fudge 127.127.1.0 stratum 10
    In questo modo, il server dispone anche del "localhost" come sorgente oraria anche se viene forzata ad essere uno stratum "10". Ovviamente, in presenza di una sincronia affidabile è possibile aumentare lo stratum ad "1".

    root@server:/home/matteo# ntpq -p
    remote refid st t when poll reach delay offset jitter
    ==============================================================================
    +ntp1.inrim.it .CTD. 1 u 41 64 377 16.828 -2.033 7.022
    *ntp2.inrim.it .CTD. 1 u 38 64 377 15.982 -1.272 5.237
    +saguaro.bilink. 212.45.144.11 3 u 34 64 377 16.885 -4.221 7.150
    LOCAL(0) .LOCL. 10 l 254 64 370 0.000 0.000 0.000
    192.168.150.255 .BCST. 16 u - 64 0 0.000 0.000 0.000
    Ultima modifica di frakka : 01-11-2011 a 11:33


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #18
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.7_ Configurazione dell'agente smtp per l'invio delle notifiche di sistema

    Come visto, per non dover continuamente monitorare lo stato del sistema, posso configurare alcune funzionalità per monitorare il loro stato ed inviare una mail in caso di problemi. E' quello che è stato fatto, ad esempio, con mdadm: Se rileva un problema con gli array raid invia una mail all'indirizzo indicato nel suo file di configurazione.
    Praticamente tutte le distribuzioni Linux sono in grado, out of the box, di gestire l'invio di mail: Nel caso di Debian l'agente preinstallato per l'invio e la ricezione di mail è exim ma, nella configurazione predefinita, non può inviare o ricevere mail a o da sistemi diversi da se stesso.
    La cosa potrebbe sembrare stupida ma exim è uno strumento completo per l'invio e la ricezione di mail. Una configurazione predefinita così restrittiva serve per impedire che, per l'ìncuria di sysadmin disattenti, ogni installazione di Debian diventi un potenziale zombie in grado di fare mail relay a disposizione di tutti gli spammers del mondo...

    Quello che mi serve ora è fare in modo che exim sia in grado di inviare le notifiche originate dal sistema verso internet. Non devo configurare un server di posta completo ma semplicemente fare in modo che exim sia in grado di ricevere una mail da un daemon locale al server ed inviarla su internet, all'indirizzo mail che ho impostato nelle varie configurazioni.

    Per farlo, è sufficiente eseguire una semplice procedura guidata: Lancio da ssh il comando:
    codice:
    sudo dpkg-reconfigure exim4-config
    E seguo la procedura guidata:

    La configurazione attuale (predefinita) è: "Local delivery only". Seleziono "internet site" in quanto il mio server dovrà occuparsi di inviare direttamente le mail. Nella seconda schermata, seleziono il dominio che il server dovrà utilizzare nel campo From: per l'invio di mail: L'esempio proposto è esplicativo di cosa inserire. La terza schermata è estremamente importante: Nel mio caso, come nell'esempio, lascio l'indicazione di 127.0.0.1 come indirizzo Ip abilitato all'invio della posta tramite questo server. Lasciare questo campo vuoto permetterebbe a chiunque di utilizzare il mio server per inviare mail (se nel firewall ho lasciato la porta 25 in ingresso aperta) generando un open relay, cosa certamente non auspicabile. Solo i daemon in esecuzione sul server devono essere in grado di inviare mail quindi 127.0.0.1 per me va bene. La quarta schermata invece ci chiede di impostare per quali domini deve essere accettata la posta: E' un primo filtro antispam, in questo modo il server riceverà mail solo per i domini indicati e non qualunque mail che riporti nella parte di indirizzo prima di "@" un utente configurato. Nel mio caso, il server non deve ricevere alcuna mail da internet quindi utilizzo il dominio privato. Di massima, una mail al dominio @fracassetti.lan non dovrebbe neppure arrivare e se arriva al 99.9% è un messaggio di sistema o è spam...


    Nella quinta e sesta schermata, posso configurare i domini o le specifiche macchine autorizzate al relay tramite il mio server: In questo caso, nessuno. La settima schermata riguarda le configurazioni con connessione dial-up e non è il mio caso quindi rispondo "no". Nella penultima schermata scelgo di salvare le mail per il mio indirizzo locale in formato mbox nella direcotry /var/mail. Queste sono le mailbox dell'utente root e "matteo" configurati sul server e rispondono all'indirizzo root@fracassetti.lan e matteo@fracassetti.lan... E' una scelta puramente estetica dato che il mio server non riceve mail da nessuno e sicuramente non per un dominio privato... Ed, in ultimo, non ho necessità di splittare la configurazione di exim in file più piccoli.

    Al termine, provo a fare inviare una mail di test ad mdadm con il comando:
    codice:
    matteo@server:/$ sudo mdadm --monitor --test /dev/md0
    con questo risultato:
    Da: email-configurata
    A: mia-mail
    Oggetto: TestMessage event on /dev/md0:server
    Data: Sat, 20 Aug 2011 17:14:38 +0200
    This is an automatically generated mail message from mdadm
    running on server
    A TestMessage event had been detected on md device /dev/md0.
    Faithfully yours, etc.
    P.S. The /proc/mdstat file currently contains the following:
    Personalities : [raid1]
    md1 : active raid1 sda2[2] sdb2[1]
    30760888 blocks super 1.2 [2/2] [UU]
    md0 : active raid1 sda1[0] sdb1[1]
    498676 blocks super 1.2 [2/2] [UU]
    unused devices:


    Con poche semplici modifiche, è possibile fare in modo che il serverino operi anche da mail relay per l'invio di posta dalla rete interna.
    Nello specifico, autorizzando il relay dalla rete locale è possibile configurare il client di posta dei pc della mia rete locale per inviare mail usando come server in uscita l'IP del server, invece che il server SMTP del provider. Questo è particolarmente utile quando si devono spedire mail da un account che non appartiene al nostro ISP (ad esempio mail da un indirizzo *@libero.it con linea Telecom o viceversa) visto che molti provider non permettono più di farlo.
    Le modifiche da fare sono da apportare nelle schermate numero 3, 5 e 6 in cui è possibile e necessario specificare su quale indirizzo IP del mio serverino il server di posta exim dovrà mettersi in ascolto (solo l'IP della rete lan interna, solo l'IP della rete lan esterna, entrambi o qualunque IP assegnato al server) quali domini di posta possono transitare attraverso questo server (Domains to relay mail for) e gli indirizzi di rete delle eventuali macchine autorizzate al relay senza alcuna restrizione (l'indirizzo di una stampante di rete, un NAS, un'intera rete locale che magari non permettono di impostare una autenticazione SMTP).
    Questa è solo una funzionalità basilare: Un server di posta completo richiede molto di più ma l'argomento lo tratterò separatamente. Richiede comunque molta attenzione perchè un server SMTP open-relay mal configurato può essere fonte di notevoli problemi (anche legali!!!).
    Ultima modifica di frakka : 22-08-2011 a 13:13


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  9. #19
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 3.8_ Finalizzazione della configurazione di base. Impostazioni varie

    L'installazione è giunta ora ad un buon punto. Praticamente ho concluso l'installazione e la configurazione di tutti quelle parti che costituiscono la base comune a tutti i sistemi server di questo tipo, praticamente una sorta di "punto di partenza".
    Ci sono delle configurazioni che, inizialmente, ho lasciato indietro e che posso comodamente fare ora. Una di queste riguarda mdadm: Questo strumento monitora costantemente lo stato degli array raid ma questo monitoraggio sarebbe assolutamente inutile se non ci avvertisse tempestivamente di un problema. Lo strumento è quindi in grado di inviare una di avviso quando rileva dei problemi con gli array RAID. L'indirizzo a cui spedire le mail può essere configurato da linea di comando, agendo sul file di configurazione oppure da webmin, tramite il modulo raggiungibile da "Hardware -> Linux Raid"
    L'indirizzo email "Send notifications to" deve, ovviamente, essere un indirizzo verificato di frequente, mentre il "From address for notifications" è solo per indicare il mittente della mail, potrebbe anche essere un indirizzo inesistente.


    Sempre per quanto riguarda le notifiche, possiamo usare webmin perchè verifichi periodicamente la disponibilità di aggiornamenti e le azioni da intraprendere.
    L'opportunità o meno di utilizzare l'aggiornamento automatico del sistema è sempre molto dibattuta: La mia configurazione non prevede moduli che debbano essere ricompilati manualmente in caso di aggiornamento del kernel quindi sono dell'idea di mantenere il sistema aggiornato. D'altra parte, in alcuni casi il cambio di versione di alcuni software apporta anche dei cambiamenti nella sintassi dei files di configurazione che potrebbero comportare la necessità di modifiche manuali.
    Per quanto mi riguarda ho quindi decido quindi di verificare giornalmente la disponibilità di aggiornamenti ed effettuare automaticamente solo quelli di sicurezza, comunque con l'invio di una mail di notifica da parte del sistema quando ci sono aggiornamenti disponibili.
    Per configurare gli aggiornamenti utilizzo il modulo di webmin "System -> Software Package Updates".
    Ultima modifica di frakka : 15-04-2012 a 15:41


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  10. #20
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,114
    configurazione

    Predefinito 4_ Installazione, configurazione e verifica del server DHCP

    Il passo successivo è configurare il server DHCP e cioè un server in ascolto solo sull'interfaccia interna della mia rete che sia in grado di distribuire la configurazione di rete ai client che ne fanno richiesta, in modo che possano configurarsi in automatico. Solitamente questo lavoro è svolto dal router/modem dell'ISP ma avendo posto il server tra il router/modem e la mia LAN devo configurare il servizio in modo che sia raggiungibile anche dal mio lato della rete.
    L'installazione del server DHCP di fà con il solito comando:
    codice:
    sudo apt-get install dhcp3-server
    Il comando installerà anche le dipendenze necessarie. Al termine, l'installazione restituirà un messaggio di errore: Il sistema non riesce a far partire il server DHCP. E' insolito ma normale: Il server DHCP non ha ancora una configurazione e usarne una di default non avrebbe senso, data la specificità del servizio, che deve essere configurato per la rete su cui dovrà operare.


    Il mio server dovrà distribuire indirizzi IP solo ai client della mia LAN, quindi è inutile metterlo in ascolto su tutte le interfacce. Anzi: Avendo già un servizio DHCP attivo sul router dell'ISP attivare un altro DHCP sulla stessa rete potrebbe darmi solo problemi. Per indicare su quale interfaccia il server dovrà rispondere alle richieste DHCP agisco sul file di configurazione del server DHCP:
    codice:
    sudo nano /etc/default/isc-dhcp-server
    Così è come si presenta di default il file:
    codice:
    # Defaults for dhcp initscript
    # sourced by /etc/init.d/dhcp
    # installed at /etc/default/isc-dhcp-server by the maintainer scripts
    
    #
    # This is a POSIX shell fragment
    #
    
    # On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
    #       Separate multiple interfaces with spaces, e.g. "eth0 eth1".
    INTERFACES=""
    Io ho quindi inserito solo eth1 tra le "" in fondo, la mia ultima riga diventa quindi INTERFACES="eth1".
    Come dice il commento, se avessi più reti lan connesse a diverse interfacce da servire col DHCP basterebbe metterle tutte tra le "", separate da spazi.

    Per la configurazione del servizio DHCP mi vengono in aiuto le guide pubblicate su questo blog. Le guide sono scritte per Ubuntu in verità ma si adattano con estrema facilità anche a Debian. Anche in questo caso è possibile operare da webmin o da linea di comando. Una volta terminata la configurazione, dai test che ho fatto è abbastanza indifferente apportare modifiche dall'una o dall'altra interfaccia (non interferiscono tra loro) ma come al solito io preferisco la linea di comando in quanto mi permette di capire meglio come funziona il servizio che vado ad attivare.
    Su Debian, il file di configurazione del servizio DHCP non è "/etc/dhcp3/dhcpd.conf" ma in "/etc/dhcp" quindi per aprire il file di configurazione uso il comando:
    codice:
    sudo cp /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.backup
    sudo nano /etc/dhcp/dhcpd.conf
    per dargli un'occhiata.
    La configurazione è molto complessa perchè lo strumento è pensato per gestire reti molto grandi ed articolate. Le sezioni che interessano a me per fortuna sono relativamente poche.
    Analizzandone la struttura, si nota che il file è organizzato in sezioni, racchiuse tra "{" e "}" mentre ogni linea della configurazione all'interno delle parentesi termina con ";". Le altre linee sono tutte commentate.
    codice:
    #
    # Sample configuration file for ISC dhcpd for Debian
    #
    #
    
    # The ddns-updates-style parameter controls whether or not the server will
    # attempt to do a DNS update when a lease is confirmed. We default to the
    # behavior of the version 2 packages ('none', since DHCP v2 didn't
    # have support for DDNS.)
    ddns-update-style none;
    
    # option definitions common to all supported networks...
    option domain-name "example.org";
    option domain-name-servers ns1.example.org, ns2.example.org;
    
    default-lease-time 600;
    max-lease-time 7200;
    
    # If this DHCP server is the official DHCP server for the local
    # network, the authoritative directive should be uncommented.
    #authoritative;
    
    # Use this to send dhcp log messages to a different log file (you also
    # have to hack syslog.conf to complete the redirection).
    log-facility local7;
    
    # No service will be given on this subnet, but declaring it helps the 
    # DHCP server to understand the network topology.
    
    #subnet 10.152.187.0 netmask 255.255.255.0 {
    #}
    
    #This is a very basic subnet declaration.
    
    #subnet 10.254.239.0 netmask 255.255.255.224 {
    #  range 10.254.239.10 10.254.239.20;
    #  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
    #}
    
    # This declaration allows BOOTP clients to get dynamic addresses,
    # which we don't really recommend.
    
    #subnet 10.254.239.32 netmask 255.255.255.224 {
    #  range dynamic-bootp 10.254.239.40 10.254.239.60;
    #  option broadcast-address 10.254.239.31;
    #  option routers rtr-239-32-1.example.org;
    #}
    
    # A slightly different configuration for an internal subnet.
    #subnet 10.5.5.0 netmask 255.255.255.224 {
    #  range 10.5.5.26 10.5.5.30;
    #  option domain-name-servers ns1.internal.example.org;
    #  option domain-name "internal.example.org";
    #  option routers 10.5.5.1;
    #  option broadcast-address 10.5.5.31;
    #  default-lease-time 600;
    #  max-lease-time 7200;
    #}
    
    # Hosts which require special configuration options can be listed in
    # host statements.   If no address is specified, the address will be
    # allocated dynamically (if possible), but the host-specific information
    # will still come from the host declaration.
    
    #host passacaglia {
    #  hardware ethernet 0:0:c0:5d:bd:95;
    #  filename "vmunix.passacaglia";
    #  server-name "toccata.fugue.com";
    #}
    
    # Fixed IP addresses can also be specified for hosts.   These addresses
    # should not also be listed as being available for dynamic assignment.
    # Hosts for which fixed IP addresses have been specified can boot using
    # BOOTP or DHCP.   Hosts for which no fixed address is specified can only
    # be booted with DHCP, unless there is an address range on the subnet
    # to which a BOOTP client is connected which has the dynamic-bootp flag
    # set.
    #host fantasia {
    #  hardware ethernet 08:00:07:26:c0:a5;
    #  fixed-address fantasia.fugue.com;
    #}
    
    # You can declare a class of clients and then do address allocation
    # based on that.   The example below shows a case where all clients
    # in a certain class get addresses on the 10.17.224/24 subnet, and all
    # other clients get addresses on the 10.0.29/24 subnet.
    
    #class "foo" {
    #  match if substring (option vendor-class-identifier, 0, 4) = "SUNW";
    #}
    
    #shared-network 224-29 {
    #  subnet 10.17.224.0 netmask 255.255.255.0 {
    #    option routers rtr-224.example.org;
    #  }
    #  subnet 10.0.29.0 netmask 255.255.255.0 {
    #    option routers rtr-29.example.org;
    #  }
    #  pool {
    #    allow members of "foo";
    #    range 10.17.224.10 10.17.224.250;
    #  }
    #  pool {
    #    deny members of "foo";
    #    range 10.0.29.10 10.0.29.230;
    #  }
    #}
    codice:
    # option definitions common to all supported networks...
    option domain-name "example.org";
    option domain-name-servers ns1.example.org, ns2.example.org;
    Questa sezione definisce il nome della zona ed i server DNS comuni a tutte le zone. Di massima, il nome della zona coincide con il nome del dominio della rete locale ma credo che nulla ci vieti di darle un nome diverso. Questa impostazione è a "livello server" e "sovrascrive" le impostazioni specificate per le singole zone.
    codice:
    default-lease-time 600;
    max-lease-time 7200;
    L'assegnazione degli indirizzi di rete di un server DHCP generalmente non è eterna ma ha una durata. Questa durata è appunto il "lease-time" ed è espresso in secondi. Questo non significa che dopo 600 secondi la macchina cambia indirizzo IP ma che il server riserva l'indirizzo IP che ha assegnato ad una determinata scheda di rete per un periodo di tempo che va da un minimo di 600 ad un massimo di 7200 secondi (10 minuti - 2 ore) dopo di che se il client rinnova la richiesta di indirizzo IP potrebbe essergliene assegnato uno diverso. Questa impostazione per funzionare funziona... Ma è un valore molto basso per una rete locale privata. Aumentare il "default-lease-time" a 12 o 24 ore (e di conseguenza il max-lease-time) non dovrebbe comportare particolari problemi (43200 oppure 86400 secondi).

    codice:
    # If this DHCP server is the official DHCP server for the local
    # network, the authoritative directive should be uncommented.
    #authoritative;
    Un server DHCP è "autorevole" quando è il server DHCP principale per una determinata subnet. Potrebbero esserci anche altri server, che operano come ripetitori del server principale ma ci deve essere un solo server autorevole, onde evitare che i client rinnovino in continuazione le richieste di indirizzi provocando confusione e problemi.

    codice:
    # No service will be given on this subnet, but declaring it helps the 
    # DHCP server to understand the network topology.
    
    #subnet 10.152.187.0 netmask 255.255.255.0 {
    #}
    codice:
    # This is a very basic subnet declaration.
    
    #subnet 10.254.239.0 netmask 255.255.255.224 {
    #  range 10.254.239.10 10.254.239.20;
    #  option routers rtr-239-0-1.example.org, rtr-239-0-2.example.org;
    #}
    codice:
    # A slightly different configuration for an internal subnet.
    #subnet 10.5.5.0 netmask 255.255.255.224 {
    #  range 10.5.5.26 10.5.5.30;
    #  option domain-name-servers ns1.internal.example.org;
    #  option domain-name "internal.example.org";
    #  option routers 10.5.5.1;
    #  option broadcast-address 10.5.5.31;
    #  default-lease-time 600;
    #  max-lease-time 7200;
    #}
    I commenti sono esplicativi: Il primo pezzo serve a far capire al server DHCP com'è organizzata la rete che deve gestire, il secondo è una configurazione minimale ma funzionate. A me interessa di più la terza parte, è un pò più "completa".

    codice:
    # Hosts which require special configuration options can be listed in
    # host statements.   If no address is specified, the address will be
    # allocated dynamically (if possible), but the host-specific information
    # will still come from the host declaration.
    
    #host passacaglia {
    #  hardware ethernet 0:0:c0:5d:bd:95;
    #  filename "vmunix.passacaglia";
    #  server-name "toccata.fugue.com";
    #}
    
    # Fixed IP addresses can also be specified for hosts.   These addresses
    # should not also be listed as being available for dynamic assignment.
    # Hosts for which fixed IP addresses have been specified can boot using
    # BOOTP or DHCP.   Hosts for which no fixed address is specified can only
    # be booted with DHCP, unless there is an address range on the subnet
    # to which a BOOTP client is connected which has the dynamic-bootp flag
    # set.
    #host fantasia {
    #  hardware ethernet 08:00:07:26:c0:a5;
    #  fixed-address fantasia.fugue.com;
    #}
    Questa sezioni permettono di specificare, in base al MAC address dell'interfaccia di rete delle macchine client, assegnazioni permanenti di indirizzi IP o configurazioni particolari. Gli host così individuati otterranno sempre lo stesso indirizzo IP oppure otterranno le informazioni di configurazione delle rete pescandole da un file specifico... Ci sono molte applicazioni di queste assegnazioni, fino ad arrivare ad assegnare a determinati client dei parametri di rete sbagliati o incompleti per non permettergli di navigare su internet o che li facciano finire direttamente nelle DROP chain di IPTABLES... Il limite credo sia solo la malignità dell'amministratore di rete!
    Nel mio caso, mi permetterà di fare in modo che al pc della mia cara sorellina sia assegnato sempre lo stesso indirizzo IP, pur mantenendo in DHCP la configurazione di Windows.

    La parte finale del file di configurazione del servizio in verità non mi interessa, è per situazioni particolari.

    codice:
    # Sample configuration file for ISC dhcpd for Debian
    #
    #
    
    # The ddns-updates-style parameter controls whether or not the server will
    # attempt to do a DNS update when a lease is confirmed. We default to the
    # behavior of the version 2 packages ('none', since DHCP v2 didn't
    # have support for DDNS.)
    ddns-update-style none;
    
    # option definitions common to all supported networks...
    option domain-name "fracassetti.lan";
    option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5;
    
    default-lease-time 600;
    max-lease-time 7200;
    
    # If this DHCP server is the official DHCP server for the local
    # network, the authoritative directive should be uncommented.
    authoritative;
    
    # Use this to send dhcp log messages to a different log file (you also
    # have to hack syslog.conf to complete the redirection).
    log-facility local7;
    
    # No service will be given on this subnet, but declaring it helps the 
    # DHCP server to understand the network topology.
    
    # Non mi convince (credo serva solo in reti più complesse) quindi lo tolgo.
    #subnet 192.168.100.0 netmask 255.255.255.0 {
    #}
    
    # Configurazione dello scope per la mia rete locale:
    subnet 192.168.100.0 netmask 255.255.255.0 {
    
    
    # Zona di forward di casa zone fracassetti.lan. { primary 127.0.0.1; } # Zona di reverse di casa zone 100.168.192.in-addr.arpa. { primary 127.0.0.1; }
    range 192.168.100.200 192.168.100.220; option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5; option domain-name "fracassetti.lan"; option routers 192.168.100.150; option broadcast-address 192.168.100.255; default-lease-time 600; max-lease-time 7200; }
    Questo è quasi il file di configurazione del server DHCP che conto di utilizzare. Ho rimosso alcune parti che non mi interessavano per risparmiare spazio ma in sostanza ho configurato il DHCP per una zona denominata "fracassetti.lan", per cui i DNS da distribuire sono 192.168.100.150, 208.67.222.222, 193.205.245.5, il DHCP è autorevole per la zona e la zona è relativa alla subnet 192.168.100.0/255.255.255.0.
    In aggiunta, il server DHCP potrà distribuire solo gli indirizzi IP compresi nel range tra 192.168.100.200 e 192.168.100.220, indicherà ai client di utilizzare l'indirizzo IP 192.168.100.150 (il proprio IP) come gateway e comunicherà come broadcast address l'IP 192.168.100.255

    La guida secondo me contiene un errore/imprecisione:
    codice:
    #  option domain-name-servers ns1.internal.example.org;
    Utilizzare per il formato "ns1.internal.example.org" per il "domain-name-servers" invece che l'indirizzo IP secondo me è sbagliato, quindi ho utilizzato l'indirizzo IP invece che il nome host. Usando il nome host il client non può essere in grado di risolvere il nome del DNS stesso e quindi di interrogarlo, a meno che non lo abbia nel file hosts ma mi sembra assurdo... Comunque la configurazione che ho indicato è provata e funzionante, quindi comunque sia è poco male.

    Il modo migliore per testare la configurazione è provarla. Il nome del servizio è diverso da quanto proposto da per ubuntu ed il comando per avviare il server DHCP diventa quindi:
    codice:
    sudo /etc/init.d/isc-dhcp-server start
    A questo punto, basta impostare un client per il DHCP e vedere se si prende l'indirizzo di rete.

    Direi che ci sono!

    Ora che il servizio DHCP è avviato, dal pulsante "List active Lease" nel modulo di configurazione del DHCP di webmin, posso vedere queli computer della rete sono registrati nel mio servizio DHCP. In particolare stò cercando questa riga:
    codice:
    192.168.100.201 	00:18:f3:82:82:fd 	salotto 	2011/07/30 13:34:04 	2011/07/30 13:44:04
    La seconda sezione è il MAC adddress della scheda di rete che ha ottenuto l'indirizzo IP. Questo dato identifica in modo univoco una determinata interfaccia di rete: Non ci dovrebbe essere, al mondo, un'altra scheda di rete con lo stesso indirizzo MAC. Usando questo dato posso dire al mio servizio DHCP di assegnare a quel pc sempre lo stesso indirizzo IP. Il file di configurazione definito per il mio servizio DHCP diventa quindi:
    codice:
    # Sample configuration file for ISC dhcpd for Debian
    #
    #
    
    # The ddns-updates-style parameter controls whether or not the server will
    # attempt to do a DNS update when a lease is confirmed. We default to the
    # behavior of the version 2 packages ('none', since DHCP v2 didn't
    # have support for DDNS.)
    ddns-update-style none;
    
    # option definitions common to all supported networks...
    option domain-name "fracassetti.lan";
    option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5;
    
    default-lease-time 600;
    max-lease-time 7200;
    
    # If this DHCP server is the official DHCP server for the local
    # network, the authoritative directive should be uncommented.
    authoritative;
    
    # Use this to send dhcp log messages to a different log file (you also
    # have to hack syslog.conf to complete the redirection).
    log-facility local7;
    
    # No service will be given on this subnet, but declaring it helps the 
    # DHCP server to understand the network topology.
    
    # Non mi convince (credo serva solo in reti più complesse) quindi lo tolgo.
    #subnet 192.168.100.0 netmask 255.255.255.0 {
    #}
    
    # Configurazione dello scope per la mia rete locale:
    subnet 192.168.100.0 netmask 255.255.255.0 {
    
    
    # Zona di forward di casa zone fracassetti.lan. { primary 127.0.0.1; } # Zona di reverse di casa zone 100.168.192.in-addr.arpa. { primary 127.0.0.1; }
    range 192.168.100.200 192.168.100.220; option domain-name-servers 192.168.100.150, 208.67.222.222, 193.205.245.5; option domain-name "fracassetti.lan"; option routers 192.168.100.150; option broadcast-address 192.168.100.255; default-lease-time 600; max-lease-time 7200; # pc salotto host salotto { hardware ethernet 00:18:f3:82:82:fd; fixed-address 192.168.100.201; } }
    Ultima modifica di frakka : 22-08-2011 a 15:13


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

Pagina 2 di 5
prima
1 2 3 4 5 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2018

Search Engine Optimization by vBSEO 3.6.1