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 20:25:09 -0800
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.htm#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
Other related posts:
