Questo articolo rappresenta una guida per ripristinare il corretto funzionamento dell’interfaccia web remota.

Il problema era legato ad un errore riscontrato in tomcat che ne impediva il corretto funzionamento. Dopo un’analisi dei log ho tentato di avviare webAccess manualmente con il comando:

/usr/lib/vmware/webAccess/java/jre1.5.0_15/bin/webAccess -client -Xmx64m -XX:MinHeapFreeRatio=30 -XX:MaxHeapFreeRatio=30 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/temp org.apache.catalina.startup.Bootstrap start

L’errore riscontrato era il seguente:

GRAVE: StandardServer.await: create[8005]: java.net.SocketException: Invalid argument

La conferma veniva data dalla mancanza di socket in ascolto sulla porta 8308:

server:~# netstat -an|grep 8308
server:~#

Ciò è dovuto al fatto che il sistema, di default, impedisce il bind di socket IPV4 su indirizzi IPV6. La console remota di vmware, infatti, si pone in ascolto su tutte le interfacce localhost rilevate. La soluzione è modificare il file

/etc/sysctl.d/bindv6only.conf

sostituendo la voce da

net.ipv6.bindv6only = 1

a

net.ipv6.bindv6only = 0

Fatto questo passo riavviare il server.

I comandi sottostanti servono a verificarne il corretto funzionamento:

server:~# netstat -an|grep 8308
tcp 0 0 127.0.0.1:52251 127.0.0.1:8308 TIME_WAIT
tcp 0 0 127.0.0.1:60849 127.0.0.1:8308 TIME_WAIT
tcp 0 0 127.0.0.1:60845 127.0.0.1:8308 TIME_WAIT
tcp 0 0 127.0.0.1:60842 127.0.0.1:8308 ESTABLISHED
tcp 0 0 127.0.0.1:60846 127.0.0.1:8308 TIME_WAIT
tcp6 0 0 :::8308 :::* LISTEN
tcp6 0 0 127.0.0.1:8308 127.0.0.1:52247 TIME_WAIT
tcp6 0 0 127.0.0.1:8308 127.0.0.1:60842 ESTABLISHED

server:~# nmap -sT -p 8308 127.0.0.1 -sV

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-13 10:03 CET
Interesting ports on localhost (127.0.0.1):
PORT STATE SERVICE VERSION
8308/tcp open http Apache Tomcat/Coyote JSP engine 1.1

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.25 seconds

alias_maps = hash:/etc/aliases

e per rendere questo file una mappa utilizzabile da Postfix lanciamo il comando

# postalias /etc/aliases

Multidominio, Virtual Domain e Sender Canonical
Nel caso il vostro Server debba ricevre la posta per più domini non dobbiamo fare altro che modificare la tag mydestination come segue

mydestination = localhost, /etc/postfix/local-domain

creare il file /etc/postfix/local-domain e inserire li i domini da considerare locali uno per riga senza virgole.

Fatto questo conviene preparare un file per la gestione dei domini virtuali in modo tale da associare il giusto dominio al dato utente creiamo allora il file /etc/postfix/virtual La sintassi da usare è la seguente:

info@dominio1.it marco -> le mail in arrivo per tale indirizzo sono redirezionate a marco
webmaster@dominio2.it andrea@dominio4.it -> le mail verranno inviate a andrea@dominio4.it
@dominio3.com alessandro -> tutte le mail inviate a qualsiasi indirizzo @dominio3.com sono inviate all’utente alessandro

aggiungiamo in /etc/postfix/main.cf

virtual_maps = hash:/etc/postfix/virtual

e prepariamo la map con il comando

# postmap /etc/postfix/virtual

Può essere utile sempre per la gestione di più domini usare un file che associ ad un nome utente un indirizzo mittente particolare. Creiamo perciò un file /etc/postfix/sender_canonical dove con la precedente sintassi associamo al nome utente l’indirizzo mittente da mostrare nelle mail inviate. Aggiungiamo in /etc/main.cf la seguente riga:

