Re: Stand Alone DHCP Servers and Windows 2000

On our network the clients are allowed to talk to the domain controller
using just these:

DNS
Kerberos Sec (TCP)
Kerberos-Sec (UDP)
LDAP
LDAP (UDP)
Microsoft CIFS (TCP)
NTP (UDP)
RPC (all Interfaces)
[ maybe one more variant on the above, not sure right now.... ]

No NetBIOS here thank you very much. And yes you are right it is hellishly
hard to get rid of NetBIOS but we forced ourselves to live without it and to
fix whatever breaks without it to not use it. We used the firewall to have
the existing NetBIOS network continue to work as always, then we created new
client segments that use the far more restrictive ruleset. We migrate
each computer one at a time from the insecure segment to the secure one.

While I understand the huge pain that a firewall in the middle of the LAN
would cause most admins, once you go through the huge initial learning curve
and figure out how to make Windows work with just the above protocols, what
you end up with is a far more secure network. And the firewall is there to
*force* you to play by certain restricted protocol rules. Once we got
through the learning curve, I am here to tell you it works extremely
reliably, and I feel really empowered both by a better understanding of how
the different pieces are interacting, and by the ability to finely control
which segments and which computers use specific protocols.

I will say in defense of your point that it took us *months* to figure out
the internals of RPC well enough to be able to restrict inside the protocol
which RPCs can execute through the firewall, and I came away from that
pretty scared at how disorganized and random Microsoft's use of different
RPC services seems to be. If you can live with all RPC (what ISA Server
2004 calls "RPC (All Interfaces)" ) then inserting a firewall between the
client and domain controller is very doable as long as it is done in a way
that lets you slowly migrate each machine from an insecure existing network
to a new segment that is more secure.

I also will say in your defense that most admins spend so much time just
keeping the mess which is computing today working at all, that there is not
a lot of time to think about ideals like building a secure internal
infrastructure. Probably not a lot of managers would support the activity
either.

--
Will



"Phillip Windell" <@.> wrote in message
news:ur$7GUEgGHA.3860@xxxxxxxxxxxxxxxxxxxxxxx
4) You can enforce restrictions against the old style NetBIOS calls
(137)
by
forbidding access on those ports at all.

Only in a "perfect world". The are still too many applications that
require
NetBios to function. In my experiments with software on our LAN that must
have uptime of 100%, these are the protocols that are required. I have
verified them by not allowing them and having things fail. I spent several
days verifying these using ISA2004 as the "firewall" with a "routing"
relationship between the segments. Using a "nat" relationship would have
been nearly impossible because many of the protocols required
bi-directional
travel.

These were needed across all users:................
HTTP, HTTPS
FTP
NNTP
DNS
Kerberos Sec (TCP)
Kerberos-Sec (UDP)
LDAP
LDAP (UDP)
Microsoft CIFS (TCP)
NetBios Datagram
Netbios Name Service
Netbios Session
NTP (UDP)
Ping
RPC (all Interfaces)

These were needed for certain users:.................
6341 TCP (proprietary)
2638 TCP (proprietary)
8000-8003 TCP (proprientary)
RDP (Terminal Services)


As a comparison, these are the only protocols allowed Outbound at the
network "edge".
HTTP/HTTPS
FTP
NNTP
(SMTP, POP3 are not used or allowed)

So.
By the time you account for all these protocols and "allow" them at a
firewall in the middle of the LAN, there really isn't any point in having
the firewall there to begin with.

--
Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com
-----------------------------------------------------
Understanding the ISA 2004 Access Rule Processing
http://www.isaserver.org/articles/ISA2004_AccessRules.html

Troubleshooting Client Authentication on Access Rules in ISA Server 2004

http://download.microsoft.com/download/9/1/8/918ed2d3-71d0-40ed-8e6d-fd6eeb6cfa07/ts_rules.doc

Microsoft Internet Security & Acceleration Server: Guidance
http://www.microsoft.com/isaserver/techinfo/Guidance/2004.asp
http://www.microsoft.com/isaserver/techinfo/Guidance/2000.asp

Microsoft Internet Security & Acceleration Server: Partners
http://www.microsoft.com/isaserver/partners/default.asp

Deployment Guidelines for ISA Server 2004 Enterprise Edition

http://www.microsoft.com/technet/prodtechnol/isa/2004/deploy/dgisaserver.mspx
-----------------------------------------------------





.

Relevant Pages

  • Re: Kerberos UDP vs TCP
    ... The main reason for using UDP by default is that it's lightweight compared ... UDP starts having problem if the network is not reliable, i.e. busy network, ... slow links, or has packet loss. ... The advantage of using TCP is that it uses ...
    (microsoft.public.security)
  • Re: Kerberos UDP vs TCP
    ... Various network devices and improperly configured network cards are what I most often see screwing up the UDP packet delivery. ... TCP does add a good amount of overhead and I would recommend doing a network impact study before considering switching whole hog to TCP. ...
    (microsoft.public.security)
  • Re: Log Out Issues
    ... > I would be quite happy to use TCP to save headaches, ... > ive read during my learning, UDP is the way to go for internet games. ... UDP is faster, in this context, mostly because it doesn't care so much about ... If the network has a little hiccup, and you're using UDP, all that happens ...
    (microsoft.public.win32.programmer.networks)
  • Re: logging in but then loss of domain connection
    ... > It sounds like the workstation is unable to find the Domain controller. ... > happens if you connect the laptop to the network using a network cable? ... We have seem issues whereby the UDP ... > Kerberos to use TCP by making a registry change. ...
    (microsoft.public.windows.server.sbs)
  • Re: UDP vs TCP
    ... If you could use TCP instead, you'd be far, far better off. ... Basically, TCP -is- UDP with all the error checking, retransmission of lost ... This is why FTP, HTTP, and most every other protocol are packed ... protocols interacting with the TCP mechanisms. ...
    (microsoft.public.vb.enterprise)