Re: how to get IPFW rules for SMTP server behind NAT server "right"? (freebsd-security: message 1 of 20)

From: OpenMacNews (
Date: 11/21/03

  • Next message: OpenMacNews: "teet"
    Date: Fri, 21 Nov 2003 13:01:25 -0800

    -- On Friday, November 21, 2003 12:48 PM -0800 "David Wolfskill -"
    <> wrote:


    thanks for your reply!

    >> i've been struggling with setting appropriate rules for an SMTP-server
    >> behind by NAT'd firewall.
    > OK....


    >> currently, my SMTP ipfw rules are as follows (snip'd from my startup
    >> script)
    >> =============================================
    >># allow connections to/from internal smtp_server
    >> ipfw add 7000 allow log tcp from any to ${smtp_server} 25
    > I suggest appending " setup" to that. Unless I'm very confused, you
    > don't really want to see *every* incoming SMTP packet -- just those that
    > initiate an SMTP conversation. (Note that -- at least in FreeBSD -- the
    > mail traffic gets logged to /var/log/maillog anyway.)
    >> ipfw add 7001 allow log tcp from ${smtp_server} 25 to any
    > Again, you may wish to append " setup" to that, for the same reasons.
    > In conjunction with the above, you'd likely want to (silently) permit
    > "established" connections.

    hadn't dawned on me to this, so:

    ipfw add 7000 allow log tcp from any to ${smtp_server} 25 setup
    ipfw add 7001 allow tcp from any to ${smtp_server} 25 established
    ipfw add 7002 allow log tcp from ${smtp_server} 25 to any setup
    ipfw add 7003 allow tcp from ${smtp_server} 25 to any established


    >># allow clients to communicate with external smtp servers
    >> ipfw add 7002 allow log tcp from ${innr} 1024-65535 to ${exip} 25
    >> ipfw add 7003 allow log tcp from ${exip} 25 to ${innr} 1024-65535
    > Why? Wouldn't you want them to send their mail to your internal mail
    > server, which would then send it out?

    usually, yes

    BUT, sometimes i want to be able to use a local LAN mail client to directly access on offsite SMTP server.

    my understanding is that usually a client uses "high ports" to communicate to those servers at THEIR port 25 -- just
    like to my internal svr, but internal lan traffic is "all open"

    in this case would you recommend the "setup & established" approach as above?

    >> it seems to me that everything's working. question is, are these too
    >> open, too closed, incomplete, risky, etc?
    > Have you actually looked at your security log?

    yes i have

    of course, i've had little DENIED on port 25 ( and a LOT of entries ....)

    other than servers/connection attempts that clearly are failing SMTP 'transactions', i'm frankly not sure what to look
    for for 'unauthorized' access to port25/my server ...

    because of its "open" nature, what are the legit triggers for "suspicious" activity for SMTP?

    > Peace,
    > david
    > --

    _______________________________________________ mailing list
    To unsubscribe, send any mail to ""

  • Next message: OpenMacNews: "teet"

    Relevant Pages

    • Re: quick FW question [SOLVED]
      ... ipfw add allow tcp from any to me 25 ... SMTP server outside the network. ...
    • Re: ipfw question (ip vs tcp)
      ... The ipfw file has a line like this in it: ... > ipfw add allow tcp from any to any 21 setup ... > Either way I can then have full user ftp sessions with this server. ... Why do both commands work and why won't the server ...
    • Re: Re[5]: Assymetric NIC performance problem
      ... I've got a FreeBSD file server running Samba, file upload speeds are okay, ... Client connecting to, TCP port 5001 ... Sorry, I didn't know that UDP bandwidth must be specified manually, ...
    • Re: Internal TCP/IP send buffer?
      ... and that has to be decided at your proxy server. ... UDP or a separate TCP connection to the target and periodically ... connections) constitutes a completely different source of latency. ...
    • Re: Netzwerkproblem GBit -> 100MBit
      ... GBit-Kette - flow control zwingend notwendig sei. ... zwischen Client und Server. ... Das kann TCP an der Stelle nicht mehr leisten. ...