RE: Last Word On The BlackAttacker.vbs Question

Hey Jim,

A classic! And I'll include it in this month's ISAserver.org newsletter.

BTW -- I think you cc:'d the isaserver.org list :-)

Tom
www.isaserver.org/shinder
Get the book!
Tom and Deb Shinder's Configuring ISA Server 2004
http://tinyurl.com/3xqb7
MVP -- ISA Firewalls



-----Original Message-----
From: Jim Harrison [mailto:jim@xxxxxxxxxxxx] 
Sent: Tuesday, September 21, 2004 6:56 PM
To: [ISAserver.org Discussion List]
Cc: [ISAserver.org Discussion List]
Subject: [isalist] Last Word On The BlackAttacker.vbs Question


http://www.ISAserver.org

(if you want me to see your reply from sbs2k@xxxxxxxxx, please 'r' me)

Hi all,

It's come to my attention that the once-proud BlockAttacker script is
once again the subject of deep discussion.
This script has been pulled from isatools.org (it never was on
isaserver.org) and it will not reappear on that site so long as I own 
/ run it.
It is no longer supported by me, Microsoft or anyone cooperatively
associated with either one of us.

This subject (and related script) has been abused, misused and
misunderstood for far too long.
It stops here and now.

Contrary to what you might have heard, this script was never intended
for anything more than an example of how to use environment 
variables in ISA 2000 alert actions.  As with any good deed, it has not
gone unpunished.

If you are using it for automatic "deny" policy creation, consider this:
1 - with the notable exception of SMTP Filter alerts (you're not using
it there, are you?  That would be silly in the extreme...), 
if ISA generated an alert based on the traffic from the remote host,
that traffic was also blocked.  Adding a rule to block traffic 
that is already silently dropped is a waste of processor time
(redundantly repetitive).

2 - Every time this script creates a new packet filter for a presumed
"attack on your property":
    a - it takes CPU time to create, update and save the changes; if
your script is creating rules as fast as someone can DoS your 
ISA with spoofed packets, then your firewall quickly becomes a network
brick.
    b - you complicate the ISA policy set.  Every rule in the ISA engine
takes processing time.  The fewer rules you have, the 
faster your ISA can process the traffic
    IOW, leave this monkey-script in place long enough and your ISA will
crawl to a halt.

3 - ISA can generate "attack" alerts on any number of packets that ISA
deems to be "out of context".  Most notably, these include 
(but are not limited to):
    1 - "late" packets; these are response packets arriving from a
server outside of the time ISA considers traffic from this host 
to be "valid".
        You'll usually see these when internal clients drop their
session before the server finishes the response stream.
        99% of the time, ISA will report these as "scans" and drop them
    2 - DHCP traffic from your ISP; even if you use static IPs, it's
very likely that someone in your broadcast subnet uses dynamic 
IPs.
        Will your ISA see these?  You betcha.
        Will it trigger on them?  Maybe; it depends on your
configuration and how many alerts you've enabled.
    3 - Real attacks using spoofed source IPs; here's the real danger.
        All it takes is one script-kiddie to slam your ISA with spoofed
packets from the entire IP v4 space and your ISA will no 
longer be functional in the Internet.  If you think this is hard to do,
you're fooling yourself.
    4 - There has been some discussion regarding:
        a - the value of blocking traffic from 127.0.0.1 and how your
ISA will lie bleeding to death on the floor from the "circle 
of death" resulting from such an attack.  The fact is, while ISA is
properly configured in Firewall or Integrated mode, this 
"attack" profile a non-issue.  ISA 2000 in Cache mode has no such
self-protection, so you should use a properly-configured 
packet-filtering router.
        b - the potential for blocking traffic from your own ISA server
is less than zero.  Any traffic seen at the external 
interface with a source IP of 127.0.0.1 is a spoof packet, period.  End
of discussion.   You should get mad at your ISP for allowing 
this to reach you, not some "think for me" script for not having a
"whitelist".

As always, I'm interested in feedback, but here is the final word:
"BlockAttacker.vbs is not a supported tool for any Microsoft product in
this, or any other lifetime in which I may be a member."

Anyone who wants to offer intelligent discussion on the subject will be
heard, and maybe even responded to in kind (of).
Anyone who wants to cry "foul" (no; wait, that's "spooooon!") will be
courteously (or not) ignored.

  Jim Harrison
  MCP(NT4, W2K), A+, Network+, PCG
  http://isaserver.org/Jim_Harrison/
  http://isatools.org
  Read the help / books / articles!


------------------------------------------------------
List Archives: http://www.webelists.com/cgi/lyris.pl?enter=isalist
ISA Server Newsletter: http://www.isaserver.org/pages/newsletter.asp
ISA Server FAQ: http://www.isaserver.org/pages/larticle.asp?type=FAQ
------------------------------------------------------
Other Internet Software Marketing Sites:
World of Windows Networking: http://www.windowsnetworking.com
Leading Network Software Directory: http://www.serverfiles.com
No.1 Exchange Server Resource Site: http://www.msexchange.org
Windows Security Resource Site: http://www.windowsecurity.com/
Network Security Library: http://www.secinf.net/
Windows 2000/NT Fax Solutions: http://www.ntfaxfaq.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion List as:
tshinder@xxxxxxxxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx


Other related posts: