RE: Updates from the Least Privilege Front

  • From: "Thor \(Hammer of God\)" <thor@xxxxxxxxxxxxxxx>
  • To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
  • Date: Tue, 6 Dec 2005 21:27:24 -0800

Inline:

This seems like a reasonable assessment to me. However, I don't
completely trust what comes in from any DMZ, whether it be anonymous or
authenticated access. I especially don't trust anonymous access DMZs, as
they're essentially extensions of the "external" (unmanaged by me)
network.  In the article that went up today, you'll see that I use a
Server Publishing Rule from External to anonymous DMZ SMTP server, and
then another Server Publishing Rule to publish the Exchange Server on
the default Internal Network, so both connections get app filtered.

I knew you'd get up on your hind legs when I said "I don't agree with that" ;)
But in the above configuration, ATRN is not used. The described config is what I would recommend.


On the other hand, I trust the authenticated access DMZ a lot more,
since they had to use legit credentials to get in there. I do use Access
Rules from there to the default Internal Network because I get the HTTP
app inspection (same level as I would get with Web Publishing Rules).
Also, the DNS and POP3 filters work with both Access Rules and Server
Publishing Rules, IIRC (I better RC) so I'm covered there as well.

Agreed, to an extent. My personal preference for a "trusted authenticated DMZ" would include dual authentication mechanisms, but let's dispense with that detail and agree that, regarding whatever authentication mechanism one has in place, that traffic from authenticated sources are more trustworthy. The difference between this scenario and the ATRN scenario is that the originating traffic was sourced from an untrusted source-- SMTP traffic from anonymous sources queued for delivery is still un-authenticated whether you choose to authenticate the connection used from the internal network for delivery or not. One has to define an "authenticated access" DMZ by access rules required for external access, not those from the internal network.


That's a diff between ISA Server 2000 and 2004, in that app filters that
used to work only for Server Publishing Rules now are bound to both the
inbound and outbound Protocol Definitions. Nice ! (Jim pointed out that
tasty tidbit to me). However, the SMTP filter is an exception (IIRC).

Yes, it is an exception. You can define content types via the access rule from Internal to DMZ, but not the SMTP filter. That's my point. Since we're talking about SMTP, I'm not sure why you even bring that up, Old Man. ;)


I haven't deployed ATRN in this manner on any production network, but it
seemed like a cool feature. Of course, you'd have to create an account
on the anonymous SMTP server that isn't used anywhere else and has a
"random" password/phrase/paragraph/book, so that Rainbowing woudn't be
realistic and you'd need a Cray to crack it given enough time.

Well, since ATRN is subsequent to an SMTP AUTH, you won't have to worry about Rainbow Tables-- it's in clear text ;)


ATRN seemed like an interesting level of complexity, and I like complex
systems because they break more often and need fixing. They have the
advantage of confusing bad guys, but only if it doesn't confuse the good
guys deploying it :)

Totally- a fun level of complexity, but one that cannot be filtered in its deployment. Given that we both stipulate that filtering app-level traffic is better than full-pipe access, I believe that my main point stands.


I think I won.  Where's my "I PL0nK'd Shinder" T-Shirt??  :-ppppppppppppp

t


Laterz, GMT

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
**Who is John Galt?**



-----Original Message-----
From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx]
Sent: Tuesday, December 06, 2005 10:25 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Updates from the Least Privilege Front

http://www.ISAserver.org

A song comes to mind:

"Should SMTP ATRN, ATRN, ATRN?
There is no reason-  ATRN, ATRN, ATRN.
For this time there's a purpose, to the filter."

To the melody of the "Byrds" of course. ;)

IMHO, this is an example of "security guys" thinking too
much, immediately
followed by not thinking enough.  For one, this obviates the
SMTP filter
between the DMZ and the internal network.  If a back-to-back
config was in
place, maybe the FE filters SMTP, but that's not good enough.
 All traffic
from the DMZ to the internal network should be filtered through any
available app filter, regardless of what mechanisms verified
the data on the
front end.  I know you've talked about the FE "pre-verifying"
data, that
should then be trusted, but I don't agree with that-- not regarding
DMZ-sourced data that makes it way to the internal network.
The scenario of
"what if the DMZ server gets owned" is testament to this
rather than support
for ATRN.  If I root the box via some SMTP vector in the DMZ,
that vector
may also be available to the internal server- thus, modified
SMTP content
awaiting delivery would allow me to root the internal box over an
un-inspected-layer connection.  If I root the DMZ box via
alternate methods,
I then own a server that internal resources will soon come to with an
established connection that I can now use, unfiltered by any
app level
process, to highjack at will regardless of any SMTP
vulnerability.  I even
get to watch what authentication credentials are used to pull
the data,
which just might be usable in the internal network...

