Some right reserved
Scegli come ricevere gli ultimi articoli:
Il Portalinux è anche su facebook
Risultati del sondaggio
Ti piacerebbe avere una rubrica dedicata alle domande dei lettori?
- Si (93%, 25 Votes)
- No (7%, 2 Votes)
Total Voters: 27
Loading ...Basta MSN, usa Jabber!
Categorie
Meta
iptables Archive
Go Away Scriptkiddie!!
Posted on luglio 21, 2009 | 5 commentiPiccolo suggerimento per difendersi ulteriormente dalla marea di "disturbatori della quite pubblica" che ogni giorno tentano invano di sfondare le nostre difese.
Suggerimento valido anche per web server Apache.
Bloccare IP di determinati paesi via IPtables
Posted on febbraio 18, 2009 | Nessun commentoSiete stanchi dei continui attacchi al vostro server? Siete riusciti a capire che gli ip vengono generalmente sempre dallo stesso paese, o da determinati paesi?
Bene vediamo di porre fine a questa agonia....
E’ stata rilasciata lenny??
Server Proxy-Cache su debian etch con squid
Posted on dicembre 10, 2008 | 7 commentiNelle reti aziendali sono molto usati i cosiddetti proxy server, ed anche nella nostra piccola rete casalinga può essere utile installarne uno, perchè con le funzionalità che ci offre è possibile dare una spintarella alla navigazione quotidiana.
Con questo how to vedremo come installare squid, forse il più celebre tra i proxy server, con funzionalità di caching delle pagine web ed in modalità trasparente.
Capiamo ed usiamo Iptables – Parte 2°
Posted on novembre 13, 2008 | 3 commentiEccoci stasera con la seconda parte della nostra guida su IpTables. Oggi vediamo i parametri più comuni che si utilizzano per definire le regole e come/quali obiettivi si possono passare alle stesse.

Capiamo ed usiamo Iptables – Parte 1°
Posted on novembre 9, 2008 | 8 commentiCon oggi parte una delle mie solite guide per principianti del mondo GNU/Linux, questa volta vedremo cosa è e cosa possiamo fare con iptables. Non sono un guru di iptables, essendo sempre abituato a lavorare con appliance dedicati, però noto che nonostante le milioni di guide presenti su internet si presentano sempre utenti (come il nostro amico NeOs) che vogliono fare determintate cose con le loro macchine, ma non hanno la competenza necessaria per farlo, quindi ho deciso di dare il mio contributo condividendo quanto so con voi...

