Esempi di iptables utili all’amministratore di sistema e di rete

Gen01
by chitblog on 1 gennaio 2014 at 01:25
Posted In: LINUX SERVER, OPENSUSE

Introduzione

Quando si parla di sicurezza in sistemi unix-like è buona cosa parlare di Iptables. In questa guida intendo fornire all’amministratore una lista di utili esempi in modo da configurare al meglio il proprio firewall. Quelli che seguono sono semplici esempi di iptables, chiaramente in una situazione più complessa e specifica sarà necessario creare delle regole più complesse. Questa non è una guida completa su Iptables, è solo una breve introduzione contenente degli esempi utili.

Iptables per limitare l’accesso ad un servizio tramite indirizzo ip

In questo esempio si fa in modo che solo un ip, o se si preferisce solo un range di ip, possa accedere al Server su una determinata porta.

Molto utile se sul Server gira SSHD per esempio. Si potrebbe limitare l’accesso a un indirizzo ip o range.

In questo esempio viene usata la porta 9999 e non quella standard, la 22. L’indirizzo della Workstation dell’amministratore è il seguente: 192.168.1.211.

iptables -A INPUT -p tcp -m state --state NEW --source 192.168.1.211 --dport 9999 -j ACCEPT
iptables -A INPUT -p tcp --dport 9999 -j DROP

Iptables per bloccare le richieste ICMP Ping

Per bloccare le richieste ICMP Ping eseguire il seguente comando:

iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -j DROP
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Iptables per prevenire Ip-Spoofing

Le seguenti Iptables potrebbero essere utili a prevenire l’ip-spoofing:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT

Iptables per scartare tutti i primi pacchetti che non siano SYN

Assicurarsi che i primi pacchetti inviati da un host siano SYN, se no verrano scartati. Per farlo eseguire il seguente comando.

iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

Iptables per prevenire attacchi Denial of service (DOS)

Chiarmente non c’è un modo per proteggersi al 100% da attacchi di tipo Denial of Service. Le seguenti iptables potreberò essere utili per proteggersi da alcuni tipi di attacchi Denial of Service:

iptables -A INPUT -p tcp --dport 80 -m limit --limit 25/minute --limit-burst 100 -j ACCEPT

Come aggiungere iptables in modo permanente

Metodo Normale – iptables_save e iptable_restore

Per aggiungere le iptables in modo permanete anche dopo un rinvio del sistema si potrebbero eseguire i comandi: iptables_save e iptable_restore. Eseguendo il comando iptables_save viene creato un file contenente le impostazioni in uso, il comando ibtable_restore viene poi aggiunto tra i comandi da eseguire all’avvio.

Ecco il comando:

iptables-save > /etc/iptables.conf

Una volta creato il file con le configurazioni fare in modo di eseguire il comando iptables_restore durante l’avvio. Per ottenere questo risultato editare il file in /etc/rc.local o /etc/init.d/boot.local (SUSE), e aggiungere il seguente comando:

iptables-restore < /etc/iptables.conf

Metodo SUSE - Usare SuSEfirewall2 FW_CUSTOMRULES

Per aggiungere iptables in SUSE con il SUSEFirewall2 attivo il modo migliore è quello di aggiungere un riferimento a uno script contenente delle iptables nel file di configurazione del firewall /etc/sysconfig/SuSEfirewall2.

Editare il file e scommentare la seguente riga cancellando il cancelletto:

FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"

Una volta fatto andare ad editare il file in questione - /etc/sysconfig/scripts/SuSEfirewall2-custom - e nella sezione fw_custom_after_chain_creation() tra le parentesi graffe, aggiungere delle Iptables da eseguire all'avvio. Vedi immagine sottostante.

suse-firewall-custom-configuration-iptables

Metodo SUSE 2 - disattivare il SuSEFirewall2 e usare solo iptables

Con SUSE si potrebbero aggiungere delle regole a quelle già create durante l'installazione o configurazione tramite Yast e poi, con il comando iptables_save, salvare le informazioni in un file.

SuseFirewall non fa altro che generare regole iptables in base alle impostazioni create tramite yast durante l'installazione o una successiva configurazione.

Usando questo metodo si decide di disattivare il SuseFirewall2 ed eseguire automaticamente lo script con le iptables ad ogni avvio del sistema - come nel metodo normale. In questo modo inoltre si possono tenere le configurazioni effettuate in precedenza.

Per aggiungere le iptables desiderate eseguire il comando iptables da una root shell.

Controllare le iptables attive con il comando iptables -L

Per controllare se le regole iptables siano attive nella zona giusta sulla corretta interfaccia, eseguire il comando iptables -L Eccone un esempio:

# iptables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1304 81826 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
52992 8208K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED 
 6116  555K input_ext  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           
    0     0 input_ext  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-IN-ILL-TARGET ' 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       icmp --  eth0   *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWD-ILL-ROUTING ' 

