cd /etc/ssl/certs & openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout mail.key -out mail.crt
openssl rsa -in mail.key -out mail.key & mv mail.key /etc/ssl/private

Assicuriamoci che l’utenza di sistema che mapperemo con quella per l’email appartenga al gruppo “mail” e cominciamo con le installazioni:

pacman -S postfix procmail dovecot spamassassin
configuriamo spamassassin:
groupadd -g 5001 spamd
useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin -m spamd
chown spamd:spamd /var/lib/spamassassin

tuniamo un po’ abbassando ad 1 il valore del parametro max-children (default=5), cio’ ci fara risparmiare parecchia ram:
vi /etc/conf.d/spamd

SAHOME=”/var/lib/spamassassin/”
SPAMD_OPTS=”-c –max-children 1 –username spamd -H ${SAHOME} -s ${SAHOME}spamd.log –pidfile /var/run/spamd.pid”

Configuriamo adesso DOVECOT per l’ IMAPssl e il pop3dssl con:
vim /etc/dovecot/dovecot.conf

protocols = imaps pop3s

disable_plaintext_auth = yes
log_timestamp = “%b %d %H:%M:%S ”

#ssl_disable = no

#i nostri certificati precedentemente creati
ssl_cert_file = /etc/ssl/certs/mail.crt
ssl_key_file = /etc/ssl/private/mail.key

mail_location = maildir:~/Maildir
mail_access_groups = mail
auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@

protocol imap {
imap_client_workarounds = delay-newmail tb-extra-mailbox-sep
}

protocol pop3 {
pop3_uidl_format = %08Xu%08Xv
#pop3_client_workarounds =
}

auth default {
mechanisms = plain login
passdb pam {
}
userdb passwd {
}
user = root
socket listen {
client {
path = /var/run/dovecot/auth-client
user = postfix
group = postfix
mode = 0660
}
}
}

Passiamo adesso alla configurazione di POSTFIX, (

cd /etc/postfix/

) cominciamo dal file principale:
vi main.cf

# Paths
queue_directory = /var/spool/postfix
daemon_directory = /usr/lib/postfix
command_directory = /usr/sbin
mail_owner = postfix
# Domain settings
myhostname = mail.nostrodominio.com
myorigin = nostrodominio.com
mydestination = $myhostname, localhost.$mydomain, localhost
# Timeout settings and other limits
delay_warning_time = 4h
unknown_local_recipient_reject_code = 450
minimal_backoff_time = 300s
maximal_backoff_time = 1200s
maximal_queue_lifetime = 1d
bounce_queue_lifetime = 1d
smtp_helo_timeout = 60s
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 12
# SMTP settings
smtpd_tls_cert_file=/etc/ssl/certs/mail.crt
smtpd_tls_key_file=/etc/ssl/private/mail.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_tls_loglevel = 1
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination,
#postgrey
check_policy_service inet:127.0.0.1:10030
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks
smtpd_sasl_security_options = noanonymous
# SASL
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/run/dovecot/auth-client

# Network settings
inet_interfaces = all
inet_protocols = ipv4
mynetworks = 127.0.0.0/8
relayhost =
# Email and mailbox settings
alias_maps = hash:/etc/postfix/aliases
alias_database = $alias_maps
home_mailbox = Maildir/
virtual_alias_domains = miodominio.com eventualealtrodominio.org
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_size_limit = 0

# Misc
mailbox_command = /usr/bin/procmail
smtpd_banner = $myhostname ESMTP banner_che_vogliamo
biff = no
append_dot_mydomain = no
debug_peer_level = 2
sendmail_path = /usr/sbin/sendmail
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/man
sample_directory = /etc/postfix/sample
readme_directory = no
recipient_delimiter = +

Mappiamo adesso utenza sys/utenza email inserendo le informazioni opportune con:
vi /etc/postfix/virtual

utenteemail@dominiomio.com utentesistema@localhost
utente2mail@altrodominio.org utentesistema2@localhost
#etc.

lanciamo adesso il comando:

postmap /etc/postfix/virtual

alliniamo adesso a spamassassin postfix configurando il suo vero motore principale:
vi master.cf e aggiungiamo/modifichiamo

smtp inet n – n – – smtpd
-o content_filter=spamassassin
spamassassin unix – n n – – pipe
user=spamd argv=/usr/bin/perlbin/vendor/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}

