[ale] iptables: DROP vs. REJECT --reject-with tcp-reset

[Mike Millson]

Right now my iptables firewall is set up to DROP all undesirable TCP
packets. However, I have read that DROP can be a giveaway that you are
running a firewall. Is it better to try to look like you don't have a
firewall and use REJECT --reject-with tcp-reset? What are good scenarios to
use REJECT --reject-with tcp-reset?

Thank you,
Mike


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Amarendra Godbole (Intl Vendor)]

Post by Mike Millson
Right now my iptables firewall is set up to DROP all undesirable TCP
packets. However, I have read that DROP can be a giveaway that you are
running a firewall. Is it better to try to look like you don't have a
firewall and use REJECT --reject-with tcp-reset? What are
good scenarios to
use REJECT --reject-with tcp-reset?

Keeping the packet filtering tool aside, security by obscurity is no
longer a valid scenario, and never works for a longer time. DROP and
REJECT choice can be made on how powerful your firewall machine is. In
DROP the packets are immediately dropped and no reply is sent, while in
REJECT a reply which says that ``Hey, I am rejecting your packets :)''
is sent. So if you want to put less burden on your machine, go for a
DROP, else REJECT is also fine.

The choice for DROP or REJECT with reference to security by obscurity is
not a good idea. And there is no harm letting them know that yes, we
have adequate mechanisms to fight you... :)

Cheers,
--amar

--
Amarendra A. Godbole / Microsoft ``Services For UNIX'' / These opinions
are _MINE_.
If you miss love, you miss life.

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[James P. Kinney III]

If someone is banging on a port I have closed off for security reasons,
I don't want to give them any information or waste any bandwidth telling
them to go away. Just like when the door-to-door salesman knocks, I
don't want to be bothered to answer it and tell them to go away.

Besides, DROP is shorter to type and uses less of my systems to
implement. :)

Post by Mike Millson
Right now my iptables firewall is set up to DROP all undesirable TCP
packets. However, I have read that DROP can be a giveaway that you are
running a firewall. Is it better to try to look like you don't have a
firewall and use REJECT --reject-with tcp-reset? What are good scenarios to
use REJECT --reject-with tcp-reset?
Thank you,
Mike
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

--
James P. Kinney III \Changing the mobile computing world/
President and COO \ one Linux user /
Local Net Solutions,LLC \ at a time. /
770-493-8244 \.___________________________./

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7



---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Chris Ricker]

Post by Amarendra Godbole (Intl Vendor)
The choice for DROP or REJECT with reference to security by obscurity is
not a good idea. And there is no harm letting them know that yes, we
have adequate mechanisms to fight you... :)

<rant>

You know, this is a very mistaken assumption that I frequently hear from
people. They start with the notion that "Security by obscurity is bad."
Okay, true enough. However, it doesn't in any way follow from that what
they mistakenly conclude: that it's therefore an acceptable security
practice to divulge information needlessly.

For an extreme example, think about /etc/shadow on Unix boxes. It's
obscure. Only root can read it. The (il)logical conclusion of what you're
saying is that it's acceptable to chmod a+r /etc/shadow. Or that you should
as a matter of practice post your internal network topology (after all,
determined people can find that out anyway). Or that you should make your
router ACLs publically available (ditto). Or that....

"Security by obscurity" means one specific thing: hiding security holes,
rather than fixing them, then relying on the fact that they're allegedly
unknown to prevent them from being exploited. Simply not needlessly
divulging information is NOT security by obscurity, but rather is one of the
basic tenets of safe security practice. There's a significant difference
between the two.

</rant>

Back to the original question:

RFC behavior is that unbound TCP ports return resets on connections, and
unbound UDP ports return ICMP port unreachable. If you want to make your
firewall less obtrusive, then do that. Your filtered ports will then be (at
least in that respect) indistinguishable from unfiltered, unbound ports.

If you want your port filtering to be very obvious, then use DROP instead.

later,
chris


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Chris Ricker]

Post by James P. Kinney III
If someone is banging on a port I have closed off for security reasons,
I don't want to give them any information or waste any bandwidth telling
them to go away. Just like when the door-to-door salesman knocks, I
don't want to be bothered to answer it and tell them to go away.
Besides, DROP is shorter to type and uses less of my systems to
implement. :)

Depending upon the client, sending resets is actually more efficient.

If the client receives an ICMP port unreachable, she will give up and move
on to the next UDP port. Ditto for reset and TCP ports.

If the client receives no response, he's likely to just keep flooding more
packets at the port (particularly for UDP).

Sure, REJECT results in you sending a response you wouldn't otherwise send
(nominally using more bandwidth), but it also cuts off further incoming
traffic (saving bandwidth, and reducing filter load).

later,
chris


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Geoffrey]

Post by Amarendra Godbole (Intl Vendor)

Post by Mike Millson
Right now my iptables firewall is set up to DROP all undesirable TCP
packets. However, I have read that DROP can be a giveaway that you are
running a firewall. Is it better to try to look like you don't have a
firewall and use REJECT --reject-with tcp-reset? What are
good scenarios to
use REJECT --reject-with tcp-reset?

Keeping the packet filtering tool aside, security by obscurity is no
longer a valid scenario, and never works for a longer time.