Chain OUTPUT (policy ACCEPT 47000 packets, 81M bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1304 81826 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           

Chain forward_ext (0 references)
 pkts bytes target     prot opt in     out     source               destination         

Chain input_ext (2 references)
 pkts bytes target     prot opt in     out     source               destination         
 3816  427K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast 
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 4 
    0     0 DROP       icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
    5   300 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:9999 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
    5   300 ACCEPT     tcp  --  *      *       192.168.1.211        0.0.0.0/0           state NEW tcp dpt:9999 
    2    92 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:9999 
 1218 70284 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:80 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
 1826  105K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
  218 13040 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp dpt:443 flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-ACC-TCP ' 
  273 15440 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:80 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:443 
  188  6768 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 PKTTYPE = multicast LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
  188  6768 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = multicast 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast 
    0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 tcp flags:0x17/0x02 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 LOG        icmp --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    0     0 LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 3/min burst 5 state NEW LOG flags 6 level 4 prefix `SFW2-INext-DROP-DEFLT ' 
    6   240 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain reject_func (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with tcp-reset 
    0     0 REJECT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-proto-unreachable 
#

Salvare la configurazione del firewall iptables in un file

Per salvare la cofigurazione del firewall e fare in modo che venga riusata ad ogni avvio del sistema, usare il comando iptables_save in combinazione con iptables_restore come visto in precedenza. 

iptables-save > /etc/iptables.conf

Aggiungere il comando iptables_restore nel file /etc/init.d/boot.local

Inserire il seguente comando nel file /etc/init.d/boot.local di modo da configurare il firewall durante lo start del sistema automaticamente:

iptables-restore < /etc/iptables.conf

Dasabilitare SuseFirewall2

Se si decide di non usarlo si elimina direttamente il pacchetto. In caso che lo si volesse solo provissoriamente disattivare usare i seguenti comandi:

# /sbin/SuSEfirewall2 off
SuSEfirewall2: batch committing...
SuSEfirewall2: Firewall rules unloaded.
# /etc/init.d/SuSEfirewall2_setup stop
Shutting down the Firewall                                                                                                                                                                                                                                          done
#
└ Tags: , , , , , , , , , , , , , , , , ,
 Comment 

Testare la sicurezza del proprio Web Server con Acunetix.

Dic08
by chitblog on 8 dicembre 2013 at 19:00
Posted In: WORDPRESS

Guida in italiano sul come testare la sicurezza del proprio server e delle proprie applicazioni con Acunetix Web Vulnerability Scanner.

Acunetix è un tool per Win usato per testare la sicurezza. Con questo programma è possibile testare le varie vulnerabilità con un semplice click tutto in uno.

Il programma proverà a simulare attacchi come per es. SQL Injection e di raccogliere informazioni sulle possibili vulnerabilità.

Per prima cosa configurare Acunetix per effettuare l’analisi tramite un Proxy Server. Consiglio di usare sempre dei proxy quando si usano questi “tools”, anche se si sta testando il proprio Server o se non si hanno cattive intenzioni. Per le impostazioni proxy di Acunetix andare in configuration, scann settings e in fine lan settings. Apparirà la finestra in cui inserire il proprio Proxy.

Acunetix Web Vulnerability Scanner

Una volta fatto avviare lo scanner premendo su New scann. Apparirà una finestra in cui inserire l’host da analizzare. Inserire l’host e premere su next.

Acunetix Web Vulnerability Scanner

Poi appare la finestra options in cui si possono scegliere alcune opzioni, in questo esempio si lascia Default. Poi premere su Next.

Acunetix Web Vulnerability Scanner

Dopo la parte Options appare la finestra di configurazione nominata Target in cui scegliere le varie tecnologie da testare, in questo esempio si sceglie PHP, mod_ssl e OpenSSL. Se non si conosce niente sul Server selezionarle tutte.

Acunetix Web Vulnerability Scanner

Una volta scelto premere su next. La prossima schermata, Login, serve nel caso si volessero testare zone protette da password durante lo “scann”. In questo esempio non vi sono cartelle protette da analizzare e quindi lasciare com’è ( no login sequence ) e premere su avanti.

Acunetix Web Vulnerability Scanner

Nella prossima e ultima finestra, FINISH, viene chiesto se si vuole fare uso di AcuSensor e se si desidera includere pagine simili. Lasciare tutto com’è e premere su finish.

Acunetix Web Vulnerability Scanner

Una volta premuto su finish il programma inizierà a scannare il Web Server in cerca di vulnerabilità. La scansione potrebbe durare diversi minuti.

Finito il processo di scansione i risultati riguardo ai diversi rischi per la sicurezza rilevati, vengono mostrati dal programma.

Acunetix Web Vulnerability Scanner

Come si può vedere dal risultato, il tool ha rivelato 6 “allerts” di cui 3 di livello medio. In questo esempio non vi sono rischi gravi per la sicurezza, come si può vedere in alto a destra il livello di “allerta” è “LEVEL 2”. Vi sono tre livelli, low, medium e high rispettivamente 1, 2 e 3.

L’alert di importanza media, HTML form without CSRF protection, si riferisce al fatto che i form ( formulari in cui inserire informazioni ) potrebbero essere vulnerabili ad attacchi di tipo “cross-site request forgery“.

Per rimediare alla falla nella sicurezza scoperta, installare un qualche plugin – nel mio caso si tratta di WordPress – come per es Anti CSRF o apportare le modifiche manualmente.

Uno degli “alerts” di minore importanza è “Trace method enabled“. Per default Apache2 supporta il metodo HTTP TRACE, che potrebbe esporre il proprio server ad alcuni tipi di attacchi, tra cui i “Cross-Site Scripting attacks“.

Ecco un ottima descrizione tratta da “Hacking Web – Sicurezza nel groviglio della Rete“: “TRACE è una sorta di richiesta ping che restituisce informazioni su tutti i proxy attraversati nell’elaborazione di una richiesta. Riporta anche l’eco della richiesta originale. I browser non fanno richieste TRACE. Tali richieste vengono utilizzate molto di rado per scopi legittimi, il primo dei quali è la verifica della sicurezza: possono rivelare interessanti dettagli sull’architettura interna dei server HTTP di una rete remota. Proprio per questa ragione viene quasi sempre disabilitato dagli amministratori dei server.”

Testare metodo HTTP TRACE con curl

Per testare se il metodo HTTP TRACE sia attivo con Linux si potrebbe eseguire il seguente comando:

:~> curl -i -X TRACE https://christeninformatica.ch
HTTP/1.1 200 OK
Date: Thu, 05 Dec 2013 23:44:58 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http
TRACE / HTTP/1.1
User-Agent: curl/7.32.0
Host: christeninformatica.ch
Accept: */*
:~>

Come si può notare osservando l’output del comando appena eseguito, il Server supporta il metodo “HTTP TRACE“.

Ora vediamo come disabilitarlo. Per disabilitare il supporto per TRACE in Apache2 editare il file di configurazione del Web Server, in SUSE, /etc/apache2/httpd.conf. Se non si ha accesso al file di configurazione del Server, usare .htaccess.
Alla fine del file aggiungere la seguente riga:

TraceEnable off

Una volta apportate le modifiche rinviare il server:

rcapache2 restart

A questo punto per controllare se il server è stato configurato correttamente eseguire nuovamente il comando di prima.

:~>curl -i -X TRACE https://christeninformatica.ch
HTTP/1.1 405 Method Not Allowed
Date: Thu, 05 Dec 2013 23:52:19 GMT
Server: Apache
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Method not allowed!</title>
<link rev="made" href="mailto:%5bno%20address%20given%5d" />
<style type="text/css"><!--/*--><![CDATA[/*><!--*/ 
    body { color: #000000; background-color: #FFFFFF; }
    a:link { color: #0000CC; }
    p, address {margin-left: 3em;}
    span {font-size: smaller;}
/*]]>*/--></style>
</head>
<body>
<h1>Method not allowed!</h1>
<p>
    The TRACE
    method is not allowed for the requested URL.
</p>
<p>
If you think this is a server error, please contact the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>.
</p>
<h2>Error 405</h2>
<address>
  <a href="/">christeninformatica.ch</a><br />
  <span>Fri Dec  6 00:52:19 2013<br />
  Apache</span>
</address>
</body>
</html>

Come si può notare dall’output del comando il metodo non viene più supportato dal Server ( 405 Method Not Allowed ).

Testare metodo HTTP TRACE con telnet

Se si usa Windows si potrebbe usare telnet per verificare se il metodo HTTP TRACE venga supportato oppure no.
Con il seguente comando aprire una connessione sulla porta 80 con telnet e una volta connessi digitare: TRACE / HTTP1.1

C:\Users\chit>telnet christeninformatica.ch 80
Digitare "TRACE / HTTP1.1" e poi premere due volte su enter per confermare
HTTP/1.1 200 OK
Date: Sat, 07 Dec 2013 00:17:41 GMT
Server: Apache
Connection: close
Content-Type: message/http
TRACE / HTTP1.1
Verbindung zu Host verloren.
C:\Users\chit>

Ed ecco la risposta nel caso il metodo HTTP TRACE non venga supportato:

C:\Users\chit>telnet christeninformatica.ch 80
TRACE / HTTP1.1
HTTP/1.1 405 Method Not Allowed
Date: Sat, 07 Dec 2013 00:01:38 GMT
Server: Apache
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Expires: Sat, 07 Dec 2013 00:01:38 GMT
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Method not allowed!</title>
<link rev="made" href="mailto:%5bno%20address%20given%5d" />
<style type="text/css"><!--/*--><![CDATA[/*><!--*/
body { color: #000000; background-color: #FFFFFF;}
a:link { color: #0000CC; }
p, address {margin-left: 3em;}
span {font-size: smaller;/*]]>*/--></style>
</head>
<body>
<h1>Method not allowed!</h1>
<p>
The TRACE method is not allowed for the requested URL.
</p>
<p>
If you think this is a server error, please contact the <a href="mailto:%5bno%20address%20given%5d">webmaster</a>.
</p>
<h2>Error 405</h2>
<address>
<a href="/">christeninformatica.ch</a><br />
<span>Sat Dec  7 01:01:38 2013<br />
Apache</span>
</address>
</body>
</html>

Alcuni esempi

Quelli che seguono sono esempi di possibili vulnerabilità trovate “scannando” altri hosts.

Blind SQL Injection

Acunetix Web Vulnerability Scanner
In questo caso lo scanner ha rilevato una vulnerabilità ad attacchi tramite SQL INJECTION. Per risolvere il problema si potrebbero usere delle regole rewrite o impedire l’aggiungere di segni particolari nei formulari controllando meglio l’input da inserire (sanitize the data) che è la soluzione migliore.

Ecco un esempio con delle regole rewrite che prevengono diversi attacchi per WordPress:

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_METHOD} ^(HEAD|TRACE|DELETE|TRACK) [NC]
RewriteCond %{QUERY_STRING} \.\.\/ [NC,OR]
RewriteCond %{QUERY_STRING} ^.*\.(bash|git|hg|log|svn|swp|cvs) [NC,OR]
RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} ftp\: [NC,OR]
RewriteCond %{QUERY_STRING} http\: [NC,OR]
RewriteCond %{QUERY_STRING} https\: [NC,OR]
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [NC,OR]
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(\[|\]|\(|\)|<|>|ê|"|;|\?|\*|=$).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*("|'|<|>|\|{||).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%24&x).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(%0|%A|%B|%C|%D|%E|%F|127\.0).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(globals|encode|localhost|loopback).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(request|select|concat|insert|union|declare).* [NC]
RewriteCond %{QUERY_STRING} !^loggedout=true
RewriteCond %{QUERY_STRING} !^action=rp
RewriteCond %{HTTP_COOKIE} !^.*wordpress_logged_in_.*$
RewriteCond %{HTTP_REFERER} !^http://maps\.googleapis\.com(.*)$
RewriteRule ^(.*)$ - [F,L]

PHPSESSID secure and httponly

Acunetix Web Vulnerability Scanner
In questo caso acunetix ha rilevato possibili rischi dovuti al fatto che la “PHPSESSID non è secure”.

Aggiungere la seguente riga nel file di configurazione di Apache (httpd.conf):

Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Colmare se possibile tutte le lacune della sicurezza trovate. Chiaramente in altre situazioni si troverebbero altri problemi da risolvere, quindi consiglio di fare ricerche sulle vulnerabilità trovate come anche le possibili soluzioni e di apportare in fine le modifiche necessarie.

Una volta finito fare un’altra analisi per assicurarsi che tutte le modifiche apportate abbiano avuto l’effetto desiderato. Non sono andato di proposito troppo nel dettaglio per quanto riguarda il descrivere le varie lacune alla sicurezza e relative soluzioni al problema, per non deviare troppo dal tema principale di questo tutorial e per il fatto che comunque, ognuno avrà risultati diversi.

└ Tags: , , , , , , , , , , , , , ,
 Comment 

Rendere più veloce e stabile (tuning) openSUSE Linux

Ott13
by chitblog on 13 ottobre 2013 at 05:01
Posted In: LINUX SERVER, OPENSUSE

Rimuovere i servizi inutili in Yast

Rimuovere tutti i servizi inutili per aumentare le prestazioni del sistema. Con l’installazione standard vengono installati molti pacchetti e molti demoni sono attivi per default, cosa che naturalmente rende il sistema meno stabile e veloce.

Per vedere quali demoni sono attivi eseguire il seguente comando:

# netstat -lp

Tipici demoni attivi per default sono per es: avahi-daemon, dchcpd, cups e altri.

L’avahi-demon è una applicazione che permette di cercare le risorse (cartelle condivise e stampanti condivise) disponibili nella rete, un po’ come il comando net view in Windows. Lo rimuovo visto che non ne ho bisogno.

Anche del dhcpd non ho bisogno che è il servizio che offre dhcp.

Cups serve per condividere e configurare stampanti, posso rimuovere anche questo visto che non ho una stampante in uso su questo computer.

E non ho neanche bisogno di cron, che serve per svolgere azioni pianificate in modo automatico.

In poche parole li rimuovo tutti eccetto quelli indispensabili per il corretto funzionamento del sistema e delle applicazioni in uso.

Per rimuovere i servizi inutili vi sono diverse possibilità, una di queste è usare Yast. Avviare Yast e spostarsi in System/runlevel:

SUSE Yast runlevel

Apparirà una lista – vedi immagine sopra – con i servizi e le relative informazioni a riguardo, in particolar modo lo stato (se sono attivi o no) e una descrizione. Per disattivare un servizio selezionarlo e cliccare su disable o disattiva.

Rimuovere le Shared Libraries inutili

Al giorno d’oggi molto codice necessario al corretto funzionamento delle varie applicazioni viene messo in file separati, le Shared Libraries. Per potere usare questi pezzi di codice viene usato il dynamic link loader (ld.so). Per ulteriori informazioni eseguire man ld.so.

Ecco la descrizione ottenuta in inglese: “The programs ld.so and ld-linux.so* find and load the shared libraries needed by a program, prepare the program to run, and then run it.”
Traduzione:“Il programma ld.so cerca e poi carica – nella memoria – le Shared Libraries necessare per il corretto funzionamento di un programma. Prepara il programma per l’esecuzione e lo esegue.”

Questo programma usa il file /etc/ld.so.cache per ottenere informazioni sulle varie librerie (Una lista delle Shared Libraries trovata nelle varie cartelle… ) e ovviamente per ottenere delle buone prestazioni, sarebbe buona cosa fare in modo di tenere il file il più piccolo possibile. Per ottenere questo risultato cancellare tutte le “Shared Libraries” di cui non si ha bisogno. Per cercare le librerie installate cercare “lib” in “Yast/Software Management” e una lista di file lib apparirà. Togliere quello di cui non si ha bisogno.

Lib files

Un altro modo per vedere quali libs sono installate è con il seguente comando:

# rpm -qa | grep "lib"

Stare molto attenti alle dipendenze ed eliminate le Shared Libraries solo se ne siete sicuri. Fare al limite un immagine del sistema o un backup prima di proseguire.

Un utile programma per vedere di quali libs abbia bisogno un programma è ldd.

Eccone un esempio:

#ldd /bin/ls
        linux-vdso.so.1 (0x00007fffce7ff000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fbc913e1000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007fbc911dc000)
        libacl.so.1 => /lib64/libacl.so.1 (0x00007fbc90fd3000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fbc90c25000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fbc90a21000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fbc91601000)
        libattr.so.1 => /lib64/libattr.so.1 (0x00007fbc9081c000)

Cercare di eliminarne il più possibile ma fare attenzione alle dipendenze e cioè da che programmi vengono usate le libs, se non si ha bisogno di tali programmi, rimuovere tranquillamente. Rimuovere direttamente anche il pacchetto del programma di cui non si ha bisogno.

Se si usa Suse a 64 bit, cancellare tutte le Shared Libraries 32 ma fare attenzione, perché potrebbero venire richieste da alcune applicazioni office. Non nel mio caso. Per eliminare le “libs” 32 bit cercare in Yast/Software Management “32” ed eliminarle tutto quello che si può.

Disablilitare la partizione Swap

Se si ha molta RAM potrebbe essere una buona pratica quella di disabilitare la partizione Swap. A questo scopo usiamo il comando swapoff:

# /sbin/swapoff -a

Per disabilitare permanentemente la partizione swap cancellare la riga relativa a swap nel file /etc/fstab:

#vi /etc/fstab
/dev/disk/by-id/ata-ST2000DM001-9YN164_Z1E0E9YF-part6 swap                 swap       defaults
...

Su questo punto vi sono molte contraddizioni in rete, guardate un po’ in giro e vedete se vi conviene. Alcuni affermano che non è necessario e che può portare ad effetti collaterali. Vi sono sicuro pro e contro. Vi invito dunque come detto a fare ricerche e a leggere il seguente documento in inglese:

Should I completely turn off swap for linux webserver

Una soluzione più elegante e in alcuni casi migliore sarebbe editare il file /etc/sysctl.conf e aggiungere le seguenti righe:

vm.swappiness = 0
vm.dirty_background_ratio = 50
vm.dirty_ratio = 80

Con questi parametri si fa in modo che la partizione swap viene attivata solo nel caso che la Memoria (RAM) si esaurisca completamente. Vm.swappiness viene usato per definire l'”aggressività” in cui viene usata la memoria swap, in caso di 0, solo se non c’è più memoria. Gli altri due parametri fanno in modo di aspettare più a lungo prima di iniziare a scrivere sul disco.

Disattivare Desktop Search

Desktop Serch è l’equivalente del sevizio index in windows, se non si usa spesso cercare tra i dati e non è importante che se nel caso si dovesse cercare, fosse un po’ più lento, disattivarlo.
Per disattivare questa funzionalità muovere il cursore del mouse sull’icona di SUSE, in basso a sinistra, e poi nel campo Search inserire Desktop Search. Una volta apparsa l’icona del programma, selezionarlo, dovrebbe aprirsi una finestra come nell’immagine sottostante.

SUSE: Desktop search service

Togliere il visto da “Desktop search services are active” e abbiamo finito. Se si preferisce solo limitare la memoria andare sotto Advanced Settings.

Disattivare Klipper di SUSE

Altra applicazione che usa risorse inutilmente e che si potrebbe disabilitare è Klipper. Per farlo cliccare in basso a destra sul simbolo della forbice, apparirà una lista in cui scegliere quit. Il programma chiederà allora se si desidera che Klipper venga eseguito automaticamente quando si accede al sistema. Vedi immagine sottostante:

klipper SUSE Linux

Mettere il visto in “do not ask again” e cliccare su “do not start”.

Migliorare le prestazioni della rete

Ecco alcuni punti per migliorare la performance della rete. Come prima cosa rimuovere il protocollo IPv6. Suse supporta il protocollo IPv6 ma se non si usa è buona cosa rimuoverlo. Rimuovendo il protocollo IPv6 si fa in modo che alcune attività della rete vengono eseguite più velocemente.

Per rimuovere il supporto per il protocollo IPv6 eseguire il seguente comando: 

# export KDE_NO_IPV6=1

Un altro modo sarebbe impedire al modulo di venire caricato nel Kernel. Per farlo aggiungere la seguente riga nel file /etc/modprobe.d/blacklist: “blacklist IPv6”.

Ancora meglio sarebbe chiaramente ricompilare il Kernel e rimuoverlo del tutto, per farlo vedere l’ultimo punto di questa guida.

Se si usa Firefox rimuovere il supporto per IPv6 anche li, per ottenere questo risultato inserire il seguente comando nel campo in cui si inserisce la URL: about:config

Poi nel campo Search digitare IPv6, premere con il tasto destro del mouse su network.dns.disableIPv6 e scegliere imposta. Il valore ora è true.

Remove IPv6 from Firefox

Una altra cosa che si potrebbe fare per velocizzare un po’ la rete è assegnare l’indirizzo IP manualmente.

In una piccola rete si potrebbe anche rimuovere arp editando il file /etc/dhcpd.conf e aggiungendo “noarp“. Una volta fatto rinviare il sistema o il demone per far si che i cambiamenti abbiano effetto.

Compilare il Kernel (SUSE Linux)

Un punto importantissimo è chiaramente compilare il Kernel in modo da ottenere le maggiori prestazioni possibile. In poche parole dobbiamo togliere anche qui tutto quello che non ci serve.

Per questo punto vi invito a leggere la guida sulla compilazione del Kernel di Linux SUSE: Guida sul come compilare il Kernel in Linux SUSE

└ Tags: , , , , , , , , , , , , ,
 Comment 

Linux Secure Shell Server (SSHD) – Sicurezza

Lug16
by chitblog on 16 luglio 2013 at 01:35
Posted In: LINUX SERVER

Guida di base alla sicurezza di SSHD. In questa guida illustrerò alcuni punti importanti riguardanti la sicurezza di un server SSH. SSHD è un servizio che offre la possibilità di connettersi ad una Shell da remoto. La connessione avviene in modo criptato. Ecco alcuni punti per migliorare la sicurezza di SSHD.

1. Limitare l’accesso tramite indirizzo ip

Per limitare l’accesso tramite indirizzo ip editare il file hosts.allow e host.deny. Nel file allow andiamo ad inserire le istruzioni sul chi può accedere e nel file con l’estensione .deny informazioni sugli ip a cui negare l’accesso. Nel nostro caso a tutti. Per farlo inserire in /etc/hosts.deny la seguente riga:

sshd: ALL

Con questo rifiutiamo l’accesso a tutti a parte chiaramente gli hosts inseriti (indirizzi ip, o range di ip) nel file hosts.allow, che andiamo ad editare. In questo modo l’accesso sarà permesso solo da uno specifico indirizzo Ip. Nel file /etc/hosts.allow inserire la seguente riga:

sshd: 192.168.200.10

2. Limitare l’accesso ad alcuni utenti

Per limitare l’accesso solo ad alcuni utenti editare il file /etc/ssh/sshd_config ed aggiungere la seguente riga:

AllowUsers chituser

3. Disabilitare il login da Root

Per disabilitare il login da Root editare il file /etc/ssh/sshd_config ed aggiungere la seguente riga:

PermitRootLogin no

Rendendo impossibile l’accesso diretto tramite Root si evita di esporre l’account dell’amministratore ad eventuali attacchi ed exploit. Poi, oltre a questo, un eventuale attacker dovrebbe essere a conoscenza delle informazioni di accesso (nome utente e password) riguardanti sia l’utente usato per connettersi al Server che Root. Quindi una doppia sicurezza.

4. Cambiare la Porta

Il motivo per il quale viene consigliato di non usare la porta (22) standard è il seguente: Un attaccante potrebbe scannare l’ip del Server con un port-scanner e capire che sul Server in questione sia attivo SSHD e decidere di usarlo come punto di attacco.

Oppure un malintenzionato potrebbe scannare la rete alla ricerca di hosts con la porta 22 aperta con un ip-scanner. Quindi come in tutto meno informazioni si danno all’attaccante su che Servizi sono attivi e sul che porte sono aperte e meglio è.

Vi sono due tipi di scanner, gli IP-scanner e i Port-scanner che come si capisce già dalla parola servono rispettivamente per scannare un ip alla ricerca di porte aperte o per scannare un range di ip (una rete) alla ricerca di specifiche porte aperte. L’IP-scanner scanna la rete alla ricerca di hosts con una specifica porta aperta mentre il port-scanner scanna und indirizzo ip alla ricerca di porte aperte. Network-scanners come nmap per Linux incorporano tutte e due le funzionalità.

Per cambiare la porta dobbiamo per prima cosa sceglierne una, si può usare una qualsiasi porta da 1024 a 65535. Uno scanner non scannerà per default queste porte (non standard).

Per cambiare la porta editare il file di configurazione sshd_config e aggiungere le seguenti righe:

Port 6500
ListenAddress 10.10.10.10

5. Usare password complicate e cambiarle spesso

Cambiare spesso le password e usarne di complicate è molto importante. L’ideale sarebbe cambiare la password ogni mese o due.

6. Attivare l’opzione StrictModes

Per usare l’opzione settare il valore su yes, editando il file /etc/sshd_config:

StrictModes yes

7. Usare UsePrivilegeSeparation

Per attivare l’opzione editare il file /etc/sshd_config e aggiungere quanto segue:

UsePrivilegeSeparation yes

8. Forzare l’uso del Protocollo 2

Per forzare l’uso del protocollo 2 Aggiungere la seguente riga nel file di configurazione:

Protocol 2

Se è già presente lasciare com’è. Questo farà in modo che ai client che hanno ancora in uso una versione vecchia di un ssh client, verrà negato l’accesso.

9. Disabilitare l’accesso senza password

Per impedire il login da remoto a utenti non protetti da password impostare la seguente opzione su no:

PermitEmptyPasswords no

10. Limitare l’accesso tramite ip usando iptables

In alternativa al metodo utilizzato prima o come doppia sicurezza (usare entrambi i metodi) oltre al fare uso del file hosts.deny e hosts.allow per limitare l’accesso solo ad alcuni hosts, vi è la possibilità di usare iptables per ottenere li stessi risultati.

Ecco il comando per permettere l’accesso al Secure Shell Server su una determinata porta ad un host specifico:

# iptables -A INPUT -p tcp -m state --state NEW --source 192.168.200.10 --dport 6500 -j ACCEPT

Questo invece è il comando per negare l’accesso a tutti gli altri:

# iptables -A INPUT -p tcp --dport 6500 -j DROP

11. Attualizzare OpenSSH e sistema operativo

Una altra cosa importante è chiaramente tenere aggiornato il sistema operativo come anche l’applicazione stessa, OpenSSH. Assicurarsi di avere in uso sempre la versione più attuale disponibile.

12. SSH Client

Ora per connettersi al Secure Shell Server appena configurato bisogna usare i parametri -l per specificare l’utente e -p per la porta. Ecco un esempio:

ssh -l chituser -p 6500 10.10.10.10
└ Tags: , , , , , , , , , , , , ,
 Comment 

Compilare il Kernel di Linux in openSUSE

Giu27
by chitblog on 27 giugno 2013 at 06:17
Posted In: LINUX SERVER, OPENSUSE

Benvenuti questa è una breve guida sul come compilare il Kernel di Linux in modo da potere usufruire delle piene potenzialità del sistema. Compilando il Kernel di linux si ottiene più sicurezza, stabilità e velocità.

Prima di tutto scaricare il Kernel da www.kernel.org. Il sistema usato in questa guida è SUSE Enterprise Server ma non fa molta differenza, la procedura, eccetto che per il comando make cloneconfig, è uguale in ogni sistema Linux o unix-like. Per la versione Desktop di openSUSE vale la stessa identica procedura.

Una volta scaricato l’archivio copiarlo nella cartella /usr/src/ o dove si preferisce.

Poi estrarre il contenuto dell’archivio compresso e spostarsi nella cartella appena creata.

# cp /media/usb/linux-3.9.7.tar.xz /usr/src/ 
# cd /usr/src 
# tar -xf *.7.tar.xz 
# cd *7

Ora, per essere sicuri di avere un Kernel funzionante è buona cosa usare la configurazione del Kernel attualmente in uso, creata durante l’installazione o durante una precedente compilazione del Kernel.

Se non vi è un file con le configurazioni precedenti il file verrà creato con il comando make menuconfig.

La configurazione in uso del Kernel si trova in OpenSUSE nel file /proc/config.gz ed è possibile crearne una copia eseguendo il comando: make cloneconfig:

# make cloneconfig

Suse include una funzionalità del kernel che permette di salvare la configurazione in uso in un file compresso, /proc/config.gz. Eseguendo il comando make cloneconfig viene creato un file di configurazione con i valori trovati in config.gz.

Se il comando cloneconfig da errori, come nel mio caso, si potrebbe eseguire il seguente comando: 

# cp /proc/config.gz config.gz 
# gzip -dv config.gz
config.gz:       74.6% -- replaced with config
# mv config .config

oppure questo: 

 # cp /boot/config-`uname -r` .config

Bene, ora che il file di configurazione dell’attuale Kernel (.config) è presente nella cartella, eseguire il comando make menuconfig. 

# make menuconfig

A questo punto appare la finestra del menu principale per la configurazione.

Configurazione del Kernel - Menu principale

Nel menu “general setup” impostare il nome per il nuovo Kernel. Io uso tunato e metto il visto in automatically append version information.

Ciò va fatto per evitare di sovrascrivere la configurazione attuale, perché nel caso la compilazione del Kernel non venga effettuata con successo, si sarebbe ancora in grado usare il vecchio Kernel e riprovare.

Se si lascia com’è si rischia di rendere il sistema inutilizzabile, quindi, importante, cambiare il nome.

Kernel general setup

Una volta fatto premere due volte su esc o exit per tornare al menu principale. Ora, sotto Processor types and features, scegliere il processore, chiaramente se si ha un intel cancellare tutto quello che è AMD e viceversa.

Per aver informazioni sul processore in uso eseguire il seguente comando:

# cat /proc/cpuinfo

Toglere tutto quello che non serve e soprattutto scegliere il tipo di processore (Processor family), se si lascia com’è non si usano a pieno le potenzialità, il kernel di defalut è fatto per soddisfare la maggior parte delle situazioni.

Per esempio, si ha bisogno di Dell Laptop support, se il si sta usando un Server, o del supporto per IBM se non si sta usando IBM?!? Certamente no. Usare linux senza compilare il Kernel sarebbe una cosa stupida da fare.

Kernel processsor type

Scegliere Processor Family -io scelgo core 2/ Newer Xeon- e poi tornare al menu principale. Una volta al menu principale passare a networking support.

Kernel Network device support

Anche qui possiamo togliere quasi tutto.

Come sempre se non si sa cos’è una cosa, si fa una ricerca. Toglere Amateur Radio support, CAN bus, irda (infrarossi), Bluetooth, wireless, WIMAX, RF switch, Plan 9, CAIF, Ceph, plan9 e tutto il resto. Anche nella cartella networking options si può togliere quasi tutto tranne TCP/IP Networking.

Tolgo per es il protocollo ipv6, qos, LAN Emulation, VLAN, apletalk, ipx, ppp, ip-multicasting, DECNET support… Tornare al menu principale con exit o premendo due volte su esc poi passare alla scheda Device Drivers e tolgiere anche li tutto quello che non serve.

Kernel device drivers

Tolgliere per esempio IEEE 1394, Parallel Support, multimedia support (è un Server), Ultrawideband service, Microsoft hyper-v, Virtualization driver e tutto quello che non serve. Consiglio di fare prima un giro tra i vari driver e togliere tutto quello che si conosce di cui non si ha bisogno e poi cercare il resto che non si conosce in internet.

Per avere informazioni sull’hardware installato con SUSE andare in Yast sotto Hardware e poi hardware information. Apparirà una finestra con tutte le informazioni relative all’hardwere in uso.

Suse hardware information

In Netowork device support cancellare ISDN, Wirelesslan, PPP, USB network adapters,SLIP, CSLIP… Cancellare veramente tutto e poi, sotto ethernet driver support, scegliere il driver per la propria scheda ethernet.

Per sapere il nome della propria scheda ethernet eseguire il seguente comando: 

 # lspci | grep -i Ethernet 
03:00.0 Ethernet controller Atheros Communications Inc. AR8152 v2.0 Fast Ethernet (rev c1)

Tornare al menu principale e passare alla sezione file sistem e tolgliere anche qui tutto quello che non serve. Consiglio di dare un occhiata alle opzioni Kernel hacking ma vi sarà una guida specifica per questa sezione. In scurity Options attivo Restrict unprivileged access to kernel syslog e tolgo Apparmor perché non lo uso. Infondo, all’ultimo punto, togliere anche Virtualisation se non si ha intenzione di usare questa tecnologia. Abbiamo finito.

Salvare la configurazione premendo su save e uscire dal programma, le impostazioni verrano salvate nel file .config.

Ora non resta che eseguire il comando per compilare il kernel, chiaramente bisogna avere gcc e i tool per lo sviluppo del Kernel installati.

Se si ricevono degli errori cercare gli errori in internet…

 # make && make modules && make modules_install && make install

In cui make crea l’immagine, make modules compila i moduli, make modules_install installa i moduli e make install sposta i file necessari in boot e crea la configurazione per grub – il boot manager – in modo automatico. Se il comando viene effettuato con successo alla fine non vi saranno errori ma dei messggi del genere:

sh /local/src/linux-3.9.6/arch/x86/boot/install.sh 3.9.6-tunato arch/x86/boot/bzImage \ System.map "/boot" Kernel image
/boot/vmlinuz-3.9.6-tunato Initrd image
/boot/initrd-3.9.6-tunato Root device
/dev/disk/by-id/md-uuid-07bfe96d:370b4411:1068b86d:0e002d62-part2 (/dev/md126p2) (mounted on / as ext3) Resume device
/dev/disk/by-id/md-uuid-07bfe96d:370b4411:1068b86d:0e002d62-part1 (/dev/md126p1) Kernel Modules: hwmon thermal_sys thermal processor fan libahc mbcache jbd ext3 usb-common usbcore ohci-hcd uhci-hcd ehci-hcd hid usbhid raid0 raid1 raid10 async_tx async_memcpy xor async_xor raid6_pq async_pq async_raid6_recov raid456 crc-t10dif sd_mod Features
acpi block usb md resume.userspace resume.kernel Bootsplash
SLES (1024x768) 93900 blocks >>> Network
auto >>> Calling mkinitrd -B -k /boot/vmlinuz-3.9.6-tunato -i /tmp/mkdumprd.vMeN3NU2jx -f 'kdump network' -s '' Regenerating kdump initrd ... Kernel image
/boot/vmlinuz-3.9.6-tunato Initrd image: /tmp/mkdumprd.vMeN3NU2jx Root device
/dev/disk/by-id/md-uuid-07bfe96d:370b4411:1068b86d:0e002d62-part2 (/dev/md126p2) (mounted on / as ext3) Resume device
/dev/disk/by-id/md-uuid-07bfe96d:370b4411:1068b86d:0e002d62-part1 (/dev/md126p1) Kernel Modules: hwmon thermal_sys thermal processor fan mbcache jbd ext3 usb-common usbcore ohci-hcd uhci-hcd ehci-hcd hid usbhid af_packet atl1e raid0 raid1 raid10 async_tx async_memcpy xor async_xor raid6_pq async_pq async_raid6_recov raid456 nls_utf8 crc-t10dif sd_mod Features: acpi block usb network md resume.userspace resume.kernel kdump 
111085 blocks

A questo punto bisogna controllare se il file /boot/grub/menu.lst o /boot/grub2/grub.cfg sia stato modificato correttamente e rinviare. Abbiamo finito. Se no cercare gli errori, correggerli e ricompilare il Kernel.

Se si ricompila il Kernel fare attenzione a copiare il file .config da un altra parte e poi eseguire i seguenti comandi

# cp .config $HOME/config 
# make clean 
# make mrproper 
# cp $HOME/config .config 
# make menuconfig

Aggiungere ciò che manca di modo da correggere l’errore e compilare nuovamente il Kernel.

└ Tags: , , , , , , , , , , , , , ,
2 Comments