RE: Iptables Clues and Advices.

• Previous message: Steve Bremer: "RE: Iptables Clues and Advices."
• In reply to: Jason Dixon: "RE: Iptables Clues and Advices."
• Next in thread: Bryan S. Sampsel: "Re: Iptables Clues and Advices."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

From: "Benjamin Meade" <ben@lanwest.com.au>
To: <security-basics@securityfocus.com>
Date: Wed, 9 Apr 2003 09:56:25 +0800

That is all well and good, but the added security comes not from host
scanners, but from network scanners. For example, there are many tools
that are able to scan an entire IP range to find hosts. In the case of a
REJECT response returned, the scanner will log your server as available,
but a DROP command with cause the scanner to assume that there is no
server attached to this ip address, and move on. Granted, when scanning
against a single host, the security gained is marginal at best, but the
added security against network scanning is worth the effort.

The inside interface is another matter. Here, you assume a higher level
of trust, and thus a REJECT becomes a better proposition.

Benjamin Meade
System Administrator
LanWest Pty Ltd

-----Original Message-----
From: Jason Dixon [mailto:jasondixon@myrealbox.com]
Sent: Wednesday, 9 April 2003 12:20 AM
To: gillettdavid@fhda.edu
Cc: security-basics@securityfocus.com
Subject: RE: Iptables Clues and Advices.

For all the folks who illusion that DROP is more secure than REJECT, I
submit the following:

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

-J.

On Mon, 2003-04-07 at 20:03, David Gillett wrote:
> There is ONE specific case in which I REJECT rather than
> DROP filtered packets:
>
> Sometimes users behind my firewall need to contact an outside
> POP3 email server. Many such boxes react to such connections by
> attempting a connection back to the source on port 113 (identd).
> If I DROP connections to this port, the remote POP3 server
> will wait for its request to timeout -- and then try again and
> timeout again, two more times. By REJECTing the connection, I
> let the server try and fail and try and fail immediately, and so
> my client's download of mail begins much sooner than it would
> if I just DROPped those packets.
>
> David Gillett
>
>
> > -----Original Message-----
> > From: Allan Schon [mailto:allanschon@mckinleymachinery.com]
> > Sent: April 7, 2003 08:53
> > To: security-basics@securityfocus.com
> > Subject: RE: Iptables Clues and Advices.
> >
> >
> > >it will also result into a mess, because the server will be a
> > >hole in space (regarding the blocked ports). And what are
> > the benefits
> > >(if there are any) of this practice?
> >
> > Well, the primary benefit is that attackers scanning for
> > specific open ports in your ip range will never find your
> > machine, if you're dropping connection attempts to the target
> > port. That's a considerable advantage, I think. They can't
> > attack you if they don't know you're there.
> >
> > Are there any specific disadvantages to DROPing?
> >
> > -----Original Message-----
> > From: Andreas Happe [mailto:andreashappe@gmx.net]
> > Sent: Saturday, April 05, 2003 5:29 PM
> > To: security-basics@securityfocus.com
> > Subject: Re: Iptables Clues and Advices.
> >
> >
> > In article <1049484753.24055.41.camel@unsigned.local.fr>,
> > Pierre BETOUIN wrote:
> > > DROP would be better there because you don't need to
> > prevent attackers
> > > that this port is filtered.
> >
> > it will also result into a mess, because the server will be a
> > hole in space (regarding the blocked ports). And what are the
benefits
> > (if there are any) of this practice?
> >
> > andreas
> > --
> > I tell them to turn to the study of mathematics, for it is only
there
> > that they might escape the lusts of the flesh.
> > -- Thomas Mann, "The Magic Mountain"
> >
> >
> > -------------------------------------------------------------------
> > SurfControl E-mail Filter puts the brakes on spam,
> > viruses and malicious code. Safeguard your business
> > critical communications. Download a free 30-day trial:
> > http://www.securityfocus.com/SurfControl-security-basics
> >
> >
> > <b>
> > -------------------------------------------------------------------
> > Is SPAM over-loading your e-mail server, disk space or bandwidth?
> > SurfControl E-Mail Filter is flexible, intelligent and policy-driven
> > protection.
> > http://www.securityfocus.com/SurfControl-security-basics2
> > Download your free fully functional trial, complete with
> > 30-days of free technical support.
> > Stop SPAM before it stops you.
> > -------------------------------------------------------------------
> > </b>
> >
>
> ----
>

> <b>
> -------------------------------------------------------------------
> Is SPAM over-loading your e-mail server, disk space or bandwidth?
> SurfControl E-Mail Filter is flexible, intelligent and policy-driven
> protection.
> http://www.securityfocus.com/SurfControl-security-basics2
> Download your free fully functional trial, complete with 30-days of
free technical support.
> Stop SPAM before it stops you.
> -------------------------------------------------------------------
> </b>

-------------------------------------------------------------------
Is SPAM over-loading your e-mail server, disk space or bandwidth?
SurfControl E-Mail Filter is flexible, intelligent and policy-driven
protection.
http://www.securityfocus.com/SurfControl-security-basics2
Download your free fully functional trial, complete with 30-days of free
technical support.
Stop SPAM before it stops you.
-------------------------------------------------------------------

-------------------------------------------------------------------
Is SPAM over-loading your e-mail server, disk space or bandwidth?
SurfControl E-Mail Filter is flexible, intelligent and policy-driven
protection.
http://www.securityfocus.com/SurfControl-security-basics2
Download your free fully functional trial, complete with 30-days of free technical support.
Stop SPAM before it stops you.
-------------------------------------------------------------------

• Previous message: Steve Bremer: "RE: Iptables Clues and Advices."
• In reply to: Jason Dixon: "RE: Iptables Clues and Advices."
• Next in thread: Bryan S. Sampsel: "Re: Iptables Clues and Advices."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]