Re: Automate Connection Access
- From: "Sanford Whiteman" <swhitemanlistens-software@xxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 10 Apr 2007 22:37:51 -0400
On Sun, 01 Apr 2007 14:54:02 -0400, NetFodder <NetFodder@xxxxxxxxxxxxxxxxxxxxxxxxx> 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 what you're doing. Sworn? Good.
Anyway, IIS exposes the Connection Control list via the Metabase property `IPSecurity.` Unlike many other props, even with direct Metabase editing enabled, though, you can't easily automate the editing of metabase.xml for this property, because it is of the binary data type IPSECLIST rather than 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=GetObject("IIS://localhost/smtpsvc/1") 'ADSI IIS namespace
objSMTPServer.getinfo
set objIPSec = objSMTPServer.get("IPSecurity") 'target metabase property
arrHosts=objIPSec.IPDeny 'read current list into temp array
redim preserve arHosts(ubound(arHosts) + 1) 'extend temp array length by 1
arrHosts(uBound(arrHosts))="1.2.3.4,255.255.255.255" 'add new IP at the end
objIPSec.IPDeny=arrHosts 'reserialize array back into metabase data type
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 offered 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 that the POP3 service was not very efficiently coded in general was surely part of the problem, but the fact remained that when the POP3 daemon had to use 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
.
- Prev by Date: Re: DNSReport.com connection failure
- Next by Date: Re: smtp gateway
- Previous by thread: Re: Automate Connection Access
- Next by thread: Re: SMTP fails despite SMTPDiag "Success"
- Index(es):
Relevant Pages
|