Come filtrare a livello 7 con iptables
Posted on agosto 19, 2008 | 2 commentiUno dei problemi maggiori che i sysadmin si trovano ad affrontare è quello di instaurare un ottimo filtraggio per la rete aziendale che hanno per le mani; il più grande nemico delle aziende si sa è il P2P, e ad oggi non basta chiudere le sole porte "standard", dobbiamo effettuare un filtraggio di livello più alto, a livello applicazione o tecnicamente parlando di livello 7, bloccando quindi l'intero protocollo ftp, edonkey, torrent, ecc...in base ai flag che vengono imposti sull'header dei pacchetti
Integrazione di un sistema pseudo-IPS su debian etch
Posted on maggio 31, 2008 | 2 commentiChiunque amministri un server, tra le priorità per la gestione dello stesso ha prima di tutte la sicurezza...Premesso che per la gestione di server importanti nel numero o nel tipo di servizio che devono svolgere, le tecniche di messa in sicurezza sono ben altre, questa che vi sto per proporre va bene per un server o meglio ancora vps, dalle piccole dimensioni, in quanto è un metodo sicuro ma soprattutto economico...
Quello che vedete in figura è un firewall della NetASQ, modello F500. E' tra gli IPS più utilizzati in ambito aziendale, ((basato su un sistema operativo freebsd :D)) riesce a fornire un alto grado di sicurezza, unendo una gestione relativamente semplice tramite una interfaccia grafica.IPS sta per Intrusion Prevention System, e descrive un sistema che, come l'apparato descritto, a fronte di una configurazione riesce ad identificare un tentativo d'attacco verso la rete da lui gestita, bloccandolo, e loggando gli eventi; in modo da fornire tutti i dati necessari per un debug del tentativo in questione, per darci la possibilità di reagire impedendo accessi non autorizzati.Quello che vi voglio proporre ovviamente non è comprare un apparato come questi, spendendo diverse migliaia di euro, ma l'integrazione di un pacchetto all'interno della vostra debian, in modo da avere un sistema Pseudo-IPS, ((Pseudo perchè con questo sistema potremo prevenire solo attacchi di tipo brute force, non attacchi DDoS et similia)) che possa identificare tentativi di login falliti a determinati servizi, ed eventualmente oltrepassata una certa soglia agire di conseguenza con iptables...Il software in questione è Fail2Ban reperibile nei repository:apt-get install fail2banDopo averlo installato diamo una rapida occhiata al file di configurazione, semplice ed intuitivo, per la messa in piedi del servizio...nano /etc/fail2ban/jail.confCome suggerito dal file stesso, non modifichiamo direttamente questo file ma ne creiamo uno nuovo settandolo per le nostre esigenze:nano /etc/fail2ban/jail.local
Fatto? Ora dobbiamo riavviare il servizio...[DEFAULT]# "ignoreip" can be an IP address, a CIDR mask or a DNS host ignoreip = 127.0.0.1 bantime = 600 maxretry = 3# "backend" specifies the backend used to get files modification. Available # options are "gamin", "polling" and "auto". # yoh: For some reason Debian shipped python-gamin didn't work as expected # This issue left ToDo, so polling is default backend for now backend = polling# # Destination email address used solely for the interpolations in # jail.{conf,local} configuration files. destemail = root@localhost# Default action to take: ban only action = iptables[name=%(__name__)s, port=%(port)s][ssh]enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 5[apache]enabled = true port = http filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 5[apache-noscript]enabled = false port = http filter = apache-noscript logpath = /var/log/apache*/*error.log maxretry = 5[vsftpd]enabled = false port = ftp filter = vsftpd logpath = /var/log/auth.log maxretry = 5[proftpd]enabled = true port = ftp filter = proftpd logpath = /var/log/auth.log failregex = proftpd: \(pam_unix\) authentication failure; .* rhost=<HOST> maxretry = 5[wuftpd]enabled = false port = ftp filter = wuftpd logpath = /var/log/auth.log maxretry = 5[postfix]enabled = false port = smtp filter = postfix logpath = /var/log/mail.log maxretry = 5[courierpop3]enabled = true port = pop3 filter = courierlogin failregex = courierpop3login: LOGIN FAILED.*ip=\[.*:<HOST>\] logpath = /var/log/mail.log maxretry = 5[courierimap]enabled = true port = imap2 filter = courierlogin failregex = imapd: LOGIN FAILED.*ip=\[.*:<HOST>\] logpath = /var/log/mail.log maxretry = 5[sasl]enabled = true port = smtp filter = sasl failregex = warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed logpath = /var/log/mail.log maxretry = 5
/etc/init.d/fail2ban restartThat's all folks :D Adesso se ci saranno tentativi di log in falliti e conseguenti ban vedremo crescere il file di log /var/log/fail2ban.log:2007-04-24 17:49:09,466 fail2ban.actions: WARNING [apache] Ban 1.2.3.4 2007-04-24 18:08:33,213 fail2ban.actions: WARNING [sasl] Ban 1.2.3.4 2007-04-24 18:26:37,769 fail2ban.actions: WARNING [courierlogin] Ban 1.2.3.4 2007-04-24 18:39:06,765 fail2ban.actions: WARNING [courierimap] Ban 1.2.3.4
Dato che questo software va ad interagire con iptables se rileviamo allarmi diamo un iptables -L per capire cosa viene modificato sul nostri firewallGestiamo il nostro firewall con fwbuilder
Posted on maggio 1, 2008 | 12 commentiIeri notte mentre cercavo una maniera un pò più semplice per gestire l'iptables del mio server mi sono imbattuto in questo software a dir poco strepitso per me...con questo software avremo a disposizione un interfaccia grafica per l'amministrazione di iptables, dalla creazione delle regole, alle policy di nat, al logging eccetera.Ma non è finita qui, la strepitosità del programma infatti sta nel suo aspetto e nel suo modo di utilizzo, che sono del tutto uguali alle CMA di casa Checkpoint.Per chi non lo sapesse checkpoint è una celebre casa produttrice di firewall basati su kernel linux ma con os proprietario, gestibili graficamente tramite una dashboard che più comunemente viene chiamata CMA, e permette una gestione del firewall orientata agli oggetti, quindi le regole si costruiscono effettuando un semplice drag and drop degli oggetti interessati negli appositi campi della regola.Le regole vengono dapprima configurare poi, una volta che sono a posto vengono installate sul firewall che in questo caso è il nostro pc/server, non vengono registrate on the fly quindi, riducendo il rischio di combinare str**** tagliandoci fuori dal server :D è possibile anche installare le policy programmando un reload del server dopo tot minuti, cosi in caso le regole sembrano a posto ma in realtà non lo sono, se ci tagliamo fuori basterà aspettare il tempo programmato e con il reload del server tornerà tutto come prima...comodo no?E' inoltre possibile utilizzare tale interfaccia per gestire oltre ad iptables, anche veri e propri firewall corporate come i Cisco PIX, ed altri sistemi.Ma non è tutto oro ciò che luccica, installandolo sul mio server infatti, sono stato costretto ad installare X11 -.-' altrimenti non avrei mai avuto le librerie necessarie per il disegno della gui, e successivamente mi è bastato esportarmi il display sul mio pc via ssh.Correzione: E' tutto oro ciò che luccica, basta inserire l'ip del firewall in fase di installazione policy :mrgreen:Ma sono sempre più convinto che la colpa è mia per non averlo sviscerato troppo perchè credo che il modo per gestire un firewall remoto ci sia (se si sono ispirati alla checkpoint non possono non averlo implementato).Personalmente consiglio a tutti il suo utilizzo, e chi smanetta con le cma checkpoint sicuramente sa perchè ;)Uncomplicated firewall (Ufw) how-to, sicurezza in hardy
Posted on marzo 10, 2008 | 7 commentiQuesta sera vi propongo un how-to sull'uso e la configurazione del tool di gestione della sicurezza che verrà implementato in hardy heron, ufw che sta per Uncomplicated FireWall...parto col dire che i comandi sono abbastanza semplici (se no perchè uncomplicated eheh)...
di default ovviamente è spento, quindi non avremo nessuna politca di filtraggio attiva sul nostro pc.Come prima cosa suggerisco di impostare la default rule su allow, di modo da poterlo attivare senza subire disconnessioni.morfeus@hardy:~$ ufw --help
Usage: ufw COMMANDCommands: enable Enables the firewall disable Disables the firewall default ARG set default policy to ALLOW or DENY logging ARG set logging to ON or OFF allow|deny RULE allow or deny RULE delete allow|deny RULE delete the allow/deny RULE status show firewall status version display version informationsudo ufw default ALLOWe quindi poi di abilitarlo:sudo ufw enablecol comando status vediamo, indovinate un pò, la stato del firewall; se attivo o no. Mentre con l'opzione logging accompagnata da on o off, abilitamo il logging degli eventi del firewall.Tips: se prima dell'opzione, dopo del comando sudo ufw per intenderci, scriviamo --dry-run, simuleremo l'implementazione del comando; ossia diremo al programma di non modificare nulla ma di farci solo vedere cosa cambierebbe se lo lanciassimo veramente.Ora viene il bello: l'implementazione delle regole. L'utente lo può fare in due modi seguendo sintassi differenti. Vediamo come funziona la sintassi base, quella più semplice:N.B. Io userò il comando allow ma a seconda di come deve essere impostato il firewall dovrete sostituire allow con deny
Come prima cosa possiamo specificare ad ufw di abilitare il traffico (entrata/uscita) solo per porta:sudo ufw allow 53abilitando in questo caso traffico per la porta 53, che nel caso dell'udp corrisponde in richieste DNS.Possiamo però, abilitare il traffico solo per tipo di protocollo:sudo ufw allow smtpOppure possiamo mischiare le due cose e permettere solo una determinata porta per un determinato protocollo (sempre in entrambi i sensi):sudo ufw allow 53/udpabilitando in questo caso, solo ed esclusivamente traffico per queries DNS.Adesso entriamo nella sintassi più complessa e efficace, basata sul celebre PF di OpenBSD:sudo ufw deny proto tcp to any port 80in questo caso, ad esempio, neghiamo il traffico in uscita da qualsiasi host e verso qualsiasi host per la porta 80, negando quindi la navigazione HTTP.sudo ufw deny proto tcp from 10.0.0.0/8 to 192.168.0.1 port 25oppure possiamo negare, come in questo esempio, il traffico TCP da un determinato host/rete, verso un altro host/rete, sulla porta 25, nella fattispecie neghiamo alla rete 10.0.0.0/8 (quindi 10.x.x.x il /8 ci indica che siamo in classe A), di fare traffico SMTP verso l'host 192.168.0.1, i client di questa rete quindi non potranno inviare mail verso quel server.sudo ufw deny proto tcp from 2001:db8::/32 to any port 25possiamo specificare (e quindi gestire) anche indirizzi di protocollo 6, con questa regola ad esempio neghiamo all'host 2001:db80:0000:0000/32 (gli 0 negli indirizzi ipv6 possono essere omessi per comodità) di effettuare traffico smtp verso qualsiasi host, quindi non potrà inviare mail sempre e comunque. Questo lo possiamo fare a patto che precedentemente abbiamo settato correttamente il file /etc/default/ufw per l'ipv6 firewalling.Quando una regola non serve più possiamo disabilitarla postponendo delete al comando ufw, e seguendo con la regola interessata:sudo ufw delete deny 80/tcpTali regole possono essere configurate anche a firewall spento, anzi devono essere impostate a firewall spento, a meno che non sia stata messa precedentemente la default in allow. Il firewall effettua il ripasso delle regole solo quando viene attivato (con enable si può anche reloadare se è già attivo), oppure quando viene cambiata la default policy. Quando invece aggiungiamo o togliamo una regola questa non verrà "indicizzata", dovremo quindi reloadare il firewall per renderla attiva.Prima di utilizzarlo dobbiamo sapere però una cosa importante, come tutti i firewall anche ufw legge le regole in maniera sequenziale ossia dalla prima inserita fino all'ultima, vien da se che tra due regole successive, vince la prima e non la più restrittiva, pertanto dobbiamo avere cura di inserire per prime le regole più restrittive e poi quelle più generali (un deny any any 80, prima di un permit 1.2.3.4 any 80, coprirà tale regola quindi alla fine nemmeno l'host 1.2.3.4 potrà fare traffico http).UFW è una interfaccia di front-end al comando iptables-restore, le regole vengono salvate nei file /etc/ufw/before.rules, /usr/share/ufw/after.rules, e /var/lib/ufw/user.rules. Le regole possono essere modificate dagli amministratori (aka sudo), nei file before.rules e after.rules, secondo la sintassi iptables.Si tenga a mente che vengono lette per prima le regole all'interno del file before.rules, successivamente quelle di user.rules, ed infine quelle dentro after.rules (ecco il perchè dei nomi).Per ora è tutto, spero questa guida vi sia piaciuta.