Configuriamo spamassassin:
vi /etc/mail/spamassassin/local.cf

rewrite_header Subject *****SPAM*****
required_score 3
report_safe 0 #1
use_bayes 1
use_bayes_rules 1
bayes_auto_learn 1

Diciamo adesso a procmail come istruire le emails marchiate da spamassassin:
vi /etc/procmailrc

DROPPRIVS=yes
DEFAULT=$HOME/Maildir/
MAILDIR=$HOME/Maildir/
:0:
* ^X-Spam-Status: Yes
.Junk/

Postgrey:
yaourt -S postgrey
configuriamo con
vi /etc/conf.d/postgrey

POSTGREY_TYPE=”inet”
POSTGREY_HOST=”127.0.0.1″
POSTGREY_PORT=”10030″
POSTGREY_SOCKET=”/var/spool/postfix/private/postgrey”
POSTGREY_OPTS=”–delay=60″

Infine creiamo la Maildir per l’utente:

cd ~utente
umask 077
mkdir -p Maildir/{cur,new,tmp}
mkdir -p Maildir/.Drafts/{cur,new,tmp}
mkdir -p Maildir/.Sent/{cur,new,tmp}
mkdir -p Maildir/.Trash/{cur,new,tmp}
chmod -R 0700 Maildir
chown -R utente:users *

Riavviamo adesso tutti i servizi legati al mail server

/etc/rc.d/postgrey start
/etc/rc.d/spamd start
/etc/rc.d/dovecot start
/etc/rc.d/postfix start

..e configuriamoci i nostri clients di posta.

SQL> CREATE OR REPLACE TRIGGER trace_logon
2 after logon on database
3 begin
4 if ( sys_context(‘USERENV’, ‘SESSION_USER’) in (‘N00b1′, ‘Noob2′))
5 then
6 execute immediate ‘alter session set timed_statistics=true’;
7 execute immediate ‘alter session set max_dump_file_size=10000′;
8 execute immediate ‘alter session set tracefile_identifier=”Noobs”;
9 execute immediate ‘alter session set events ”10046 trace name context forever, level 12”’;
10 end if;
11 end;
12 /

SQL> CREATE OR REPLACE TRIGGER trace_logoff before logoff on database
2 begin
3 if ( sys_context(‘USERENV’, ‘SESSION_USER’) in (‘N00b1′,’Noob2′))
4 then
5 execute immediate ‘alter session set events ”10046 trace name context off”’;
6 end if;
7 end;
8