sender_canonical_maps = hash:/etc/postfix/sender_canonical

ed infine prepariamo la map con

# postmap /etc/postfix/sender_canonical

Antivirus – Amavis e ClamaV
Passiamo ora alla configurazione dell’antivirus da installare sul vostro MTA. Procediamo all’installazione:

# apt-get install amavisd-new clamav clamav-daemon

Dopo l’installazione dobbiamo dire a Postfix di far processare le mail dal vostro antivirus. Aggiungiamo a /etc/postfix/main.cf quanto segue:

content_filter = amavis:[127.0.0.1]:10024

mentre nel file /etc/postfix/master.cf:

amavis unix – - n – 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes

127.0.0.1:10025 inet n – n – - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_client_restrictions=
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o strict_rfc821_envelopes=yes

Di per se non si richiedono altre modifiche per il corretto funzionamento, comunque può essere utile dare un occhiata al file /etc/amavis/amavisd.conf per eventuali modifiche. Il Demone clamav-daemon (freshclam) tiene aggiornato il vostro antivirus aggiornandosi 12 volte al giorno, per eventuali modifiche /etc/clamav/fresclam.conf e /etc/clamv/clamavd.conf

Antispam – Spamassassin
Può essere utile installare un antispam che filtri le mail nel vostro server. Spamassassin è ciò che fa per voi. Installiamolo insieme a procmail:

# apt-get install spamassassin procmail

a questo punto aggiungiamo in /etc/postfix/main.cf quanto segue

mailbox_command = /usr/bin/spamc | procmail -a “$EXTENSION”

abilitiamo spamassassin modificando in /etc/default/spamassassin

ENABLE=1

aggiungiamo al file /etc/procmailrc quanto segue:

DROPPRIVS=yes
:0fw
| /usr/bin/spamassassin

Per settaggi particolari di spamassassin vi consiglio di dare un’occhiata al file /etc/spamassassin/local.cf oppure consultare il sito web http://www.yrex.com/spam/spamconfig.php che vi consente di creare un file di configurazione personalizzato rispondendo alle varie domande.

WebMail – Openwebmail
Per poter usufruire del servizio di webmail è necessario usare un server web. Io vi consiglio apache con supporto php e cgi. In questa guida presumo che nel vostro server sia già presente apache configurato a dovere. Esistono diversi servizi di WebMail, io ho scelto openwebmail. Per installarlo digitate:

# apt-get install openwebmail

Dopo l’installazione recatevi in /etc/openwebmail e date un occhiata al file apache.conf che contiene le specifiche per configurare apache. Apriamo ora /etc/openwebmail/openwebmail.conf e apportiamo le nostre personalizzazioni. Attenzione alla voce domainnames, spesso auto può portare a dei problemi, vi consiglio di specificare il dominio di appartenenza. Per altre modifiche consultate il file /usr/share/openwebmail/configs/openwebmail.conf

Gestione Mailing-List Mailman + Hypermail
Ogni mailserver che si rispetti ha anche un gestore di mailing-list. Io vi consiglio di installare mailman che possiede un ottimo supporto web per le varie configurazioni:

# apt-get install mailman hypermail

Fatto questo modificate /etc/postfix/main.cf aggiungendo quanto segue:

alias_maps = hash:/etc/aliases
hash:/var/lib/mailman/data/aliases
transport_maps = hash:/etc/postfix/transport
relay_domains = lists.vostrodominio.com
mailman_destination_recipient_limit = 1

creiamo /etc/postfix/transport e trasformiamolo in una mappa

# echo lists.vostrodominio.com mailman: > /etc/postfix/transport
# postmap /etc/postfix/transport

Modificate ora il file /etc/postfix/master.cf:

mailman unix – n n – - pipe flags=FR user=list argv=/var/lib/mailman/bin/postfix-to-mailman.py ${nexthop} ${user}