A published, filtered connection, in my mind, is a far better posture.

t




----- Original Message ----- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
Sent: Tuesday, December 06, 2005 7:47 PM
Subject: [isalist] RE: Updates from the Least Privilege Front



http://www.ISAserver.org

So that the anonymous access SMTP server only sends in
response to your
trigger. Some *security guys* (of which I wouldn't consider
myself, per
se) think this is a much more secure configuration. Check out
http://forums.isaserver.org/m_290005500/mpage_1/key_ATRN/tm.ht
m#29000550
0 and my general opinion, which is not the last word, of course.

Then there's this:
http://www.mailarchive.ca/lists/comp.mail.sendmail/2003-06/1016.html

Since the mail is sent over an established channel (initated by the
"internal" mail server), this removes the requirement of allowing the
anonymous DMZ SMTP server to initiate inbound connections over TCP 25.
So, if someone got control of the anon. SMTP server and tried to
initiate a connection over TCP 25, it wouldn't workie.

I have a packet trace of the ATRN process if you'd like to confirm.

How much security you gain is debatable, and you'd be better
equipted to
answer that question than I am.

HTH,
Tom

Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
**Who is John Galt?**



> -----Original Message-----
> From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx]
> Sent: Tuesday, December 06, 2005 9:19 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] RE: Updates from the Least Privilege Front
>
> http://www.ISAserver.org
>
> Why? What good is ATRN on an anonymous access inbound SMTP server?
>
>
> ----- Original Message ----- > From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
> To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
> Sent: Monday, December 05, 2005 8:43 PM
> Subject: [isalist] RE: Updates from the Least Privilege Front
>
>
> http://www.ISAserver.org
>
> Oh, and remember you want to use ATRN on your inbound SMTP relay :))
>
> Thomas W Shinder, M.D.
> Site: www.isaserver.org
> Blog: http://spaces.msn.com/members/drisa/
> Book: http://tinyurl.com/3xqb7
> MVP -- ISA Firewalls
> **Who is John Galt?**
>
>
>
> > -----Original Message-----
> > From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx]
> > Sent: Monday, December 05, 2005 9:57 PM
> > To: [ISAserver.org Discussion List]
> > Subject: [isalist] RE: Updates from the Least Privilege Front
> >
> > http://www.ISAserver.org
> >
> > Only Greg uses POP3 and IMAP4 ;)
> >
> > ----- Original Message ----- > > From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
> > To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
> > Sent: Monday, December 05, 2005 7:52 PM
> > Subject: [isalist] RE: Updates from the Least Privilege Front
> >
> >
> > http://www.ISAserver.org
> >
> > Whoa. Interesting stuff.
> >
> > So, the dreaded CIFS and RPC are only required for Exchange
> Management
> > console? That would indeed be sweet.
> >
> > And FE POP3 and IMAP4 works too? ;)
> >
> > Thomas W Shinder, M.D.
> > Site: www.isaserver.org
> > Blog: http://spaces.msn.com/members/drisa/
> > Book: http://tinyurl.com/3xqb7
> > MVP -- ISA Firewalls
> > **Who is John Galt?**
> >
> >
> >
> > > -----Original Message-----
> > > From: Thor (Hammer of God) [mailto:thor@xxxxxxxxxxxxxxx]
> > > Sent: Monday, December 05, 2005 9:37 PM
> > > To: [ISAserver.org Discussion List]
> > > Subject: [isalist] Updates from the Least Privilege Front
> > >
> > > http://www.ISAserver.org
> > >
> > > Just in case I forget (since we have been discussing FE
> > > Exchange Servers in
> > > a DMZ Segment) here is the skinny on the least privilege
> > > rules required to
> > > support the functionality outlined in Shinder's List.
> > >
> > > A Front End Exchange Server must verify a remote user's logon
> > > request,
> > > authenticate the local OWA access request in AD (based on
> > > NTFS perms), look
> > > up the Exchange Server hosting the user's mailbox in AD
> > > (global catalog),
> > > forward the user's credentials to the Back End Exchange
> > > Server required to
> > > log on to the BE on behalf of the user, and to finally proxy
> > > the web-based
> > > data to the end user. You also must be able to log into the
> > > FE server to
> > > administer the box, obviously.
> > >
> > > The protocol list required for all of this functionality is
> > > as follows:
> > > From the OWA FE server in the DMZ Segment to the Domain
> > Controllers--
> > > DNS
> > > Kerberos-Sec (UDP)
> > > LDAP
> > > LDAP (UDP)
> > > LDAP (Global Catalog)
> > > Ping (Not required, but helpful)
> > > Microsoft CIFS (TCP)
> > > RPC (All Interfaces)
> > >
> > > From the OWA FE server to all BE servers, you must allow:
> > > HTTP
> > >
> > > Note that all manner of NBT traffic requests were attempted,
> > > but these are
> > > apparently not required when the other protocols are allowed.
> > >
> > > Now, one may be tempted to have a single rule for DC
> authentication
> > > containing these rules, and a single HTTP rule from the FE to
> > > all BE servers
> > > on the Internal Network, but that is not how I recommend
> > > doing it in a
> > > "least privilege" environment.
> > >
> > > I have a problem with allowing CIFS and RPC from a DMZ asset
> > > to my internal
> > > Domain Controllers. I also like peanut butter rolled up in a
> > > slice of
> > > Bologna-- I call it a "trailer park crepe." But I digress.
> > >
> > > In my tests, CIFS and RPC were only necessary for console
> > > logon to the FE
> > > asset. If you were logged out of the FE server yet remotely
> > > accessed the FE
> > > facilities via OWA, CIFS and RPC were *not* required. If the
> > > FE thinks it
> > > has CIFS and RPC, it will use it for FE functions (in my
> > > tests). But if you
> > > do not allow it, LDAP, Kerberos-Sec to the DC's and HTTP to
> > > the BE's will
> > > ultimately be used. The first time a user does this, it
> > > takes a bit for the
> > > auth to complete, but after that, it's superfly.
> > >
> > > Given that, I have decided to separate auth into 2 rule sets:
> > > One from the FE server to the DC's with all the above minus
> > > CIFS and RPC,
> > > and one from the FE server to the DC's with CIFS and RPC.
> > > The trick is to
> > > disable the second auth rule until you need to log on the to
> > > console of the
> > > FE server. This way, you allow full OWA functionality
> > > without having to
> > > have evil CIFS and RPC open from that DMZ segment into
> your Internal
> > > network.
> > >
> > > More later.
> > >
> > > t
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------
> > > 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
> > > ------------------------------------------------------
> > > Visit TechGenix.com for more information about our other sites:
> > > http://www.techgenix.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
> > >
> > >
> >
> > ------------------------------------------------------
> > 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
> > ------------------------------------------------------
> > Visit TechGenix.com for more information about our other sites:
> > http://www.techgenix.com
> > ------------------------------------------------------
> > You are currently subscribed to this ISAserver.org Discussion
> > List as:
> > thor@xxxxxxxxxxxxxxx
> > 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
> > ------------------------------------------------------
> > Visit TechGenix.com for more information about our other sites:
> > http://www.techgenix.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
> >
> >
>
> ------------------------------------------------------
> 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
> ------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.com
> ------------------------------------------------------
> You are currently subscribed to this ISAserver.org Discussion
> List as:
> thor@xxxxxxxxxxxxxxx
> 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
> ------------------------------------------------------
> Visit TechGenix.com for more information about our other sites:
> http://www.techgenix.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
>
>


------------------------------------------------------
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
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.com
------------------------------------------------------
You are currently subscribed to this ISAserver.org Discussion
List as:
thor@xxxxxxxxxxxxxxx
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
------------------------------------------------------
Visit TechGenix.com for more information about our other sites:
http://www.techgenix.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



------------------------------------------------------ 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 ------------------------------------------------------ Visit TechGenix.com for more information about our other sites: http://www.techgenix.com ------------------------------------------------------ You are currently subscribed to this ISAserver.org Discussion List as: thor@xxxxxxxxxxxxxxx To unsubscribe visit http://www.webelists.com/cgi/lyris.pl?enter=isalist Report abuse to listadmin@xxxxxxxxxxxxx




Other related posts: