> -----Original Message-----
> From: slug@lists.nks.net [mailto:slug@lists.nks.net]On Behalf Of Levi
> Bard
> Sent: Tuesday, June 10, 2003 12:48 PM
> To: slug@nks.net
> Subject: Re: [SLUG] IPTables/Firewall/SMTP
>
>
> Why not send the mail directly from the av scanner to the "real" mail
> server? Also, why not scan outgoing mail for virii as well?
The firewall is the only machine that knows of an outside world and that is
the way I like it. Allowing the av scanner access to the outside world even
in such a small way as for smtp traffic is more potential trouble than I
really want to deal with.
Eventually we will be scanning outbound mail... but the system had to work
correctly first. ;-)
>
> Then it would be a simple matter of transparently routing all av scanner
> traffic to where it "wants" to go, and bouncing all incoming and internal
> mail to the av scanner.
I actually attempted this and wound up creating an open relay out of my av
scanner... took me three days to get our domain cleared from the rbl's!
Again, letting the firewall make the decisions in this case, I feel is the
wisest... even if I am being overly cautious.
I do appreciate the suggestion.
Thanks,
Bradley
>
> Assuming eth0 outer and eth1 inner, 10.0.0.50 for av scanner:
>
> iptables -A FORWARD -i eth0 -p tcp --dport 25 -j ALLOW
> iptables -A FORWARD -i eth1 -s 10.0.0.50 -p tcp --dport 25 -j ALLOW
> iptables -A FORWARD -i eth1 -p tcp --dport 25 -j ALLOW
>
> iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 10.0.0.50
> iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>
> Levi
>
> > I have a redhat box running as my firewall using iptables.
> I also have
> > an anti-virus scanning appliance inside our network that all incoming
> > email
> > traffic is directed to for scanning. All rerouting is done by iptables.
> > Our actual email server that our users get their mail from
> resides off
> > site, external to our firewall.
> > Also, the firewall is our outgoing SMTP hub running
> postfix. Any email
> > destined for our domain is rerouted inside to our av scanner. Incoming
> > email
> > bypasses postfix and is sent directly to the av scanner. (Postfix only
> > listens on the internal interface).
> > Once scanned, the email is submitted to our SMTP hub to be
> mailed out
> > to
> > our actual mail server, offsite.
> > We have two mx records for our internet dns. MX 10 points to our
> > firewall so that incoming mail gets scanned. MX 20 points to the offsite
> > email server. This works because once mail is submitted to our
> > firewall/SMTP
> > hub, postfix times out trying to send to MX 10 (of course) and
> then sends
> > the mail to MX 20.
> > This works really well and is so far quite reliable. The only thing
> > about it is that since the mail destined for our domain has to
> timeout on
> > the first MX record, it takes quite a while to receive mail in
> and also to
> > send mail to someone locally.
> > I thought about using iptables to just forward the connections
> > directly
> > to the offsite mail server, but so far I have not been able to come up
> > with
> > a rule or rules that would do the trick. I can't just forward all SMTP
> > connections from the av scanner directly to the offsite mail server as
> > that
> > would also forward any bounce messages or other error messages to people
> > trying to send mail in. The offsite mail server will just refuse those
> > messages and that will just clog the av scanner with
> > undeliverable/deferred
> > messages.
> > In an attempt to find a way to do what I need to do with iptables, I
> > used tcpdump to attempt to isolate the smtp traffic coming from the
> > firewall
> > machine as it attempted to deliver mail to our domain. I was trying to
> > match
> > the host ip address of the firewall going to smtp to itself,
> but it never
> > matched. It only matched when it began to send the messages to
> the offsite
> > firewall.
> > I thought about decreasing the timeout in postfix to reduce
> the amount
> > of time to takes to send the messages, but I don't want to affect mail
> > going
> > to other domains.
> > Any thoughts or ideas on how I may be able to speed up the delivery
> > times would be appreciated.
> > Thanks,
> >
> > Bradley Brown
> > Systems Administrator
> > Segrest Farms, Inc
> > Gibsonton, FL
> > bradley@segrestfarms.com
> >
> >
> >
>
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 16:26:15 EDT