Modificate nel file /etc/mailman/mm_cfg.py i seguenti tag:

DEFAULT_EMAIL_HOST = ‘vostrodominio.com’
DEFAULT_URL_HOST = ‘www.vostrosito.com’
MTA=’Postfix’
PUBLIC_EXTERNAL_ARCHIVER = ‘hypermail -L it -m /var/lib/mailman/archives/private/%(listname)s.mbox/%(listname)s.mbox -l %(listname)s -d /var/lib/mailman/archives/public/%(listname)s’
PRIVATE_EXTERNAL_ARCHIVER = ‘hypermail -c -L it -m /var/lib/mailman/archives/private/%(listname)s.mbox/%(listname)s.mbox -l %(listname)s -d /var/lib/mailman/archives/private/%(listname)s’
PUBLIC_ARCHIVE_URL = ‘/archives/%(listname)s’
PRIVATE_ARCHIVE_URL = ‘/archives/%(listname)s’
ARCHIVE_TO_MBOX = 2

Fate attenzione alle voci PUBLIC_ARCHIVE_URL e PRIVATE_ARCHIVE_URL. Sono i link che in mailman verranno associati all’archivio delle vostre mailinglist (www.vostrodominio.it/archives/nomelista). di conseguenza un mio consiglio è creare un link simbolico nella DocumentRoot del server apache in questione:

# ln -s /var/lib/mailman/archives/public/ archives

Create poi una lista mailman di default per il server (altrimenti il suo demone si rifiuta di partire)

# newlist mailman

ed il gioco è fatto. Per creare nuove mailing-list basta usare il comando newlist e per rimuoverle rmlist. Per le altre configurazione mailman crea nella vostra directory cgi-bin un programma che vi consente tramite web di accedere alle varie mailing-list per poter modificarne alcuni parametri, anche in questo caso si richiede una corretta configurazione di apache.

Autenticazione SASL2 ed SMTPS
In questa parte vediamo come realizzare un server che consenta di inviare mail con autenticazione e, proprio per questo, si consiglia di usare un protocollo criptato (smpts). Per prima cosa sarà necessario installare sasl2:

# apt-get install libsasl2-2 libsasl2-modules sasl2-bin

Una volta installati, occorre modificare il file /etc/postfix/master.cf da così:

#tlsmgr fifo – – n 300 1 tlsmgr
#smtps inet n – n – – smtpd -o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
#587 inet n – n – – smtpd -o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes

a così:

tlsmgr unix – – n 300 1 tlsmgr
smtps inet n – – – – smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject

587 inet n – n – – smtpd
-o smtpd_enforce_tls=yes
-o smtpd_sasl_auth_enable=yes

In questo modo si attiva la possibilità di usare smtps. Successivamente è necessario abilitare il demone saslauthd modificando come segue il file /etc/default/saslauthd:

START=yes

Se postfix venisse avviato in chroot (/var/spool/postfix/) allora è necessario spostare i file di database utenti che si crea sasl2-bin e il socket per permettere a postfix di dialogare con saslauth. Per fare questo è necessario svolgere i seguenti passi:

# /etc/init.d/saslauthd stop
# mkdir /var/spool/postfix/var/run/saslauthd
# chmod 0711 /var/spool/postfix/var/run/saslauthd
# chgrp postfix /var/spool/postfix/var/run/saslauthd
# rmdir /var/run/saslauthd
# ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd
# ln -s /var/run/saslauthd /var/run/sasl2
# adduser postfix sasl

E’ necessario modificare il file di configurazione del demone postfix /etc/init.d/postfix perché copi nella sua root il file /etc/sasldb2 modificando da:

FILES=”etc/localtime etc/services etc/resolv.conf etc/hosts \
etc/nsswitch.conf etc/nss_mdns.config”

a:

FILES=”etc/localtime etc/services etc/resolv.conf etc/hosts \
etc/nsswitch.conf etc/nss_mdns.config etc/sasldb2″

