Re: [sbs list] FW: Last Word On The BlackAttacker.v bs Question

True, but that's actually a separate issue and doesn't fit into the chicken 
little scenario that's being discussed.
Actually, there was a recent rehash of the ICMP redirect tunneling in the 
securityfocus mailing list this week.
The fact is, this is almost as difficult to accomplish as "blind IP 
spoofing-spamming" that Tony describes.

The spoofing that Tony claims to expose your SBS Exch server is this:
- ISA 2000 locahost server publishing is routed via a virtual loopback object, 
causing all traffic to source from "127.0.0.1".
This is a design feature of ISA 2000 because it was the best way to "self-NAT" 
at the time.  Since then, better ways of 
accomplishing this have been worked out, but don't "fit into" the ISA 2000 
codebase.

While this behavior does make RBL filtering moot, it hardly "opens the server 
to localhost spoofing".
ISA will drop any packet that is sourced from 127.x.x.x that's seen on any ISA 
external interface and didn't come from the ISA 
itself; period.

..it's a non-issue doggie-bone that Tony just won't let go of.
I've received a response from him today that's even more "spooky" than his 
previous tirades.
I'll copy this list in my response to that one as well.

..even ISA admins deserve a good giggle once in awhile.
:-)

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

----- Original Message ----- 
From: "Troy Radtke" <TRadtke@xxxxxxxxxxxx>
To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
Sent: Friday, September 24, 2004 06:40
Subject: [isalist] Re: [sbs list] FW: Last Word On The BlackAttacker.v bs 
Question


http://www.ISAserver.org

Hi Jim,

I have to chime in on the spoofing part.  Distributed Reflected DOS attacks
have been performed.  Bounce a packet off of a remote machine with a spoofed
source IP and it replies back to the spoofed source.  Enough high speed
links being bounced off of by massive amounts of zombie machines have been
effective in (if I remember correctly only) two instances.  But, then again,
the fix was blocking return ack packets at the upstream from the source
since they were all coming in with the same port number.

No ISA config known would save you in that instance.  That's an upstream
provider fix.

Troy

-----Original Message-----
From: Jim Harrison [mailto:jim@xxxxxxxxxxxx]
Sent: Thursday, September 23, 2004 5:25 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] Re: [sbs list] FW: Last Word On The BlackAttacker.vbs
Question


http://www.ISAserver.org

Hi Tony,

Interesting statements, but dangerously misinformed and naive.

- Spoofed packets:
    The minute you think you understand what motivates the average haxor,
feel free to alert the authorities.  They've been trying
to sort that our for years.  It's also the single greatest confounder to Mom
and Pop InternetUser; "why would anyone try to hack me;
I'm nothing to them?"  The fact is, the motivation for the average script
kiddie is nothing more than "I did it!", or "see; haxor
mentor, I can own any machine I touch!".
    Your statements regarding how ISA determines "spoof status"  are
completely incorrect.  ISA uses the Windows routing table to
determine if a packet is being received is incorrectly sourced.  The LAT is
not part of the decision at all.  In fact, ISA
(correctly configured) properly recognizes spoofed traffic from within the
LAT as well.
    Regarding haxors spoofing their own source IP; that's silly.  Why would
they want to "spoof" an IP where they send the traffic
from?  Maybe a course in basic TCP/IP is in order here?  I wasn't trying to
illustrate what haxor Joe is going to do; just what's
possible with readily available tools, and thus in the hands of the script
kiddies.

- Alerts
    at least we agree on one point <g>.  I've seen many an ISA where
literally ALL of the available alerts were enabled on the basis
of "they created it; it must have a purpose".  I agree that the alerts might
have been better explained in the help, but ya gotta
ship a product sometime, and the docs always trail the code...

- Localhost (127.0.0.1)
    Nothing stated in the posting that motivated my recent response or any
