Oliver Schad wrote:
> --------------[RFC 793 - Transmission Control Protocol]---------
> --------------[RFC 792 - INTERNET CONTROL MESSAGE PROTOCOL]---------
> What was your argument?
That the open and honest nature of the Internet's original design isn't
always the best plan for a security policy.
SMTP and HTTP proxies are open protocols as well, but it's quite
inadviseable to allow global relaying for either/both service(s).
I don't send anything back to any unexpected port probes because I don't
Sure, to some extent it is security through obscurity, but the old
addage isn't entirely correct. If not for security through obscurity
we'd all have our PIN numbers sharpie'd on our ATM cards.
Going back to NAT - again, the old "NAT is not security!" addage is an
over-generalization. One-to-many NAT *IS* inherrently secure. If some
schmoe behind my NAT router decides to deploy a default install of
IIS/[4-5], or SQL Server, or even an old Apache or Rsync or MySQL server
- the outside world will not be able to access said service unless I
give it permission (deny all, allow some is NAT's model; much
consumer-level NAT equipment has an option to allow an open system,
which, thankfully, I've never seen enabled per default), and I assure
you, I won't until I've verified the security of the install.
DROP versus REJECT isn't a be-all, end-all security mechanism. It is,
however, one facet of a good security model. As long as people
understand that, I don't think it's a terribly big issue.
Stewart Honsberger - http://blackdeath.snerk.org/
To teach is to learn twice.
-- Joseph Joubert
email@example.com mailing list