Occorre ora modificare il file /etc/postfix/main.cf aggiungendo le seguenti righe:

smtpd_sasl_auth_enable = yes
smtpd_sasl_security_option = noanonymous
broken_sasl_auth_clients=yes
smtpd_sasl_authenticated_header=no

smtpd_recipient_restrictions = permit_sasl_authenticated
permit_mynetworks
reject_unauth_destination
smtpd_client_restrictions = permit_sasl_authenticated
reject_unknown_client

smtpd_use_tls = yes
smtpd_tls_key_file = /etc/ssl/misc/server.pem
smtpd_tls_cert_file = /etc/ssl/misc/server.pem
smtpd_tls_CAfile = /etc/ssl/misc/root.crt
smtpd_tls_loglevel = 2
smtpd_tls_received_header = no
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

ove /etc/ssl/misc/server.pem va creato opportunamente. Infine occorre creare il file /etc/postfix/sasl2/smtpd.conf che dovrà contenere la seguente riga:

pwcheck_method: saslauthd
mech_list: plain login

e il file /etc/pam.d/smtp che dovrà contenere le seguenti righe:

#
# The PAM configuration file for the sasl authentication service
#

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session

Relay host
L’ultima cosa che tratteremo in questa guida è la configurazione del relayhost, ovvero il server a cui inoltrare le mail che non vengono riconosciute come locali. Per fare questo è necessario aggiungere le seguenti riche al file /etc/postfix/main.cf:

smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_sasl_mechanism_filter = plain login
relayhost = mail.yourisp.org

La configurazione è semplice: si specifica il relayhost e si dichiara che si intende usare un protocollo tls con autenticazione. L’autenticazione sarà fornita tramite il file /etc/postfix/sasl_passwd che presenterà la seguente sintassi:

mail.yourisp.org user:password

Tale file deve essere salvato in hash e richiede, pertanto, la sua preparazione con il comando:

# postmap sasl_passwd

Dal file .zip bisogna estrarre system.img ed estrarre il file libhgl.so.
Per chi non volesse compiere tutti questi passaggi può scaricarlo da questo link.

Una volta installato il file si può procedere a caricarlo sul cellulare seguendo i passi descritti qui sotto:

1. Avviare il Samsung Galaxy in modalità Recovery (volume basso + tasto chiamata + tasto accensione)
2. Collegare il cellulare al pc ed avviare ed entrare nel sistema tramite adb (fornita dall’android SDK)
3. Eseguire i seguenti comandi:

# cd /
/ # umount /system/
/ # mount /dev/block/mtdblock1 /system
/ # mv /system/lib/libhgl.so /system/lib/libhgl.so.old
/ # mv /sdcard/libhgl.so /system/lib
/ # reboot
Riavviate il cellulare e il gioco è fatto.

Si consideri ad esempio il caso in cui si vogliano cercare componenti analogiche: spezzando la parola si ottiene anal-ogiche. La prima parte può trarre in inganno il filtro sul proxy e bloccare l’accesso ai siti che trattano questo argomento.

In questo post vediamo come fare per superare i limiti imposti da una configurazione di questo tipo.

Occorrente:

• PC conesso sempre ad internet
• DynDNS (per avere sempre un associazione precisa tra nome e ip)
• Server ssh
• Server web (opzionale)
• proxytunnel installato sul client
• Software compatibili con proxy socks o plugin (FoxyProxy per Firefox)

Configurazione lato server

Lato server si può procedere in due modi:

• porre il demone di ssh-server in ascolto sulla porta 443
• usare apache come proxy

La prima soluzione è facile: basta aprire il file /etc/ssh/sshd_config e sostituire da:
Port 22
a:
Port 443

La seconda soluzione necessita di apache installato e dei seguenti moduli attivi:

1. proxy
2. proxy_http
3. proxy_html
4. proxy_connect

