All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Newkirk <netfilter@newkirk.us>
To: Athan <netfilter@miggy.org>, netfilter@lists.netfilter.org
Subject: Re: SMTP external
Date: Thu, 2 Jan 2003 20:29:16 -0500	[thread overview]
Message-ID: <200301022029.16450.netfilter@newkirk.us> (raw)
In-Reply-To: <20030102234447.GA11431@miggy.org>

On Thursday 02 January 2003 06:44 pm, Athan wrote:

> 	iptables -A INPUT -m state --state NEW,ESTABLISHED -p tcp
> 	--sport 25
> 	iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -p tcp
> 	--dport 25
>
> Untested, off the top of my head, but should do the job.
>
> -Ath

Umm, it might help to have a target... adding "-j ACCEPT" perhaps?  :^) 
Also, since the intent is to let outside clients connect TO port 25, the 
INPUT rule should use --dport, while the OUTPUT should use --sport.  Of 
course, if a looser OUTPUT rule already exists (like EST/REL with no 
protocol specified) then the OUTPUT rule would be redundant anyway.  
(but would also be a sign that the firewall /could/ be tighter)

 If logging of 'all' access is desired, at least for a test period, I'd 
suggest logging ONLY state NEW connections in INPUT, to keep from being 
overwhelmed.  Unless something goes seriously wrong, or you have 
unsecure rules elsewhere, you will still log each and every IP that 
tries to connect to port 25, but only once per attempt, instead of once 
for each packet in 3mb worth of family christmas pictures or such.  (and 
lord help your logfile if they send it to several family members 
individually... :^)  It'd probably be a good idea to log port 25 DROPs 
as well, so you can see if anyone has been poking around.

For individual IP control just redirect all NEW state dport 25 from INPUT 
to a custom chain that has an ACCEPT rule for each client IP, and a DROP 
at the end.  Obviously this would require either that every client has a 
static IP, or that you allow ranges of IP's which their dynamic IP is 
assigned from, and the latter isn't a good idea.  Since you're unlikely 
to be lucky enough that every client is (and would remain) on a static 
IP, this probably is pointless.

Finally, and probably most important, go to http://sendmail.net 
(presuming that's what you'd be running) and download and install latest 
releases, and read through and follow all their security instructions.  
Starting with version 8.10 (8.12 is current release) sendmail supports 
SMTP AUTH - use it.

j




  reply	other threads:[~2003-01-03  1:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-02 22:40 SMTP external Simpson, Doug
2003-01-02 23:31 ` Linux
2003-01-02 23:44   ` Athan
2003-01-03  1:29     ` Joel Newkirk [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-01-02 23:34 Simpson, Doug
2003-01-02 23:37 ` Linux
2003-01-03 15:55 Simpson, Doug

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200301022029.16450.netfilter@newkirk.us \
    --to=netfilter@newkirk.us \
    --cc=netfilter@lists.netfilter.org \
    --cc=netfilter@miggy.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.