[howto in lavorazione]firewall aziendale

[HexDEF6]

Ciao, sto lavorando su un firewall, per una rete che comprende:
-server in DMZ
-accesso via rete cablata (una LAN trusted)
-accesso via wireless

il firewall girera' su una macchina con 4 schede di rete
eth0: INTERNET
eth1: LAN TRUSTED
eth2: DMZ
eth3: WIRELESS

la rete sara' cosi composta:
*server di frontiera con 4 schede di rete, dove girera' il firewall e alcuni servizi (tipo samba) accessibili solo dalla rete LAN
*DMZ con un paio di server (web e forse posta... visto che abbiamo parecchi ip pubblici potrebbero essere raggiungibili su ip differenti al server di frontiera, che quindi si dovra' beccare magari 3 ip pubblici diversi sulla eth0)
*SERVER INTERNI in cui si faranno delle prove e saranno raggiungibili solo dalla LAN (praticamente si possono considerare come delle normalissime workstation nella LAN)
* X workstation che potranno accedere sia alla DMZ sia ai servizi sul server di frontiera
*X access point che verranno connessi alla eth3 del server di frontiera (ma questa parte sara' fatta con piu' calma) dalla wireless si potra solamente navigare in internet previa autenticazione, ma non si avra' accesso ne alla DMZ ne alla LAN ne ai servizi sul server di frontiera

CONFIG

IPT=/sbin/iptables
NET="eth0"
LAN="eth1"
DMZ="eth2"
WRL="eth3"
LO="lo"

IP_NET="10.10.10.10"
IP_LAN="192.168.10.1"
IP_DMZ="192.168.20.1"
IP_WRL="192.168.30.1"
IP_LO="127.0.0.1"
IP_UPDATE="10.20.0.1"
RANGE_IP_LAN="192.168.10.0/24"
RANGE_IP_DHCP="192.168.10.XX/YY"

G_DMZ.sh

#!/bin/bash

rm ./*.dmz

. ./CONFIG

for file in ./DMZ/*
do
ip=$(basename $file)

gawk '{ if (($1 != "") && ($2 == "")) IP_DMZ = $1
		if (($1 == "tcp") || ($1 == "udp")) {
			print "$IPT -t nat -A PREROUTING -i $NET -d " IP " -p " $1 " --dport " $2 " -j DNAT --to " IP_DMZ >> pre 
			print "$IPT -t nat -A POSTROUTING -o $NET -s " IP_DMZ " -p " $1 " --sport " $2 " -j SNAT --to-source " IP >> post 
		}
		if ($1 == "update") {
			print "$IPT -A dmz_to_net -s " IP " -d " $2 " -j dmz_to_net_update" >> update
			print "$IPT -t nat -A POSTROUTING -o $NET -s " IP_DMZ " -d " $2 " -j SNAT --to-source " IP >> snat_update
		}
	}
	END { print "$IPT -t nat -A PREROUTING -i $LAN -d " IP " -j DNAT --to " IP_DMZ >> pre
	print "$IPT -t nat -A POSTROUTING -o $LAN -s " IP_DMZ " -j SNAT --to-source " IP >> post }' IP=$ip pre=./prerouting.dmz post=./postrouting.dmz update=./update.dmz snat_update=./snat_update.dmz $file
done
chmod +x ./*.dmz

firewall.sh

#!/bin/bash


#faccio un source del file di configurazione (con le dichiarazioni delle reti ecc.)
. ./CONFIG

#lancio lo script che genera le regole di post e pre routing in base ai file di configurazione trovati in ./DMZ/
./G_DMZ.sh

#pulisco tutto
$IPT -F
$IPT -F INPUT
$IPT -F OUTPUT
$IPT -F FORWARD
$IPT -F -t mangle
$IPT -F -t nat
$IPT -X

#imposto il comportamento di default
$IPT -P INPUT DROP
$IPT -P OUTPUT DROP
$IPT -P FORWARD DROP


#abilito l'ip forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

#creo dei chan nuovi per "ogni" tipo di connessione (vedi sotto)
$IPT -N net_to_lan
$IPT -N lan_to_net
$IPT -N lan_to_net_dhcp
$IPT -N net_to_dmz
$IPT -N dmz_to_net
$IPT -N dmz_to_net_update
$IPT -N lan_to_dmz
$IPT -N lan_to_dmz_dhcp
$IPT -N dmz_to_lan
$IPT -N server_to_net

#accetto in input sull'interfaccia LO tutto quello che viene dagli ip locali
$IPT -A INPUT -p ALL -i $LO -s $IP_LO -j ACCEPT
$IPT -A INPUT -p ALL -i $LO -s $IP_LAN -j ACCEPT
$IPT -A INPUT -p ALL -i $LO -s $IP_NET -j ACCEPT
$IPT -A INPUT -p ALL -i $LO -s $IP_WRL -j ACCEPT

#giro le richieste http sul server in DMZ e faccio uno SNAT per le risposte 
#faccio DNAT e SNAT anche per gli utenti che chiamano IP_WEB dalla LAN
. ./prerouting.dmz
. ./postrouting.dmz

#snatto anche le connessioni fatte per fare l'update delle macchine
#da generare con uno script!
#$IPT -t nat -A POSTROUTING -o $NET -s $IP_WEB_DMZ -d $IP_UPDATE -j SNAT --to-source $IP_WEB

. ./snat_update.dmz

#source nat se esco su internet cambio l'ip del sorgente con l'ip pubblico di eth0
$IPT -t nat -A POSTROUTING -o $NET -s $RANGE_IP_LAN -j SNAT --to-source $IP_NET

#divido le connessioni (FORWARD) in base alla provenienza/destinazione per ora non prendo in considerazione la WRL
$IPT -A FORWARD -i $NET -o $LAN -j net_to_lan
$IPT -A FORWARD -i $LAN -o $NET -j lan_to_net
$IPT -A FORWARD -i $NET -o $DMZ -j net_to_dmz
$IPT -A FORWARD -i $DMZ -o $NET -j dmz_to_net
$IPT -A FORWARD -i $LAN -o $DMZ -j lan_to_dmz
$IPT -A FORWARD -i $DMZ -o $LAN -j dmz_to_lan

#gestisco input e output del server di frontiera in base alla rete di provenienza
#se proviene dall'interfaccia di rete INTERNET, accetto solo le connessioni related ed estabilished
$IPT -A INPUT -i $NET -m state --state RELATED,ESTABLISHED -j ACCEPT

#considero trusted la LAN, e quindi accetto tutte le connessioni provenienti da essa
$IPT -A INPUT -i $LAN -j ACCEPT

#il server di frontiera non dovrebbe ricevere nulla dalla DMZ, quindi loggo e droppo
$IPT -A INPUT -i $DMZ -j LOG --log-prefix input_dmz:
$IPT -A INPUT -i $DMZ -j DROP

#il server puo' fare connessioni verso l'esterno (solo quelle permesse in server_to_net)
$IPT -A OUTPUT -o $NET -j server_to_net

#il server puo' "uscire" verso la LAN trusted (non fondamentale, magari da sostituire con related e estabilished)
$IPT -A OUTPUT -o $LAN -j ACCEPT

#il server non puo' fare connessioni verso la DMZ, quindi loggo e droppo
$IPT -A OUTPUT -o $DMZ -j LOG --log-prefix output_dmz:
$IPT -A OUTPUT -o $DMZ -j DROP

#controllo i tentativi di connessione al web server in dmz forse basta quello il log in prerouting (e il drop?)
#da scriptare pure questo!
#da scriptare... e occhio perche' se ci sono piu' porte usate sullo stesso server e' un casino!
$IPT -A INPUT -i $NET -d $IP_WEB -j LOG --log-prefix ip_web:
$IPT -A INPUT -i $NET -d $IP_WEB -j DROP

#da internet verso la LAN accetto solo le connessioni related,estabilished
$IPT -A net_to_lan -m state --state RELATED,ESTABLISHED -j ACCEPT

#dalla LAN permetto di uscire su tutte le porte, tranne a chi e' in dhcp che viene rediretto in lan_to_net_dhcp
$IPT -A lan_to_net -s $RANGE_IP_DHCP -j lan_to_net_dhcp
$IPT -A lan_to_net -j ACCEPT

#limito la navigazione agli ip non statici o non registrati nel server dhcp....
$IPT -A lan_to_net_dhcp -p tcp --dport 80 -j ACCEPT
$IPT -A lan_to_net_dhcp -p tcp --dport 443 -j ACCEPT
$IPT -A lan_to_net_dhcp -p udp --dport 53 -j ACCEPT
$IPT -A lan_to_net_dhcp -p tcp --dport 21 -j ACCEPT
#....e loggo i tentativi di usare altre porte
$IPT -A lan_to_net_dhcp -j LOG --log-prefix lan_to_net_dhcp:
$IPT -A lan_to_net_dhcp -j DROP

#dalla DMZ verso internet accetto solo le connesioni related o estabilished, o per fare l'update della macchina...
$IPT -A dmz_to_net -m state --state RELATED,ESTABLISHED -j ACCEPT
#$IPT -A dmz_to_net -s $IP_WEB -d $IP_UPDATE -j dmz_to_net_update

. ./update.dmz

#e loggo tutto quello che prova ad accedere ad internet
$IPT -A dmz_to_net -j LOG --log-prefix dmz_to_net:
$IPT -A dmz_to_net -j DROP

#...se l'ip si trova nella lista degli update lascio passare la connessione
#ma loggo pure questo...da scriptare!
$IPT -A dmz_to_net_update -j LOG --log-prefix dmz_to_net_update:  
$IPT -A dmz_to_net_update -j ACCEPT

#accetto tutte le connessioni fatte dalla LAN verso la DMZ....
$IPT -A lan_to_dmz -s $RANGE_IP_DHCP -j lan_to_dmz_dhcp
$IPT -A lan_to_dmz -j ACCEPT

#....ma per ora non consento agli utenti dhcp di lavorare sulla DMZ
$IPT -A lan_to_dmz_dhcp -j LOG --log-prefix lan_to_dmz_dhcp:
$IPT -A lan_to_dmz_dhcp -j DROP

#dalla dmz verso la lan accetto solamente le connessioni related ed estabilished...
$IPT -A dmz_to_lan -m state --state RELATED,ESTABLISHED -j ACCEPT
#...e le altre le loggo
$IPT -A dmz_to_lan -j LOG --log-prefix dmz_to_lan:
$IPT -A dmz_to_lan -j DROP

#permetto al server di uscire sulle porte 80 21 443 e di risolvere i nomi
$IPT -A server_to_net -p tcp --dport 80 -j ACCEPT
$IPT -A server_to_net -p tcp --dport 21 -j ACCEPT
$IPT -A server_to_net -p tcp --dport 443 -j ACCEPT
$IPT -A server_to_net -p udp --dport 53 -j ACCEPT
#ma se prova a fare altro lo loggo
$IPT -A server_to_net -j LOG --log-prefix server_to_net:
$IPT -A server_to_net -j DROP

Per ora c'e' solo la base, quindi se avete suggerimenti sono ben accetti...
man mano che vado avanti aggiornero il post....

tra le cose da fare:
*sistemare il firewall per la wireless (i cui client probabilmente dovranno autenticarsi in qualche maniera... server radius?)
*possibilita' di connessione per una vpn (openvpn) da internet e dalla rete wireless per poter accedere ai servizi presenti sul server di frontiera, nella DMZ e nella LAN
*(forse) permettere l'uscita dalla LAN a solo certe porte (ssh, http, https, pops, imaps, smtp)
*far funzionare il tutto

Ciao!

[eclissi83]

interessante... potresti anche aver bisogno anche di fare traffic shaping e QoS per i servizi pubblici.. in una situazione del genere, ho fatto la configurazione di un bridge in modo da far essere il tutto trasparente...

buon lavoro!

[_YTS_]

ciao

ti consiglio anche di implementare una dmz ospiti che può sempre servire.

riguardo la wireless utilizzo in produzione il classico chillispot + radius e mysql.

per lo shaping, che non è molto semplice, ti consiglio tcng e qualche
lettura sul routing e qos, tipo il larc.

ti continuo a seguire e dove posso metto parola, ciao e buon lavoro.

[HexDEF6]

Intanto grazie in anticipo per consigli e suggerimenti...
per adesso non abbiamo ancora la connessione, quindi riusciro' ad aggiornare il post solamente una volta ogni tanto...

Originariamente inviato da _YTS_

ciao

ti consiglio anche di implementare una dmz ospiti che può sempre servire.

Questo mi risulta un po difficile per via del fatto che abbiamo degli switch sfigati (niente vlan o cose simili) e ho finito le schede di rete sul server

Originariamente inviato da _YTS_

riguardo la wireless utilizzo in produzione il classico chillispot + radius e mysql.

Hai un howto sottomano o qualche lettura da consigliare? e' la prima volta che metto mano seriamente al wireless, quindi non so nemmeno che opzioni ci sono!

Originariamente inviato da _YTS_

per lo shaping, che non è molto semplice, ti consiglio tcng e qualche
lettura sul routing e qos, tipo il larc.

avevo gia dato un'occhiata a http://www.lartc.org/ per un altro progetto... ma per ora non serve proprio... (per ora siamo in pochi e la prossima settimana ci arriva un'adsl di backup... poi piu' avanti ci arrivera' una CDN)

Originariamente inviato da _YTS_

ti continuo a seguire e dove posso metto parola, ciao e buon lavoro.

Come detto prima ti ringrazio gia in anticipo (e anche gli altri per eventuali consigli) e comunque per questa e la prossima settimana faro' pochi aggiornamenti...

Gia adesso il firewall e' totalmente diverso, ho diviso tutte le connessioni da una zona all'altra in modo da semplificarmi la vita!

Ciao

[HexDEF6]

ok...
ho modificato lo script...
come vedete dovrebbe essere piu' facile da leggere....
- so che ci sono delle cose che si potrebbero togliere (sicuramente delle regole in cui DROPPO, anche se poi la fine del pacchetto sarebbe quella lo stesso...)
- come vedete ho qualche dubbio sul prerouting (Droppare in prerouting non mi pare una buona idea, e nemmeno loggare... quindi probabilmente tolgo le 2 regole che tanto ho una regola in input che logga e droppa giusto?)

se avete suggerimenti, sono ben accetti!

[HexDEF6]

Altra modifica del firewall...
adesso mi genero la parte di DMZ con uno script in base a dei file di configurazione che si trovano nella sottodir DMZ
fatti in questo modo:
il nome del file deve essere l'ip pubblico del server
dentro il file dovrà essere fatto in questo modo:
nella prima riga dovrà esserci l'ip privato del server in dmz
poi le righe con scritto update e l'ip dei server che servono per fare gli update
poi il protocollo (tcp o udp) e la porta da rigirare nel server della dmz
esempio:
nome file: 210.20.30.40

192.168.20.20
update 150.150.150.150
update 150.150.150.151
tcp 80
tcp 22
udp 6000

Inoltre per chi volesse dare un occhio ai vari update ho messo su un svn:

http://supahlooza.homelinux.org/webs...%2F&rev=0&sc=0

Ciao!

P.S. dopo che ho finito questo probabilmente faro' un piccolo howto su svn

[WebWolf]

IpCop ?



(scherzo)

[HexDEF6]

Originariamente inviato da WebWolf

IpCop ?



(scherzo)

ipcop e' un po dura... visto che la macchina non fa solo da firewall... ma magari un shorewall potrebbe andare... ma io trovo piu' complicato shorewall che usare iptables direttamente

[WebWolf]

Originariamente inviato da HexDEF6

ipcop e' un po dura... visto che la macchina non fa solo da firewall... ma magari un shorewall potrebbe andare... ma io trovo piu' complicato shorewall che usare iptables direttamente

Mi sono sempre rifiutato di imparare ad usare Shorewall (anche se si integra bene con webmin - e me lo trovo spesso tra i piedi), hai tutta la mia comprensione.

Che distro pensi di usare per il tuo scopo ?

[HexDEF6]

Originariamente inviato da WebWolf

Mi sono sempre rifiutato di imparare ad usare Shorewall (anche se si integra bene con webmin - e me lo trovo spesso tra i piedi), hai tutta la mia comprensione.

Che distro pensi di usare per il tuo scopo ?

non posso pensare a che distro usare... mi e' stata imposta una red hat 4 AS
oltre al firewall, ci deve girare altra roba, del tipo file server (con backup automatico) svn, forse un server di posta interno... il tutto su un hardware stratosferico (un server rack dell poweredge 1950, con 2 processori xeon dual core e 4Gb di ram)...
quindi utilizzero il resto dell'hardware per farci girare qualche macchina virtuale (altrimenti lo vedo un po sprecato)!

Ciao!

Originariamente inviato da HexDEF6

non posso pensare a che distro usare... mi e' stata imposta una red hat 4 AS
oltre al firewall, ci deve girare altra roba, del tipo file server (con backup automatico) svn, forse un server di posta interno...
...
quindi utilizzero il resto dell'hardware per farci girare qualche macchina virtuale

beh quelle in grassetto sono almeno 3 macchine virtuali...
poi quando hai busogno di qualcosa di nuovo basta crearne un'altra...
non lamentarti perché è un'ottima distribuzione

[HexDEF6]

Originariamente inviato da matcy

beh quelle in grassetto sono almeno 3 macchine virtuali...

si, ma comunque sia la macchina e' decisamente sovrastimata (direi che un p3 a 1GHz sarebbe piu' che sufficente!)

Originariamente inviato da matcy

poi quando hai bisogno di qualcosa di nuovo basta crearne un'altra...
non lamentarti perché è un'ottima distribuzione

non metto in dubbio (anche se ho mollato red hat da anni), adesso pero' vedo se riesco ad avere la 5 al posto della 4 per via di alcune cose che vogliono usare(hanno bisogno della nuova versione di svn, php, mysql... e se inizio a compilarmeli io, che cacchio mi serve una redhat?????? e inoltre ho dei processori che supportano la virtualizzazione in hardware, e quindi un kernel recente sarebbe ottimo: o un 2.6.20 o uno di poco precedente, ma con patch per kvm), e visto che mi arrivano altri 4 server sempre con redhat 4 AS spero sia possibile fare l'upgrade senza smenarci molto!

se ti dico che mi sono scaricato 2 giorni fa la iso di centos5?
ovviamente se riesci passa a redhat5, la virtualizzazione in hardware va una merviglia e come hai detto non vale la pena di mettersi a compilare roba a mano se ti affidi al cappello rosso. o almeno non deve succedere già al primo giorno di attività del server.

partire con un sistema già smanettato non è mai bello. gli accrocchi si fanno in corsa per tirare avanti, non adesso.

se non ti comprano la rh5 vendi un processore.

[HexDEF6]

Originariamente inviato da matcy

se ti dico che mi sono scaricato 2 giorni fa la iso di centos5?

idem... gia fatto!

Originariamente inviato da matcy

ovviamente se riesci passa a redhat5, la virtualizzazione in hardware va una merviglia e come hai detto non vale la pena di mettersi a compilare roba a mano se ti affidi al cappello rosso. o almeno non deve succedere già al primo giorno di attività del server.

esattamente il mio pensiero... posso capire che fra 2 anni possa uscire qualcosa di nuovo e indispensabile, e magari mi tocca installarlo a mano... ma partire gia con un sistema mezzo compilato da me mi sembra una stupidata (mi conviene brasare RH e mettere su un debian/ubuntu/qualcos'altro)

Originariamente inviato da matcy

partire con un sistema già smanettato non è mai bello. gli accrocchi si fanno in corsa per tirare avanti, non adesso.

appunto

Originariamente inviato da matcy

se non ti comprano la rh5 vendi un processore.

il problema e' che hanno gia preso tutti i server con compresa redhat4, quindi io spero di poter fare un upgrade alla 5 in maniera indolore (economicamente parlando) anche perche' pagare 5 licenze con 3 anni di supporto (circa 1000 euro l'una) e poi lasciarle marcire mi farebbe girare un pochino le scatole!

Ciao

Originariamente inviato da HexDEF6

il problema e' che hanno gia preso tutti i server con compresa redhat4, quindi io spero di poter fare un upgrade alla 5 in maniera indolore (economicamente parlando) anche perche' pagare 5 licenze con 3 anni di supporto (circa 1000 euro l'una) e poi lasciarle marcire mi farebbe girare un pochino le scatole!

su questo sono curioso, ma diciamo che ci spero... fammi sapere perché sono curioso. non ho mai usato una redhat comprata, sempre usato centos per via di lavori fatti in casa zero spese...

[HexDEF6]

Originariamente inviato da matcy

su questo sono curioso, ma diciamo che ci spero... fammi sapere perché sono curioso. non ho mai usato una redhat comprata, sempre usato centos per via di lavori fatti in casa zero spese...

ok appena so qualcosa comunico....

[_YTS_]

ciao

riguardo l'uso del wireless eccone uno semplice semplice...

https://faberlibertatis.org/wiki/Hot...an_Sarge_HOWTO

in pratica:

qualsiasi client riceve un indirizzo ip dal dhcpd di chillispot e non da quello
del routerino che va disabilitato ovviamente.
non si deve usare crittazione alcuna in quanto ci pensa chillispot ad autenticare in https.

puoi giocare in varie maniere sulle conf, al fine di ottimizzare e o facilitare il login e/o quello che gli utenti possono fare.
personalmente autentico gli utenti in base al mac con ip statico e poi tramite
firewall garantisco permission ecc...

il top che ho in progetto è utilizzare snort_inline con iptables in modo tale
da segare immediatamente ogni abuso del servizio.

chiedi pure per info, ovviamente per la paranoia massima è possibile fare mille giochetti, ma il prob non sono questi ultimi, ma la mantenzione ordinaria che poi nel mio caso va demandata a personaggi non del settore, spero sia chiaro
dove voglio arrivare....

mi spiace per gli switch sfigati, ma se non ti servono le vlan non le usare,
talvolta portano molti problemi sopratutto se l'hardware è scarso e/o non si
sanno bene usare i vari accrocchi, vedi spanning-tree ecc..

ho letto che usi redhat che personalmente odio.....
io uso slackware in tutti i server in produzione che gestisco, ho anche server
con redhat per carità, anzi uno di questi è un resolver che è su da 1028 giorni,
a Pasqua abbiamo festeggiato
tuttavia non amo avere un server che appena installato mi succhia 200 mega di ram è mi avvia 800 servizi che non servono a nessuno e a niente....
perdo troppo tempo a metterla apposto e non ho necessità di avere nessun tipo di supporto da questo lato.
se scegli bene a priori l'hardware di cui avrai bisogno il supporto non ti serve a niente, esiste sempre una soluzione alternativa, o quasi sempre.
cmq visto che il tuo server è bello potente, potresti pensare di utilizzare xen
per dividere i servizi su piu macchine virtuali, avresti veramente un bel fortino poi da espugnare!

ti continuo a leggere, mi piace vedere qualcuno che progetta

oggi mi sono divertito con questo:

http://www.cipherdyne.org/blog/2007/...-matching.html

su un p3 1ghz ho messo su 5000 e passa regole di iptables su cui gira anche snort sulla rete pubblica aziendale, fico!!! devo fare un tuning fino di snort, tuning tcp, tuning kernel, e ottimizzazione finale di iptables, test con netperf,
test su ddos e synflood su tcp e flood su udp e icmp e test sui limiti e shaping e poi bho...
ma forse qui mi converrebbe passare altrove... openbsd e pf in primis.

byez

[HexDEF6]

Originariamente inviato da _YTS_

ciao

riguardo l'uso del wireless eccone uno semplice semplice...

https://faberlibertatis.org/wiki/Hot...an_Sarge_HOWTO

in pratica:

qualsiasi client riceve un indirizzo ip dal dhcpd di chillispot e non da quello
del routerino che va disabilitato ovviamente.
non si deve usare crittazione alcuna in quanto ci pensa chillispot ad autenticare in https.

puoi giocare in varie maniere sulle conf, al fine di ottimizzare e o facilitare il login e/o quello che gli utenti possono fare.
personalmente autentico gli utenti in base al mac con ip statico e poi tramite
firewall garantisco permission ecc...

grazie per il link... ci darò un'occhiata!

Originariamente inviato da _YTS_

il top che ho in progetto è utilizzare snort_inline con iptables in modo tale
da segare immediatamente ogni abuso del servizio.

snort e' un bell'oggetto, ma per poterlo mettere a posto decentemente ci si perde troppo tempo...
si vedra' piu' avanti per cose del genere....

Originariamente inviato da _YTS_

chiedi pure per info, ovviamente per la paranoia massima è possibile fare mille giochetti, ma il prob non sono questi ultimi, ma la mantenzione ordinaria che poi nel mio caso va demandata a personaggi non del settore, spero sia chiaro
dove voglio arrivare....

appunto!
comunque ti ringrazio gia in anticipo per l'offerta di aiuto!

Originariamente inviato da _YTS_

mi spiace per gli switch sfigati, ma se non ti servono le vlan non le usare,
talvolta portano molti problemi sopratutto se l'hardware è scarso e/o non si
sanno bene usare i vari accrocchi, vedi spanning-tree ecc..

alla fine mi bastano e avanzano, visto che mi hanno separato fisicamente la rete wired e wireless (siccome l'ufficio e' su 3 piani forse mi davano un solo collegamento tra piani, ma alla fine sono riuscito ad averne 2, e quindi gli AP vengono attaccati ad un altro switch e arriveranno al server attraverso un'altra interfaccia di rete)

Originariamente inviato da _YTS_

ho letto che usi redhat che personalmente odio.....

non sei il solo

Originariamente inviato da _YTS_

io uso slackware in tutti i server in produzione che gestisco, ho anche server
con redhat per carità, anzi uno di questi è un resolver che è su da 1028 giorni,
a Pasqua abbiamo festeggiato
tuttavia non amo avere un server che appena installato mi succhia 200 mega di ram è mi avvia 800 servizi che non servono a nessuno e a niente....
perdo troppo tempo a metterla apposto e non ho necessità di avere nessun tipo di supporto da questo lato.

io avrei usato volentieri qualsiasi altra cosa!, debian gentoo ubuntu.... forse la slack no (non mi e' mai piaciuta... ma credo siano gusti)

Originariamente inviato da _YTS_

se scegli bene a priori l'hardware di cui avrai bisogno il supporto non ti serve a niente, esiste sempre una soluzione alternativa, o quasi sempre.

l'hardware e' certificato redhat, ma funziona con qualsiasi distribuzione linux recente (knoppix e kanotix ci girano benone) ma come sempre le scelte hardware/software non le fanno i tecnici (e comunque hanno fatto l'ordine ancora prima che venissi assunto), ma il reparto acquisti, quindi questo ho e questo mi tengo (sperando almeno nell'upgrade della redhat... altrimenti mi tocchera mettere debian e far fare la muffa a 1000 euro di licenza)

Originariamente inviato da _YTS_

cmq visto che il tuo server è bello potente, potresti pensare di utilizzare xen
per dividere i servizi su piu macchine virtuali, avresti veramente un bel fortino poi da espugnare!

pensa che mi arrivano altri 4 server, solo di poco inferiori (xeon serie 5000 e non 5100... quindi niente virtualizzazione in hw e 2Gb al posto di 4)... praticamente ho piu' server che servizi!

Originariamente inviato da _YTS_

ti continuo a leggere, mi piace vedere qualcuno che progetta

oggi mi sono divertito con questo:

http://www.cipherdyne.org/blog/2007/...-matching.html

su un p3 1ghz ho messo su 5000 e passa regole di iptables su cui gira anche snort sulla rete pubblica aziendale, fico!!! devo fare un tuning fino di snort, tuning tcp, tuning kernel, e ottimizzazione finale di iptables, test con netperf,
test su ddos e synflood su tcp e flood su udp e icmp e test sui limiti e shaping e poi bho...
ma forse qui mi converrebbe passare altrove... openbsd e pf in primis.

byez

e' troppo figo fare esperimenti!

[flisi71]

Ciao HexDEF6, sempre su progetti interessanti sei coinvolto: prima il cluster HPC e adesso questo, complimenti!

E complimenti per l'hw, il PE 1950.
Qui al lavoro c'è un recentissimo suo fratello simile, il 2950, e va molto bene.
Corretta la valutazione di andare con RedHat, visto che la macchina è certificata con tale sistema operativo (e con SUSE Enterprise Server); al limite con CentOS vista la compatibilità con la distribuzione dal cappello rosso.

Converrai con me che ha ben poco senso acquistare un server di marca dove nel prezzo è compresa la certificazione con una distribuzione per poi....mettercene un'altra non certificata: valeva la pena allora acquistare un server assemblato.

Vista la potenza della macchina ti consiglio anch'io l'uso della virtualizzazione.
Io uso vmware server, e con questo potresti comunque virtualizzare macchine windows anche sulle macchine con Xeon 50xx che non supporta la virtualizzazione hw (che tra l'altro, almeno in combinazione a vmware, non da affatto brillanti prestazioni, questo anche a livello di test ben più rigorosi della mia esperienza personale ).

Originariamente inviato da HexDEF6

e' troppo figo fare esperimenti!

Se ti piace vedere tutto filare ragionevolmente liscio, non farli sui server di produzione.....



Ciao e tienici aggiornati


Federico

[HexDEF6]

eccomi qua dopo qualche tempo!
ho una domandina veloce veloce....

problema:
raggiungere i server in DMZ dalla rete interna (LAN)

se uso l'ip privato del server ovviamente non ho nessun problema,
se uso l'ip pubblico potrei risolvere facendo un DNAT e uno SNAT potrei aggiungere questo:

$IPT -t nat -A PREROUTING -i $LAN -d $IP_PUBBLICO -j DNAT --to IP_PRIVATO
$IPT -t nat -A POSTROUTING -o $LAN -s $IP_PRIVATO -j SNAT --to-source $IP_PUBBLICO

tutto bello tutto facile, ma questa cosa credo che creerebbe un casino di problemi se adesso voglio raggiungere il server usando direttamente l'ip privato, infatti la prima delle due regole non farebbe niente al pacchetto, ma la seconda mi farebbe lo snat lo stesso, e quindi mi ritroverei a fare delle richieste all'ip privato e mi risponderebbe quello pubblico.

Soluzioni idee?

Ovviamente la cosa "facile" da fare sarebbe quella di impostare il DNS interno a rispondere sempre con l'ip privato, ma se non voglio toccare il dns? (anche se basterebbe qualcosa come dproxy), ma se non voglio percorrere questa strada?

Ciao