Fatto ciò bisogna aggiungere al virtual server selezionato per questo scopo le seguenti righe:

ProxyRequests on
AllowCONNECT 22 2022
ProxyVia on
<proxy *>
order deny,allow
allow from localhost
allow from IP_OR_NET
deny from all
allow from all
</proxy>
Tramite le chiavi allow e deny si può consentire l’accesso solo a determinati host.
E’ assolutamente indispensabile che apache sia attivo e in ascolto sulla porta 443 aggiungendo nel file /etc/apache2/ports.conf:

NameVirtualHost *:443
Listen 443


Configurazione lato client

Lato client la configurazione è molto semplice.

E’ necessario modificate il file ~/.ssh/config aggiungendo si seguenti campi:
Host <MIOSERVER>
DynamicForward 1080
ProxyCommand proxytunnel -v -p <PROXY_IP>:<PROXY_PORT> -P <USERNAME>:<PASSWORD> -t <DOMAIN> -r <MIOSERVER>:443 -d %h:%p -H "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)\n"
ServerAliveInterval 30
Create uno scritp in /usr/local/bin e chiamatelo, ad esempio, tunnel:
#!/bin/bash
ssh -D 8080 <MIOSERVER_IP>
A questo punto per connettersi è necessario digitare:
$ tunnel
e configurare tutti i software per usare un proxy socks con i seguenti parametri:

• Indirizzo IP: 127.0.0.1
• Porta: 8080

Buona Navigazione

In questo post vediamo come configurare squid per questo scopo.

Per prima cosa, è necessario che il server in questione faccia da gateway per la rete di host che deve proteggere. Ciò richiede che abbia due interfacce di rete, ad esempio:

• eth0 (rete interna)
• eth1 (rete esterna)

Bisogna configurare, anche, delle regole di firewall che garantiscano:

• connessione diretta (o tramite masquerade) degli host appartenenti alla rete interna (in particolare tramite il protocollo dns).
• blocco delle connessioni in ingresso verso la rete.

Il proxy server che verrà installato, dovrà essere configurato come http accelerator (caching proxy) e sarà necessario redirezionare tutto il traffico http in transito sulla porta in cui è in esecuzione tale servizio.

Un proxy che permette questa funzionalità è squid (http://www.squid-cache.org).

Configurare Squid

Il file di configurazione di squid è /etc/squid/squid.conf. Per prima cosa occorre definire su quali porte stare in ascolto:
http_port 8080 transparent
Si può eventualmente anche indicare l’interfaccia su cui stare in ascolto nel seguente modo:
http_port 192.168.0.254:8080 transparent
ove 192.168.0.254 è l’indirizzo che ha il server nella rete interna.

La keyword transparent consente di utilizzare squid come http accellerator.

Per le versioni precedenti alla 2.6 era necessaria una sintassi differente:
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on


Configurazione del firewall

Una volta che il transparent proxy è funzionante, occorre redirigere tutto il traffico http, che è destinato alla porta 80, sulla porta dove sta in ascolto squid 8080. Per fare ciò, basta aggiungere la seguente regola:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Agire sulla catena prerouting implica che tutto il traffico in ingresso e in transito diretto alla porta 80 (non importa indirizzo di sorgente o di destinazione del pacchetto) è rediretto sulla porta 8080.

Si può fare la stessa cosa con https (porta tcp 443) ed ftp (porta tcp 20 e 21).

Supponiamo di avere nel sistema con 2 interfacce di rete

• 00:00:00:00:00:00 -> scheda primaria
• 00:00:00:00:00:11 -> scheda secondaria

Vogliamo che la prima assuma come nome eth0 e la seconda eth1.

Per fare ciò è necessario modificare il file:

/etc/udev/rules.d/XXpersistent-net.rules

ove XX dipende dalla distribuzione e dalla versione di udev che state usando e aggiungere le seguenti righe:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:00:00:00", NAME="eth0"

UBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:00:00:00:11", NAME="eth1"