IIS and SMTP - Automate Connection Access

Author

Automate Connection Access

NetFodder

2007-04-01, 7:18 pm

Is there a version of ExIpsec.dll/Ipsec.vbs that works on Windows 2003 SMTP
6.0 - (Without Exchange/AD)

Ok, I have an exchange system behind my firewall. I'm trying to setup a
smart host in the DMZ. I've got a simple Windows 2003 server with IIS\SMTP.
It's setup for relaying and all that good stuff. The box itself it all good
and so is the configuation. Now comes time to start working on what I want it
to do. I'm going to be running my anti-virus and spam control on it. It's not
a member of the domain so it's not going to be able to have exchange on it.
One of the things I like to do is block IP's at the transport layer just to
keep the network bandwidth from getting pigged out. On my exchange servers I
watch the spam logs and then for IP's that are nothing but trouble I just
block them using the connections tab. I've helped myself out of many hours
worth of typing in IP addresses and subnets by using the ExIpsec.dll and
Ipsec.vbs script. I simply grab the list of IP's to block and run it. This is
a great tool for doing it on an Exchange server SMTP service but the problem
I have now is this box isn't running Exchange. So does anyone know of a way
to automate adding IP's to the connection control on a plain SMTP 6.0 service?

Steve Schofield

2007-04-02, 1:20 pm

The IIS SMTP is pretty basic, I'm not sure it has this built-in feature.
I'd recommend taking a look at ORF (Open Relay filter)
http://www.vamsoft.com/

--

Steve Schofield
Windows Server MVP - IIS

"NetFodder" <NetFodder@discussions.microsoft.com> wrote in message
news:B6840EC6-5091-4DB6-A919-54C2040FAFBB@microsoft.com...
> Is there a version of ExIpsec.dll/Ipsec.vbs that works on Windows 2003
> SMTP
> 6.0 - (Without Exchange/AD)
>
> Ok, I have an exchange system behind my firewall. I'm trying to setup a
> smart host in the DMZ. I've got a simple Windows 2003 server with
> IIS\SMTP.
> It's setup for relaying and all that good stuff. The box itself it all
> good
> and so is the configuation. Now comes time to start working on what I want
> it
> to do. I'm going to be running my anti-virus and spam control on it. It's
> not
> a member of the domain so it's not going to be able to have exchange on
> it.
> One of the things I like to do is block IP's at the transport layer just
> to
> keep the network bandwidth from getting pigged out. On my exchange servers
> I
> watch the spam logs and then for IP's that are nothing but trouble I just
> block them using the connections tab. I've helped myself out of many hours
> worth of typing in IP addresses and subnets by using the ExIpsec.dll and
> Ipsec.vbs script. I simply grab the list of IP's to block and run it. This
> is
> a great tool for doing it on an Exchange server SMTP service but the
> problem
> I have now is this box isn't running Exchange. So does anyone know of a
> way
> to automate adding IP's to the connection control on a plain SMTP 6.0
> service?

Sanford Whiteman

2007-04-11, 1:21 am

On Sun, 01 Apr 2007 14:54:02 -0400, NetFodder =

<NetFodder@discussions.microsoft.com> wrote:

> So does anyone know of a way to automate adding IP's to the connection=
=

> control on a plain SMTP 6.0 service?

Sure. But before I get into it, you must swear to read my concluding =

paragraph, in which I tell you that this may not be the best fit for wha=
t =

you're doing. Sworn? Good.

Anyway, IIS exposes the Connection Control list via the Metabase propert=
y =

`IPSecurity.` Unlike many other props, even with direct Metabase editin=
g =

enabled, though, you can't easily automate the editing of metabase.xml f=
or =

this property, because it is of the binary data type IPSECLIST rather th=
an =

plain-text. IPSECLIST, for the record, is some kind of serialized array=
=

of hosts/subnet masks... but you don't need to know that, because IIS =

handily serves up the property via ADSI scripting without you having to =
do =

any binary encoding yourself.

With ADSI and the IIS namespace, you can append to the current array of =
=

denied IPs, re-put the options into IIS, and the settings take effect =

immediately.

Observe:

dim objSMTPServer
dim objIPSec
dim arrHosts
set objSMTPServer=3DGetObject("IIS://localhost/smtpsvc/1") 'ADSI IIS =

namespace
objSMTPServer.getinfo
set objIPSec =3D objSMTPServer.get("IPSecurity") 'target metabase proper=
ty
arrHosts=3DobjIPSec.IPDeny 'read current list into temp array
redim preserve arHosts(ubound(arHosts) + 1) 'extend temp array length by=
1
arrHosts(uBound(arrHosts))=3D"1.2.3.4,255.255.255.255" 'add new IP at th=
e end
objIPSec.IPDeny=3DarrHosts 'reserialize array back into metabase data ty=
pe
objSMTPServer.put "IPSecurity" ,objIPSec 'flush everything back into IIS=

objSMTPServer.setinfo

*However*, before you commit to this method, I would think about using =

(and scripting) OS-level IP security instead, if you're up for it. =

Application-level security means that a socket needs to handed "up the =

stack" to whatever process owns the socket before a connection can be =

reset. That tiny bit of overhead may seem insignificant for the =

occasional hit, but if you're fending off a real DoS attack, it makes a =
=

big difference. I was working on a client's (non-Exchange, competitive)=
=

mail server just the other week and they were seeing an unendurable CPU =
=

spike from spammers trying to guess POP3 passwords. The mail app offere=
d =

its own application-level connection control, but even adding all of the=
=

offending IPs in there did not stop the server from hanging; the fact th=
at =

the POP3 service was not very efficiently coded in general was surely pa=
rt =

of the problem, but the fact remained that when the POP3 daemon had to u=
se =

its own connection control to drop the socket, the server couldn't deal.=
=

When I used OS-level Windows IP Security Policy to block the same set of=
=

IPs, everything went back to normal instantly.

I admit I haven't seen such a dramatic difference in Microsoft-authored =
=

products, probably because the IIS components are so tightly coupled to =
=

the TCP/IP stack. But when blocking at a border router is not possible =
=

due to administrative delegation or just too much complexity, you will =

_always_ do better to do host-based blocking through the OS, rather than=
=

through an uplevel application. Other advantages to scripting the OS IP=
=

filters are that there's more literature on it and it's better for =

building a portable skill set. But the application-level with IIS is =

clearly doable, and I invite you to give it a shot first. Contact me =

directly if you want to go over this more.

--Sandy