Windows 2000 Member servers behind a firewall
From: Daran Ward (daran.ward@steria.co.uk)
Date: 02/12/03
- Next message: Alex Contis: "How do I get the ip address of a computer involved in a logon/logoff event?"
- Previous message: Fox: "Changing Administrator PW"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Daran Ward" <daran.ward@steria.co.uk> Date: Wed, 12 Feb 2003 02:44:34 -0800
I am at the moment grappling with whether or not to place
a couple of member servers in a DMZ.
What I don't understand is why I need to open:
636 - why would I be running LDAP over SSL by default?
3268 - why is this needed in addition to 389?
3269 - again why would I be using SSL by default?
regards
Daran
>-----Original Message-----
>Connectivity from Windows 2000 Member Servers to
>An Active Directory Domain through a Firewall
>
>If you'd like to reply to me please remove the NOSPAM
part of my email
>address. I wrote this whitepaper because I had such a
tough time getting
>this work properly. I hope this saves you some time in
your
>implementation....
>
>There are many instances where a network administrator
may desire to have
>Windows 2000 member servers communicate to Active
Directory domain
>controllers (DC's) across a firewall. One common example
is when the member
>servers are on a DMZ segment and are deployed as world
wide web servers. In
>this scenario, the hosted website may require user
authentication against an
>Active Directory domain located on the internal network.
In such a scenario,
>there must be open communication channels in the
firewall for various Active
>Directory protocols and services.
>
>Microsoft has written two knowledge base articles (see
footnotes) that
>explain exactly what traffic is required, however I have
found that they are
>exceedingly liberal in the number of "required" port
openings. Ialso believe
>that these articles do not sufficiently contend with the
security
>implications of leaving a wide number of TCP and UDP
ports open on the
>firewall. However, in defense of the Q articles, if any
traffic is blocked
>that is otherwise stated to be left open, errors will
periodically populate
>the event logs, and some non-crucial Active Directory
related services will
>cease to function (that is, non-crucial depending on
your particular
>topology). These caveats will be discussed later in this
white paper. It
>should also be noted, that the Q articles fail to
indicate some required
>traffic components that need to be open; one notable
protocol that is absent
>from the articles is ICMP (i.e. the ping protocol).
>
>The fundamental security concern in following the Q
article's guidelines is
>that the firewall should be configured to allow perhaps
the most vulnerable
>of all protocols on a Microsoft network, that being the
Server Message Block
>protocol (SMB).In the scenario described above, if a
hacker were to
>compromise the www member servers, we would hope the
firewall could
>adequately protect the inside domain controllers from
being attacked.
>Unfortunately, if the Q articles are to be followed to
the letter, the
>inside servers would be open to SMB traffic, and the
hacker could easily
>start mapping drives, browsing network neighborhood, and
run commands that
>would enable him to gain an thorough understanding of
inside network
>topology. Opening SMB on a 2000 network is similar to
opening NetBIOS on a
>mixed mode or legacy NT 4.0 environment.
>
>This whitepaper serves to document the steps I took to
successfully
>implement Windows 2000 www member servers located in a
DMZ that authenticate
>to native mode Active Directory domain controllers on
the inside. Although
>Iused the Microsoft Q articles found in the footnote
below as a reference,
>Idid not follow them to the letter on the supposition
that opening NetBIOS
>and SMB traffic to the inside network is not a safe
computing paradigm.
>
>Required Ports:
>The Microsoft Q articles claim the following ports must
be open from the
>2000 member servers to the Active Directory Domain. The
following
>assumptions were made:
>
>* The traffic described in the table below is strictly
from the www member
>servers to the inside domain controllers
>* The domain controllers run DNS
>* The domain controllers are being used to synchronize
time with member
>servers via NTP
>* The domain is running in native mode (therefore the
NetBIOS protocol does
>not need to be allowed)
>* All IP traffic originating from the internal network
destined to the DMZ
>is inherently allowed
>* The www servers were running internal addressing, and
when they
>communicated to the inside servers, therer was no NAT
translations taking
>place. However, the firewall did NAT the servers to the
Internet, so that
>any user surfing the website was using the NAT'ed address
>
>Table 1
>Port Service
>123 (TCP) NTP Network Time Protocol
>135 TCP RPC Endpoint Mapper
>389 TCP/UDP LDAP
>636 TCP LDAP SSL
>3268 TCP LDAP GC
>3269 TCP LDAP GC SSL
>53 TCP/UDP DNS
>88 TCP/UDP Kerberos
>445 TCP SMB
>* ICMP Ping
>** 5050 TCP Active Directory logon and directory
replication interface
>
>* ICMP is not mentioned, however it is required if you
desire to not
>encounter any event id errors
>** Port 5050 is a statically defined port for Active
Directory logon. It is
>defined by adding a key to
> the registry.
>
>
>Registry Modifications:
>
>Member Servers
>The member server authenticate to the DC's via the
Kerberos protocol
>(typically over UDP). At times, the Kerberos packets may
exceed Ethernet
>specifications of 1500 kb. Some firewalls will not pass
such a large UDP
>packet. SonicWall happens to be one vendor in
particular. To overcome this
>issue, make the following edits to the registry on the
www member servers so
>that they use TCP for the Kerberos protocol:
>
>1. Start Registry Editor: regedt32.exe.
>2. Locate and then click the following key in the
registry:
>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\K
erberos\Parameters
> If the Parameters key does not exist, you
can create it now.
>3. On the Edit menu, click Add Value, and then add the
following registry
>value:
>Value Name: MaxPacketSize
>Data Type: REG_DWORD
>Value: 1
>4. Quit Registry Editor.
>
>Now make sure the www servers have their DNS pointed to
the interal DC's
>
>Domain Controllers
>This step is crucial for any domain controllers that you
are allowing the
>member servers to authenticate against. The port is used
for the Active
>Directory logon and directory replication interface (see
table 1). It is not
>necessary to make this registry modification to any
other DC's in the
>forest.
>
>1. Start Registry Editor (Regedt32.exe).
>2. Locate the following key in the registry:
>3.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\
Parameters
>4. On the Edit menu, click Add Value, and then add the
following registry
>value:
>5. Value Name: TCP/IP Port
>Data Type: REG_DWORD
>Radix: Decimal
>* Value: 5050
>6. Quit Registry Editor.
>
>* Please note, 5050 is a port that we have chose, in
reality any unused port
>over 1024 is acceptable, as long as the firewall is
modified accordingly
>
>Recommendations for additional security:
>
>Table 1 above lists that TCP port 445 and the ICMP
protocol should be left
>opened. TCP 445 is the SMB protocol, which essentially
leaves your inside DC
>'s susceptible to numerous well known attacks. The
reason Microsoft claims
>this port need to be opened is so the member server can
download group
>policy pol files periodically from the sysvol of the
domain controller that
>authenticated it. We have successfully closed these
protocols on our
>firewalls. The caveat is that if any changes are made to
the default domain
>group policy (or any other GPO), the member servers will
not be able to
>download it and process its settings. Also, the event
log will periodically
>fill with the following error:
>
>This userenv 1000 error is due to the fact that the
member server is trying
>to ping the inside DC to determine what speed connection
it has to it. If
>the ping does not go trough (because we are blocking
it), this error pops up
>approximately once every two hours.
>
>If we allow ICMP, but do not allow SMB, a different but
similar userenv
>error will populate the logs, but the end result will be
the same: the GPO
>will not be able to be downloaded.
>
>Typically on www bastion servers, we are not overly
concerned with accepting
>GPO's from the domain controller. It is our belief
that , the periodic event
>log errors are a small price to pay to know that the
inside DC's remain
>safe from SMB related attacks.
>
>
> Footnote:
>1 Q179442 How to Configure a Firewall for Domains and
Trusts
> Q280132 Exchange 2000 Windows 2000 Connectivity
Through Firewalls
> Q244474 How to Force Kerberos to Use TCP Instead of UDP
>
>
>
>
>
>
>
>
>.
>
- Next message: Alex Contis: "How do I get the ip address of a computer involved in a logon/logoff event?"
- Previous message: Fox: "Changing Administrator PW"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
