iis smtp nntp: Hello,

I have an Windows 2000 IIS server running a web site that uses forms to send
email. The mail is sent via the IIS SMTP server running on the same box.
Everything works great, but I want to make sure it is not an open relay.
Under Access Control, the relay restrictions are configured such that only
the local host 127.0.0.1 is granted access to relay through this server, and
I have unchecked 'Allow all computers which authenticate to relay, regardless
of the list above.' Authentication is set to anonymous. I was told
anonymous is fine since the web sites are local to the same box and only that
box is allowed to relay. Is this correct or am I missing something?

[quoted text, click to view]

That's fine. You are not an open relay. But while on the one hand you
have guarded against remote-initiated sessions, whether authenticated
or anonymous, you have in fact allowed _any_ loopback connections (for
example, from trojans, code injected through your web pages, etc.) to
relay.

I usually advise the opposite tactic. Don't relay by IP. Use SMTP AUTH
in your web code if available, and only relay for authenticated
sessions. This is allows for much more granular control + auditing,
for example by creating different accounts for different web apps.

Note that if you are not allowing remote connections to your box on
port 25 _at all_, then you cannot be an open relay in any traditional
sense. You can be an open _proxy_, however, if there are holes in your
web app or commercial web components that allow people to do an HTTP
form post that results in mail getting sent through the local SMTP
server. Such mail is loopback-initiated and would thus be relayed to
the outside world. An additional layer of protection via passwords can
mitigate some of those risks (though not all, since you usually end up
embedding the SMTP AUTH password in your code). Depends on your app
and how it interacts with users.

[quoted text, click to view]

Under authentication, "Anonymous" should be interpreted as "Anonymous
sessions allowed." Technically speaking, as there is no SMTP-level
AUTH mechanism used at all in an anonymous session, so it's not
"anonymous auth."

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

[quoted text, click to view]

That's not an issue for a server that, as the OP states, is used only
to send form mail -- and thus *must not* have incoming port 25 allowed
through the firewall. It would've been silly to state the obvious
security concerns of any Internet-connected machine (i.e. "block at
the firewall any ports you are not using").

More important, the discussion is about relay-by-AUTH vs. relay-by-IP,
but you're reframing it as relay-by-AUTH vs. *access*-by-IP.
Relay-by-AUTH and access-by-IP are not mutually exclusive; rather,
they are governed by two totally separate parts of the interface. When
you can't block block unwanted traffic at the edge, firewall, or even
local stack level, it's best practice to block as early in the
application level as possible; you should not allow anyone to attempt
connections on ports for which there is no legitimate traffic. This
means disallowing all traffic (access-by-IP) from anywhere but
127.0.0.1 for any server that, as in the OP's example, sends form mail
only. That makes the dictionary attack "issue" a red herring if
correct configuration is otherwise used.

[quoted text, click to view]

Laziest to maintain !=3D Easiest to maintain. It's one thing to=

streamline your configuration, it's another to have no audit trail or
security boundaries because you run everything in the same context.
Web developers need to get used to the uncomfortable idea of _somebody
else_ running their code, whether that be a customer or a hacker. That
means knowing *which* web application sent mail from 127.0.0.1. On a
server with innumerable posting acceptors running under the same
context, an accidentally open HTTP-SMTP proxy is almost impossible to
track down.

--Sandy


------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.

What you are doing is fine, subject to the caveats that Sanford as posted in
his reply.

That said, Sanford has suggested turning SMTP AUTH back on (via "allow
machines that authenticate to relay" checkbox). The only issue here is that
you open yourself up to dictionary style attacks from malicious users that
probe well known accounts (such as "Administrator"). Either ensure that
remote IP addresses are not able to connect, or rename all well known
accounts, or ensure that well known accounts have strong passwords.

As it is, your current configuration is probably the easiest to maintain.

Cheers
Ken

--
My IIS Blog: www.adOpenStatic.com/cs/blogs/ken

[quoted text, click to view]