previous communications we've had on this subject has
ever been "proven"; merely restated in the extreme; "I haven't personally
checked ", to quote you.  You're rehashing the tired old
"blind IP spoofing ISA SMTP server publishing vulnerability spamming threat
and a bag-'o-chips" that doesn't exist.  At no time has
any proof of concept been presented to anyone with whom you've expressed it.
So far, it's nothing but a paper basket full of rocks.
You do yourself a grave disservice by rechewing this old bone in a public
forum.  If you have anything to offer that can be
demonstrated either in a lab or live environment, then please forward it to
the proper folks.  What you choose to believe about a
vulnerability that, by your own admission, is nothing more than theory is up
to you, but until you or someone else does demonstrates
this in the physical world, my well-intentioned advice to you would be to
stop beating a dead (or unborn, to be more precise) horse.

Thx,

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


----- Original Message ----- 
From: "Tony Su" <TonySu@xxxxxxxxxxxxxxxxx>
To: <sbs2k@xxxxxxxxxxxxxxx>
Cc: <jim@xxxxxxxxxxxx>
Sent: Wednesday, September 22, 2004 14:48
Subject: RE: [sbs list] FW: [isalist] Last Word On The BlackAttacker.vbs
Question


I agree with everything but one point Jim says here,

And his warning about the downsides are all valid.

- I've seen the performance effects of "monkey code" running out of
process. If something like BlockAttacker was turned into a proper
tool/feature, of course it should be compiled code but as it is now it
can and will at times cause heavy loads. And, as some have noted before
(Jim can add this to his list of issues), the execution plan is faulty
because the process that launches BlockAttacker does not check for an
existing block first.

- Spoofed packets is a critical downside, which is why Blockattacker
should not be used anytime Internet Access is critical every second of
every minute of every day. This builds on the known issue that ISA's IP
spoofing detection cannot identify spoofed WAN addresses, it only
compares against the LAT. Still, the current state of hacking <today> is
that typically hackers believe or know that their targets are SysAdmins
who are either stupid or don't care. So, <today> (emphasis again) I
don't think anyone believes that hackers are spoofing their own source
addresses. Yes, if someone knows you are running BlockAttacker and how
it's configured, they can cause you to be blocked from essential network
resources (ie. DNS, DG, others) which probably makes more sense than
blocking the User's IPv4 block.

- As Jim says, what alerts you configure to trigger any action is
essential to what the consequences are, intended or otherwise.

- Jim might want to modify his comments about 127.0.0.1 if he recognized
what we've been saying on this List and has been proven... The
vulnerability might have been addressed in most situations (I haven't
personally checked but to a degree will take the word of others as
valid), but it's faulty. I suspect the Microsoft "fix" is to look
specifically for certain application processes instead of building an
entire layer which would have addressed all <unknown> applications as
well as known at the time it was designed. Regardless, the unexpected
faultiness is actually a benefit because once the vulnerability and
exploit are known, then we as SysAdmins can know to avoid it <and
similar situations>. In other words, am I to believe that the SMTP
exploit is restricted to SMTP only? Of course not. If the fix that's
supposed to work isn't working, anything similar is almost certainly
also potentially exploitable (which should be a real concern because the
practice of publishing Companyweb on port 444 <does> expose a
possibility although the actual ability to exploit and how is not
clear).

Tony Su




-----Original Message-----
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Tuesday, September 21, 2004 8:50 PM
To: sbs2k@xxxxxxxxxxxxxxx
Subject: [sbs list] FW: [isalist] Last Word On The BlackAttacker.vbs
Question


-----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


------------------------ Yahoo! Groups Sponsor --------------------~-->
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/dpFolB/TM
--------------------------------------------------------------------~->

As well you can find more info at http://groups.yahoo.com/group/sbs2k
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/sbs2k/

<*> To unsubscribe from this group, send an email to:
    sbs2k-unsubscribe@xxxxxxxxxxxxxxx

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/




------------------------------------------------------
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:
tradtke@xxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx

------------------------------------------------------
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: 
jim@xxxxxxxxxxxx
To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist
Report abuse to listadmin@xxxxxxxxxxxxx



Other related posts: