Koozali.org: home of the SME Server
Other Languages => Italiano => Topic started by: v8star on March 15, 2016, 05:32:08 PM
-
Buongiorno a tutti,
ho un cliente a cui devo trasferire nella sua struttura l'hosting di 5 caselle email fornendo pop, imap e webmail per cui sme è un must.
La ricezione delle mail (quindi l'mx record) è e resterà affidato ad un server in gestione in un datacenter che non fa altro che risparare le email pulite ad un host in relazione al dominio del cliente.
Il problema sorge dal fatto che il cliente non ha un firewall per limitare il traffico sulla porta 25 ad un solo ip e con SME non saprei come fare. il contrib Email-Whitelist l'ho testato ma putroppo non riesco a farlo funzionare o non fa a questo caso.
Si può agire con le iptables oppure c'è qualche metodo più elegante?
grazie
-
Una sorta di
db config setprop servizio_smtp AllowHosts a.b.c.d,x.y.z.0/32
db config setprop servizio_smtp DenyHosts e.f.g.h,l.m.n.0/24
signal-event remoteaccess-update
potrebbe funzionare...
-
ahem...
o "db configuration" oppure "config" :-)
in ogni caso il suggerimento è corretto.. il DenyHosts potrebbe anche essere uno 0.0.0.0/0, ma consiglio di fare dei test.
il servizio è sul quale agire è qpsmtpd, ma, mi ripeto, qualche test è da fare
-
mi correggo, il servizio è smtpd
con un
config setprop smtpd AllowHosts ip_server/32 DenyHosts 0.0.0.0/0
signal-event remoteaccess-update
ottengo (nel mio caso ip_server è 10.0.3.254)
denylog tcp -- anywhere 10.0.3.15 tcp dpt:smtp
ACCEPT tcp -- 10.0.3.254 10.0.3.15 tcp dpt:smtp
ripeto, è da testare, perchè l'ordine delle regole è fondamentale..
-
da un iptables -S ho estrapolato questo output:
-A InboundTCP -j InboundTCP_24020
-A InboundTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -j denylog
-A InboundTCP_24020 ! -d 192.168.1.150/32 -j denylog
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 80 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 993 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 443 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j denylog
-A InboundTCP_24020 -s 123.123.123.123/32 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A InboundTCP_24020 -s 456.456.456.456/32 -d 192.168.1.150/32 -p tcp -m tcp --dport 25 -j ACCEPT
-A InboundTCP_24020 -d 192.168.1.150/32 -p tcp -m tcp --dport 465 -j ACCEPT
dalla rete locale riesco ancora a fare un telnet sulla 25 ma da fuori vengo segato
teoricamente dovrei muovere la regola in grassetto dopo le altre 2 in corsivo, right?
-
si..
ti consiglio di porgere la domanda nei forum in lingua inglese, spiegando la tua situazione e chiedendo il miglior modo per implementarla; fossi in te non chiederei "come scambiare l'ordine delle regole di iptables" :-)
farei comunque riferimento al metodo testato (AllowHosts e DenyHosts)
-
sto facendo un po di test, lo sme è virtuale e sto andando di snapshot a spago :lol:
non mi è chiaro come lavora il proxy smtp: vedo che c'è anche questa regola qua
Chain SMTPProxy (1 references)
target prot opt source destination
denylog tcp -- anywhere anywhere tcp dpt:smtp
è così di default o è stata anch'essa coinvolta nel comando suggerito?
grz
-
non sono nella possibilità di fare test ora, quindi non so risponderti :-)
-
guarda, ho segato la regola nella chain e parrebbe funzionare: senza metter mano alla configrazione del dom del cliente in DC, ho creato un dominio parallelo per test in DC e in sme e sparato in DC una mail di test. Consegnata correttamente! :grin: da un terzo/quarto ip non incluso nelle regole la connessione viene correttamente segata
iptables -D InboundTCP_24020 6
Questo lasciando inalterato tutto il resto come proxy ecc ecc.
Sarebbe bello a questo punto stilare una procedura straight-forward senza poi dover metter mano alle iptables.
-
ed infatti è per questo che ti consiglio caldamente di chiedere altrove..
tutto è templatizzato.. tu puoi benissimo crearti un template customizzato che agisca solo ove e quando necessario al fine di ottenere quanto necessiti..
non ho modo ora di dedicarmi alla cosa ma posso dirti che
- i template sono in /etc/e-smith/templates/etc/rc.d/init.d/masq
- lo script finale, eseguito al boot e ricompilato ogni volta che richiami l'evento remoteaccess-update è /etc/rc.d/init.d/masq
puoi dare un'occhiata allo script finale, capire dove dovresti interventire, determinare il fragment coinvolto, copiarlo in /etc/e-smith/templates-custom/etc/rc.d/init.d/masq/ e modificarlo a tuo piacere
questa è l'unica via per otterere quello che vuoi in modo coerente e sicuro su SME
-
ok, vediamo se nell'altro forum qualcuno mi illumina.
sta di fatto che ho applicato gli aggiornamenti disponibili, essendo una fresh install e al riavvio sono andato a rivedermi le iptables, convinto di aver perso tutto e invece ci sono ancora, inclusa anche quella in grassetto che mi blocca tutto, generata dal denyhost.
A questo punto bisogno capire come togliere la entry denyhost per l'smtp
-
rileggi il mio messaggio ove parlo di template
è ovvio che le tue regole siano ancora in place: le hai create usando il giusto meccanismo
-
ok, e questo mi sta bene.
Quel che mi manca da fare è segare via la regola denyhost: al momento ho risolto in maniera poco elegante dando "config setprop smtpd DenyHosts none" sme all'avvio si incazza un po segnalando che "none" non è una net valida ma comunque non creandomi la regola di deny.
Leggendo i vari tutorial https://wiki.contribs.org/Firewall (https://wiki.contribs.org/Firewall) non trovo altro che regole di aggiunta/replace di deniedhost
-
stai ragionando in modo errato.. non devi segare la regola, devi modificare lo script in modo che, nel caso del servizio smtpd, le regole vengano invertite
-
voglio sono annullare il comando denyhost dato in precedenza, claro che alle iptables non va messo mano
-
quindi vuoi togliere..
config delprop smtpd DenyHosts
signal-event remoteaccess-update
-
si esatto: se ho capito bene dalle guide definendo allowedhosts vengono create delle jump rules che già bloccano tutto il resto quindi non serviva definire i denied.
http://distro.ibiblio.org/smeserver/contribs/gordonr/devguide/html/x2072.htm
-
Quindi potresti, a futura fruizione, dirci per esteso come hai risolto?
TIA :)
-
semplicemente non applicando regole con il denyhost:
config setprop smtpd AllowHosts 123.123.123.123,234.234.234.234/32
e abilitando solamente quello che serve: viene escludo tutto il resto automaticamente, il link nel mio penultimo post lo spiega benissimo.
-
...il link nel mio penultimo post lo spiega benissimo.
Ma io sono "tordone"... così è più semplice... ^_^