I disagree. security by obscurity is not a valid solution when used as
the sole protection mechanism, but it can be a useful tool on an overall
security design. No protection mechanism is perfect, but if you hit
them from various angles, you'll slow them up enough to catch them
before they do you any damage.

Post by Amarendra Godbole (Intl Vendor)
DROP and
REJECT choice can be made on how powerful your firewall machine is. In
DROP the packets are immediately dropped and no reply is sent, while in
REJECT a reply which says that ``Hey, I am rejecting your packets :)''
is sent. So if you want to put less burden on your machine, go for a
DROP, else REJECT is also fine.

Typically, you want to reject a packet that you received because it was
an honest mistake by the sender. You want to drop a packet, because it
was sent by someone attempting something malicious and you don't want to
provide them any insight into your network protection scenario. The big
question is, how do you tell the difference? :)

Post by Amarendra Godbole (Intl Vendor)
The choice for DROP or REJECT with reference to security by obscurity is
not a good idea. And there is no harm letting them know that yes, we
have adequate mechanisms to fight you... :)

I disagree. There's no reason in showing your cards. If you stop them,
and they don't know why all the better for you. If you stop them and
tell them why, that's just plain stupid.

Post by Amarendra Godbole (Intl Vendor)
Cheers,
--amar
--
Amarendra A. Godbole / Microsoft ``Services For UNIX'' / These opinions
are _MINE_.
If you miss love, you miss life.
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

--
Until later: Geoffrey esoteric at 3times25.net

I didn't have to buy my radio from a specific company to listen
to FM, why doesn't that apply to the Internet (anymore...)?


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Geoffrey]

Chris Ricker wrote:


I agree with what you said up to this point, hence I've chopped it out. :)

Post by Chris Ricker
"Security by obscurity" means one specific thing: hiding security holes,
rather than fixing them, then relying on the fact that they're allegedly
unknown to prevent them from being exploited. Simply not needlessly
divulging information is NOT security by obscurity, but rather is one of the
basic tenets of safe security practice. There's a significant difference
between the two.

I've seen it defined more than one way. I agree there is a failing in
obscuring known bugs for the sake of security. Fix them, of course.
But, adding a bit of obscurity to your overall security implementation
can be useful. If you have a web site that is accessed only by your
customers, then it makes sense not to publish it's location. Hopefully,
this is not your only way of protecting the site. Beyond this,
certainly should be some security mechanism to authenticate your customers.

Post by Chris Ricker
</rant>
RFC behavior is that unbound TCP ports return resets on connections, and
unbound UDP ports return ICMP port unreachable. If you want to make your
firewall less obtrusive, then do that. Your filtered ports will then be (at
least in that respect) indistinguishable from unfiltered, unbound ports.
If you want your port filtering to be very obvious, then use DROP instead.
later,
chris
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

--
Until later: Geoffrey esoteric at 3times25.net

I didn't have to buy my radio from a specific company to listen
to FM, why doesn't that apply to the Internet (anymore...)?


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Amarendra Godbole (Intl Vendor)]

Post by Amarendra Godbole (Intl Vendor)

Post by Amarendra Godbole (Intl Vendor)
The choice for DROP or REJECT with reference to security by

obscurity is

Post by Amarendra Godbole (Intl Vendor)
not a good idea. And there is no harm letting them know that yes, we
have adequate mechanisms to fight you... :)

<rant>
You know, this is a very mistaken assumption that I
frequently hear from
people. They start with the notion that "Security by
obscurity is bad."
Okay, true enough. However, it doesn't in any way follow
from that what

Oh, oh, I guess I should have phrased it in a better way. I did not mean
that security through obscurity is bad, what I wanted to say that making
a decision for DROP or REJECT just because it provides you some security
by obscurity is not the proper way. Yes, as you have said security
through obscurity combined with other defense in depth mechanisms is a
very effective firewall indeed. I agree totally.

Besides, who talked about IIS ? I thought this was a Linux only mailing
list (I haven't read the list guidelines), and Apache would have been a
much better choice. ;-) ;-)

Cheers,
--amar

--
Amarendra A. Godbole / Microsoft ``Services For UNIX'' / These opinions
are _MINE_.
If you miss love, you miss life.


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Kevin Krumwiede]

Post by Amarendra Godbole (Intl Vendor)
Besides, who talked about IIS ? I thought this was a Linux only mailing
list (I haven't read the list guidelines), and Apache would have been a
much better choice. ;-) ;-)

I wanted an example of a commonly exploited service, and IIS popped into my
head. I honestly don't know why. :-)

Krum


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

[Geoffrey]

Post by Kevin Krumwiede

Post by Amarendra Godbole (Intl Vendor)
Besides, who talked about IIS ? I thought this was a Linux only mailing
list (I haven't read the list guidelines), and Apache would have been a
much better choice. ;-) ;-)

I wanted an example of a commonly exploited service, and IIS popped into my
head. I honestly don't know why. :-)

Probably because it's a commonly exploited service....

Post by Kevin Krumwiede
Krum
---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.

--
Until later: Geoffrey esoteric at 3times25.net

I didn't have to buy my radio from a specific company to listen
to FM, why doesn't that apply to the Internet (anymore...)?


---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be
sent to listmaster at ale dot org.