PS:
tkprof $ORACLE_BASE/diag/rdbms/prod/prod/trace/*Noobs….* $ORACLE_HOME/*Noob….*.out sys=no print=10 sort=fchela

#!/bin/sh
#rebuilder script
#trova indici e ricostruisce
#Tempesta Piergiorgio 06/05/2010
. /home/oracle/.env11g
SCRIPT_DIR=/home/oracle/Tempesta
/home/oracle/app/product/11.2.0/bin/sqlplus -s /nolog < set feed off pages 1000 lines 120 echo off verify off
connect system/"password"
spool ${SCRIPT_DIR}/allIndex.sql
select 'ALTER INDEX "' || table_owner ||'"."'|| index_name || '" REBUILD;' from all_indexes;
spool off
EOF
/bin/sed /TABLE_OWNER/d allIndex.sql > allIndex2.sql
/bin/sed /———–/d allIndex2.sql > allIndex3.sql
/home/oracle/app/product/11.2.0/bin/sqlplus -s /nolog< connect SYSTEM/"password"
spool ${SCRIPT_DIR}/risultato.out select to_char(sysdate,'DD/MM/YYYY HH24:MI:SS') from dual;
@${SCRIPT_DIR}/allIndex3.sql
select to_char(sysdate,'DD/MM/YYYY HH24:MI:SS') from dual;
spool off
EOF
exit 0

L’aspetto fondamentale che questo sistema dovrà esaudire è cio’ che viene prescritto nel capitolo 4.5:
sulla “Registrazione degli accessi”
“Devono essere adottati sistemi idonei alla registrazione degli accessi logici (autenticazione informatica) ai sistemi di elaborazione e agli archivi elettronici da parte degli amministratori di sistema. Le registrazioni (access log) devono avere caratteristiche di completezza, inalterabilità e possibilità di verifica della loro integrità adeguate al raggiungimento dello scopo di verifica per cui sono richieste.”

Il sistema infatti si occuperà di delegare verso un unico server tutti gli accessi degli amministratori (root per macchine UNIX/LINUX e administrator su Domain controller e/o servers Windows ) della vostra rete, utilizzando un syslog centralizzato e un sistema di memorizzazione a scelta tra:
- i piu costosi devices WORM (Write Once Read Many);
- il gratuito UDF (anche lui scrivibile una sola volta come sui sistemi WORM…. anzi in realtà il 99% dei device WORM usano proprio UDF eheheh );
- ISO9660 magari incapsulandolo in una comunissima immagine ISO;
- o addirittura il performantissimo e almeno per me “nuovo” NILFS (che uso ultimamente sulle /etc dei miei servers linux) , un filesystem a snapshot continui ( http://www.nilfs.org/en/ – “NILFS is a log-structured file system supporting versioning of the entire file system and continuous snapshotting which allows users to even restore files mistakenly overwritten or destroyed just a few seconds ago.”);
Il tutto “accompagnato” magari da un bel HASH corrispondente

Partiamo subito con qualche specifica:
Il sistema potrà essere composto da un normalissimo pc i386 (non servono grossi requisiti hardware) con installata una qualsiasi distribuzione linux totalmente hardenizzata..
io per ulteriore sicurezza ho utilizzato un kernel 2.6.27-10 patchato con grsecurity/pax in modo da limitare (attraverso apposite ACL) perfino le operazioni di root (quando avro’ tempo magari vi parlero’ di grsec ) e non ho lasciato, nessun servizio in ascolto (ovviamente nemmeno sshd).
Il servizio di logs centralizzato è servito dal demone syslog che riceve sulla porta 514 UDP i logs delle autenticazioni
da tutte le macchine del nostro CED (nel mio caso gli os maggiormente usati: tru64, hpux e windows).
Il file di configurazione del syslog centralizzato sarà quindi:

#
# /etc/syslog.conf
#

*.emerg *
*.err /var/log/errors
kern.* /var/log/kernel
authpriv.* /var/log/auth
mail.* /var/log/mail
*.!err;mail,kern.none /var/log/messages
auth.info /var/log/SERVERSlogs/auth.info
# Log everything to vc12
# *.* /dev/vc/12

# End of file

In questo post in merito alla fase della memorizzazione dei logs utilizzero’ il filesystem Iso9660 incapsulato in un immagine ISO (inalterabile nel contenuto come vuole il decreto) e sopratutto “depositata” corrispondentemente ad un HASH (ho usato SHA256).

[Piu' avanti, in merito alla memorizzazione dei logs, se avro' tempo magari vi descrivero' altri metodi utilizzando per esempio UDF, WORM o sopratutto NILFS....]

Tale filesystem è stato scelto sia per la sua particolare caratteristica “WORM” ( Write Once Read Many ) sia per la sua compatibilità a sistemi operativi diversi sia ,non meno, alla possibilità di organizzare ogni 6 mesi o prima (come descrive il decreto stesso) una masterizzazione su CD/DVD..
(Io ho preferito utilizzare le immagini ISO ma potremmo perfettamente scrivere direttamente sul DVD senza passare per le ISO utilizzando il già citato UDF e considerando che per aggiungere dati ad un dvd contente altri dati possiamo usare il comando:

# growisofs -M /dev/dvd /tmp/file_da_aggiungere

)

..ecco gli scripts che opportunamente inseriti in crontab si occuperanno di fare cio’ che ho descritto:
(PS: occupatevi di crearvi prima le directory )

#!/bin/bash
chattr -i -R /root/StoricoLogs
mv /var/log/SERVERSlogs/auth.info /root/StoricoLogs/complauth.info
egrep ‘(dmin|root)’ /root/StoricoLogs/complauth.info > /root/StoricoLogs/`date +%Y%h%d_%H%M`
shasum /root/StoricoLogs/`date +%Y%h%d_%H%M` > /root/StoricoLogs/hashlog`date +%Y%h%d_%H%M`
rm /root/StoricoLogs/complauth.info
chattr +i -R /root/StoricoLogs/*
/etc/rc.d/syslogd restart

questo catalogherà i logs ricevuti su syslog, li filtrerà (prenderà tutto cio’ che riguarda l’auth di utenti root e administrator) e infine creerà un HASH corrispondente allo STEP attuato, riavviando successivamente syslog..

#!/bin/bash
chattr -i /root/StoricoLogs/*
mkisofs -input-charset=utf-8 -J -l -V “`date +%Y%h%d`_Log” -o /root/IsoLogs/`date +%Y%h%d`.iso /root/StoricoLogs/
rm /root/StoricoLogs/*
rm /root/auth

Quest’altro produrrà l’ISO corrispondente allo “STEPlogs” in corso utilizzando come “etichetta” la data/orario di produzione e cancellando successivamente le tracce in modo da ricominciare con un nuovo STEP successivo.

Passiamo adesso alla configurazione dei Client da dove prelevare i logs:
ovviamente @Logserver è l’host corrispondente al nostro serverlogs (inserite la corrispondenza host->ip sul file /etc/hosts oppure nello script inserite @ip)

HPUX 11.x o Linux:

# @(#)B11.23_LR
#
# syslogd configuration file.
#
# See syslogd(1M) for information about the format of this file.
#
mail.debug /var/adm/syslog/mail.log
*.info;mail.none /var/adm/syslog/syslog.log
*.alert /dev/console
*.alert root
*.emerg *
auth.info @logserver

Tru64 4*:

#
# @(#)$RCSfile: syslog.conf,v $ $Revision: 4.1.8.1 $ (DEC) $Date: 2000/10/19 19:13:52 $
#
#
# syslogd config file
#
# facilities: kern user mail daemon auth syslog lpr binary
# priorities: emerg alert crit err warning notice info debug
kern.debug /var/adm/syslog.dated/kern.log
user.debug /var/adm/syslog.dated/user.log
mail.debug /var/adm/syslog.dated/mail.log
daemon.debug /var/adm/syslog.dated/daemon.log
auth.debug /var/adm/syslog.dated/auth.log
auth.info;auth.debug @logserver
*.info;syslog.debug /var/adm/syslog.dated/syslog.log
lpr.info /var/adm/syslog.dated/lpr.log

msgbuf.err /var/adm/crash/msgbuf.savecore

kern.debug /var/adm/messages
*.alert;kern.debug /dev/console
*.emerg *

e infine lo “zoccolo duro” ehhmmm scherzo WINDOWS:
Per windows (nel mio caso 2003 server e) dovremmo trovare un buon prodotto in grado di “tradurre”
il sistema dei logs microsoft (EVENTLOGS) per il nostro sistema (SYSLOG)..
esistono diverse possibilità, io ho optato per questa: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys
installatelo e configuratelo seguendo queste semplicissime istruzioni http://eventlog-to-syslog.googlecode.com/files/Readme_4.1.rtf

il sistema è pronto per l’uso date la passwd di root al vostro incaricato e ditegli di cambiarla:
da questo momento solo lui, sarà in grado di visualizzare/conservare (ma non modificare) i logs accedendo esclusivamente fisicamente alla console della macchina..
io ho installato una GUI minimale (lxkde) e un frontend di masterizzazione (k3b o brasero) per rendergli le operazioni piu’ semplici
ciao!

apparte le mie paranoie digitali quindi cominciamo subito con lo scegliere cosa usare per condividere ai nodi del nostro cluster un unico filesystem..

per realizzare cio’ ho optato per DRBD (dovrebbe essere l’acronimo di distribuited
replicated block device”)..praticamente non è altro che un RAID1 (un mirror)
tra due dispositivi di rete: il suo lavoro è quello di propagare dati da un nodo all’altro(sincronizzare praticamente)..

Partizioniamo su ogni nodo la “parte” che dedicheremo al nostro sistema (non vi dico come si fa, lo sapete già questo) questa partizione verà “letta” dal DRBD che abbiamo installato sul nodo e verà cosi creato il device /dev/drbd*..
lo stesso DRBD poi, attraverso il suo file di configurazione /etc/drbd.conf stabilirà se scrivere o meno sul device in questione (questo in base ai criteri del nodo, se questo è primario allora potrà montare il device in +w).

Per avere una più affidabile configurazione del nostro cluster sarà meglio utilizzare 2 schede di rete ridondanti per ogni nodo, per farlo basterà abilitare il modulo “bonding” del kernel (trovate il modulo sotto “NEtwork device” nel menuconf del kernel) e quindi per ogni nodo del cluster dare:

#modprobe bonding {attiviamo il modulo del kernel linux per il bonding}
#ifconfig bind0 “ip” up {attiviamo l’interfaccia di bonding}
#ifenslave bond0  eth0 eth1 {creiamo il channel bonding nel nostro nodo}

..creeremo quindi anche uno script che faccia il tutto ad ogni riavvio della macchina
in /etc/rc.d/net.bond0 configurando anche /etc/rc.d/ifenslave
(i path ovviamente possono variare a secondo della distribuzione linux che usate

perfetto, dando adesso per scontato che abbiate “fisicamente” predisposto il cluster
[cavo cross tra le schede di rete] [poi vedremo anche di usare un cavo seriale tra
le due porte seriali ] e partizionato le 2 porzioni di fs dedicate a DRBD su ogni nodo.

Configurate DRBD [/etc/drbd.conf] seguendo il solito file di configurazione di esempio
e create quindi il famoso device con:

#mknod -m 0760 /dev/drbd0 b 147 0

avviamo il servizio:

#/etc/rc.d/drbd start

montiamo adesso sul primo nodo il device come master:

#drbdadm — –do-what-I-say primary shared

in questa maniera il device è già su ed è possibile,
dal nodo primario, montare su /shared la nostra partizione condivisa con DRBD..
ovviamente se volete potrete anche utilizzare LVM sui due nodi creando il volume
corrispondente al device di DRBD /dev/drbd0 su ogni macchina del cluster.

per poter gestire adesso il failover del nostro servizio nel nostro cluster useremo Heartbeat:
prima di tutto configuriamo sui due nodi, seguendo il solito esempio, il file ha.cf

## /etc/ha.d/ha.cf
keepalive 1
deadtime 20
warntime 3
initdead 20
serial /dev/ttyS0
bcast eth1
auto_failback yes
node host_del_nodo1
node host_del_nodo2
crm no

successivamente configuriamo /etc/ha.d/haresources sui due nodi inserendo le risorse che migreremo tra le due macchine (quindi nel nostro caso l’unico servizio per il failover è quello di drbd):

hostnodo1 drbddisk::shared script_avvio_lvm Filesystem::/dev/drbd0::/shared0::fs_scelto

(se non lo avete fatto: attivate il supporto a watchdog del kernel e create il corrispondente device:

#mknod /dev/watchdog c 10 130 )

per una maggiore sicurezza infine nel file /etc/ha.d/authkeys impostiamo la crittografia dei dati
tra i nodi:

## /etc/ha.d/authkeys
auth 1
1 sha HeartbeatPassword

diamo i permessi:

# chmod 600 /etc/ha.d/authkeys

e infine riconfiguriamo l’altro nodo con le stesse impostazioni oppure
piu semplicemente:

#scp /etc/ha.d/authkeys root@nodo2:/etc/ha.d/

prima di concludere il tutto vi consiglio un breve periodo di test ed infine un buon tuning per
una piu’ appropiriata scelta dei deadtimes di heartbeat e di tutti gli altri parametri e/o dei filesystem per le partizioni di drdb

PS: Appena avro’  tempo scrivero’ qualche altro appunto in merito alla possibilita’ del load-balancing su linux

utilizzando un unico host con LVS e i nodi linux-director

Saluti!

- pvcreate /dev/rdsk/c5t0d1

- pvcreate /dev/rdsk/c5t0d0

- mkdir /dev/vg01

- mknod /dev/vg01/group -c 64 0×010000

- vgcreate vg01 /dev/dsk/c5t0d1 /dev/dsk/c5t0d0

..creiamo adesso un LV con lx4Mb =50×4 = 200Mb

- lvcreate -l 50 -n mirror vg01

..creiamo adesso il mirror

- lvextend -m 1 /dev/vg01/mirror

- lvdisplay /dev/vg01/mirror

..inizializziamo LV e montiamolo

- newfs /dev/vg01/mirror

su fstab inseriamo quindi:

/dev/vg01/mirror /hd2mirror vxfs delaylog 0 2

In particolare ho voluto emulare Zeroshell net services una nuova piccola distribuzione per server e dispositivi embedded configurabile ed amministrabile via web tramite un browser..

vorrei fare connettere la nostra macchina virtuale con zeroshell nella mia LAN ed evitare di fare routing col portatile, decido di utilizzare quindi la macchina reale come proxy arp:

modprobe tun
tunctl -t tap0
chmod 666 /dev/net/tun
brctl addbr br0
ifconfig eth0 10.0.2.2 promisc
brctl addif br0 eth0
dhclient br0
brctl addif br0 tap0
ifconfig tap0 10.0.2.2 up
echo 1 > /proc/sys/net/ipv4/conf/tap0/proxy_arp
route add -host 10.0.2.2 dev tap0
arp -Ds 10.0.2.2 eth0 pub

..in questa maniera abbiam creato un bridge br0 e abbiamo associato la nostra interfaccia di rete fisica eth0 diventata così porta logica del bridge (per il nostro caso non necessita di alcuna assegnazione particolare..)

successivamente abbiamo assegnato un ip (nel caso particolare attraverso dhclient) della nostra lan per la “nuova” interfaccia della macchina reale.

Passiamo adesso a qemu-kvm e lanciamo quindi la nostra ZeroShell e vediamo come decidere per lei in modo che si interfacci attraverso il nostro bridge..

Tramite questo script switcheremo sull’ interfaccia di rete virtuale la macchina emulata:

#!/bin/sh

echo “Executing /etc/ifupScript…”
echo “Bringing up $1 for bridged mode…”
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo “Adding $1 to br0…”
sudo /usr/sbin/brctl addif br0 $1
sleep 2

quindi..

ricordiamoci i moduli: modprobe kvm kvm_intel;

..poi creiamo un img raw per contenere (nel caso in cui volessimo installare zeroshell su hd) il sistema operativo emulato… ed io mi tengo veramente largo e decido per 1 giga:

qemu-img create /root/Zeroshell 1G

e infine lanciamo il livecd di Zeroshell attraverso qemu specificando architettura, memoria ,device e il boot della macchina emulata:

qemu-kvm -M pc -m 512 -cdrom /root/ZeroShell-1.0.beta7.iso -hda /root/Zeroshell -net nic,vlan=0,ifname=tap0,script=/etc/ifupScript -monitor pty -boot d
una volta partito il sistema emulato dobbiamo ovviamente configurare almeno la rete..nel mio caso, userò solo dhclient:

..in questa maniera, adesso, dalla LAN a cui son connesso col portatile chiunque potrà provare Zeroshell specialmente attraverso il proprio browser sul tool di amministrazione:

attraverso questa comoda ed elegante interfaccia è possibile configurare con successo (ho provato quasi tutto il possibile con esito più che positivo):

• server RADIUS (con gestione chiavi di cifratura per Wireless 802.11b, 802.11g e 802.11; wpa e wpa2; e instradare da server radius dietro le piu svariate direttive (autenticazioni, mac acl e altro) su VLAN 802.1Q assegnata ad un essid. (ho già in mente di comprare una nano px e installare la versione zeroshell per compact flash.. e farci un bel mini sistema embedded.. )
• Captive Portal per il supporto del web login su reti wireless e wired. ( avete presente gli HotSpot ? );
• Gestione del QoS (Quality of Service) e traffic shaping per il controllo del traffico.
• VPN host-to-lan.VPN lan-to-lan in tunnel SSL/TLS, con supporto per VLAN 802.1Q.
• Router con route statiche e dinamiche;Bridge 802.1d con protocollo Spanning Tree per evitare loop anche in presenza di percorsi ridondati;
• Firewall Packet Filter e Stateful Packet Inspection (SPI) con filtri applicabili sia in routing sia in bridging su tutti i tipi di interfaccia di rete comprese le VPN e le VLAN;Controllo mediante Firewall e Classificatore QoS del traffico di tipo File sharing P2P; NAT;TCP/UDP port forwarding (PAT) (vps ? ;
• Server DNS multizona e con gestione automatica della Reverse Resolution in-addr.arpa;
• Server DHCP multi subnet (con gestione dei mac address)
• Virtual LAN 802.1Q (tagged VLAN) applicabili sulle interfacce Ethernet, sulle VPN lan-to-lan, sui bonding di VPN e sui bridge composti da interfacce Ethernet, VPN e bond di VPN;
• Client PPPoE per la connessione alla WAN tramite linee ADSL, DSL e cavo;
• Client DNS dinamico che permette la rintracciabilità su WAN anche quando l’IP è dinamico (ddclient, no-ip etc..)
• Gestione dinamica del record dns MX per l’instradamento SMTP della posta elettronica;
• Server e client NTP (Network Time Protocol);
• Server syslog;
• Autenticazione Kerberos 5 mediante un KDC integrato e cross autenticazione tra domini;Autorizzazione LDAP, NIS e RADIUS;Autorità di certificazione X.509 per l’emissione e la gestione di certificati elettronici;
• Integrazione tra sistemi Unix e domini Windows Active Directory in un unico sistema di autenticazione e autorizzazione mediante LDAP e Kerberos 5 cross realm authentication.

L’interfaccia è ancora incompleta perchè mancano un po’ di features fighe che ci vedo.. ma guardando sul sito ufficiale pare che ci stiano lavorando su bene e le prospettive sono più che buone Per quello che c’è su adesso va più che bene.. poi che aggiungere? Comoda e veloce anche quando virtualizzata dietro qemu-kvm.

Il mio caso è quello di una vpn tls (con certificati ssl) a stella(connessione da un server centrale verso diversi clients), una vera e propria intranet attraverso una rete pubblica (internet).

Per prima cosa ho creato i certificati con openssl:

openssl genrsa -out ca.key
openssl req -new -key ca.key -out rich.ca
openssl x509 -req -in rich.ca -signkey ca.key -out ca.cert
openssl genrsa -out server.key
openssl req -new -key server.key -out rich.ser
openssl x509 -req -in rich.ser -CA ca.cert -CAkey ca.key -CAcreateserial -out ser.cert
openssl dhparam -out dh.pem 1024

dopo i due file di configurazione per la vpn,

quello del lato server:

dev tap #device utilizzato (da abilitare nel kernel)
proto tcp-server #protocollo di connessione
ifconfig 192.168.0.1 255.255.0.0 # IP del server all interno della vpn
tls-server # Specifica il tipo di server ssl (unico possibile per vpn a stella)

key ca.key
dh dh.pem
ca ca.cert
cert ca.cert
local 10.0.0.149 # IP locale “reale” della macchina che ospita il server vpn

lport 5002 #porta di comunicazione
verb 4 #verbosità dei logs

mode server #modalità vpn
duplicate-cn

;ifconfig-pool 192.168.0.10 192.168.0.50 #possibilità di ip automatico (tipo dhcp) allinterno del range descritto (io avevo necessita di ip statici indi non ho usato questa funzionalità)
mssfix 1450
client-to-client #i clients si vedono tra loro

;push “ping 10″
;push “ping-restart 60″
;ping 10
;ping-restart 120

comp-lzo #compressione dei dati

.. e quello del client:

remote *.*.*:* #ip publico remoto

rport 5002 #porta
proto tcp-client #protocollo

tls-client #modalita del client ssl
dev tap #device usato (anche qui da compilare nel kernel)

ifconfig 192.168.2.9 255.255.0.0 #ip statico per la vpn (nel caso di indirizzamento dinamico dhcp non serve questa linea)

key ca.key
ca ca.cert
cert ca.cert

pull
comp-lzo #compressione dati
verb 4 #verbosità dei logs

fatto questo basterà far partire la vpn dal server e dai rispettivi client

cd /etc/openvpn

#(path dei file di configurazione ma sopratutto delle chiavi e certificati)

openvpn –config filediconfigurazione.ovpn –daemon

questa vpn è stata provata con client su diverse piattaforme (anche windows)

Oltre IPFW, di cui abbiamo già detto qualcosa prima, esiste anche il
demone natd, questa applicazione consente di effettuare le più avantate
tecniche di NAT (Network Address Translation) e di PAT (Port Address
Translation)…

..intanto ricompiliamo il kernel abilitando i seguenti moduli:
(compilare un kernel freebsd se siete già abituati con linux è veramente
semplice)
piazzate un file di configurazione su /usr/src/sys/i386/conf magari
riprendendo quello del kernel custom e aggiungendo
#
options IPFIREWALL # firewall
options IPFIREWALL_VERBOSE # abilita il logging
#options IPFIREWALL_DEFAULT_TO_ACCEPT # autorizza tutto per default
options IPDIVERT # divert sockets
#

chiamiamo MYKERNEL il nuovo file di conf del kernel ecompiliamo con:
# /usr/sbin/config MYKERNEL
andiamo poi nel dir di compilazione di Freebsd
# cd compile/MYKERNEL
e via:
# make depend
# make
# make install

adesso possiamo attivare anche il demone natd editando il solito
/etc/rc.conf così:
# impostazioni di rete
defaultrouter=”200.201.202.254″
gateway_enable=”YES”
hostname=”sticazzi.dominio.com”
ifconfig_xl0=”inet 200.201.202.140 netmask 255.255.255.248″
ifconfig_xl1=”inet 192.168.0.254 netmask 255.255.255.0″
#
# impostazione del firewall ed del nat
firewall_enable=”YES” # abilita firewalling
firewall_type=”OPEN” # script standard /etc/rc.firewall
natd_enable=”YES” # abilita il demone natd
natd_interface=”xl0″ # interfaccia che esegue il forwarding
natd_flags=”-f /etc/natd.conf” # configurazioni addizionali per il natd

La prima parte è quella espressamente dedicata al networking: viene
definito il gateway, si abilitata la regola che consente il
packetforwarding e vengono impostate le interfaccie di rete del nostro
sistema.
la seconda parte riguarda l’abilitazione del firewall, l’abilitazione del
demone natd, la definizione dell’interfaccia di rete che eseguirà la
traduzione degli indirizzi con la definizione del file che conterrà le
impostazioni principali per il demone natd.
Nel nostro esempio stiamo trattando un sistema con 2 interfacce di rete
(dual-homed host), dove l’interfaccia xl0 fa parte della rete internet
pubblica mentre l’interfaccia xl1 fa parte di una rete privata.
L’interfaccia pubblica è quella che traduce gli indirizzi e le porte
eseguendo il NAT (Network Address Translation) o il PAT (Port Address
Translation). Per definire le regole che verranno utilizzate dal demone
natd e per dare corso alla traduzione degli indirizzi e delle porte,
dovremo creare il file di configurazione del natd /etc/natd.conf:
interface xl0
use_sockets yes
same_ports yes

Nel file viene definita l’interfaccia di rete che eseguirà il NAT, le
istruzioni use_socket yes e same_ports yes sono fondamentali per il
corretto funzionamento di alcuni protocolli applicativi (layer7) come
l’FTP (File Transfer Protocol) e l’IRC (Internet relay chat).
adesso potete anche riavviare la vostra macchina
In queste condizioni operative la base di protezione è nulla. Lo script
/etc/rc.firewall consente accesso a tutti i servizi che sono attivi sulla
macchina eseguendo il solo demone natd.
Eccovi un
esempio di
firewall dual-homed con regole stringenti e sicure. Verrà eseguito il NAT,
il PAT e verranno bloccati tutti gli accessi da reti e da host non
autorizzati inclusa la tecnica di mascheramento degli indirizzi ip
denominata ipspoofing.

FreeBsd come altri sistemi operativi fornisce diversi strumenti per filtrare e gestire
pacchetti..il mio preferito che è anche quello nativo per eccellenza è IPFW….dicevo nativo..si
perchè IPFW viene compilato nel kernel e consente di utilizzare FreeBSD sia come strumento per il
filtraggio dei pacchetti (Packet Filter Firewall) che come strumento di analisi dei pacchetti che
lo attraversano grazie alle sue capacità statefull inspection..
Un firewall di tipo packet filter è fatto solitamente per l’ esclusiva gestione di sistemi dedicati
alla protezione di reti e necessita di una memoria RAM molto limitata..
Gli statefull inspection invece richiedono diversa memoria per via del lavoro di “analisi e
gestione” all’ interno delle molteplici interfacce di rete istallate nel sistema (guarda
/etc/rc.conf)….

..Per avviare le funzioni di firewalling non serve ricompilare il Kernel, dobbiamo solo aggiungere
le seguenti righe al file /etc/rc.conf perchè si inizializzi il firewall all avvio di sistema:

firewall_enable=”YES”
firewall_type=”/usr/local/etc/firewall.conf”
#

dopo di questo date un occhiata alle pagine di manuale di IPFW e configurate il vostro firewall
(in /usr/local/etc/firewall.conf
ecco un esempio base

appena avrò il tempo vi scriverò la seconda parte di questa miniguida parlandovi del filtraggio
avanzato con IPFW e del NAT su FreeBSD (/etc/natd.conf).