<(E-Mail Removed)> wrote in message
news:c2c2b9ad-1e0d-4a58-8bcc-(E-Mail Removed)...
On Mar 12, 2:46 am, "Will" <westes-...@noemail.nospam> wrote:
> "Juergen Kluth" <jkl...@t-onlinr.de> wrote in message
>
> news:u$KssK%(E-Mail Removed)...
>
> > If u look to secure to network,
> > i would think only elementary services should be reachable via internet
at
> > all (a web server for instance)
> > there may be enough ways to access ur dhcp server via vpn.
>
> There is no vpn. There is no Internet access. I'm referring to
> management of the DHCP server by machines behind our firewall only.
>
> I cannot control when someone goes to a bad website and downloads an
Active
> / X that compromises their computer. The computer behind our firewall that
> I trusted yesterday might today become a drone doing work for someone
> outside our network. The worst threats usually come from inside your
> networks, from computers you were previously able to trust, that switched
> sides over night and became tools for the bad guys to use against you.
> It's easy to build a maginot line against the computer you knew was your
> enemy from day one. It's a much harder and more subtle thing from
> protecting against a computer you are supposed to trust.
>
> The most secure solution is one that locks the DHCP Server management port
> to a single fixed port location, and a firewall on the DHCP server that
> opens only that one port. Then if my client is compromised I have given it
> minimal attack surface on the computer it has direct access to. If I
expose
> a range of dynamic ports, the compromised client with RPC access can use
> (and attack) *any* code running as a server on the computer that uses a
> dynamic RPC port. It can in many cases install a trojan on the target
> computer by writing a viral payload to a shared file system and then send
a
> service start command to the targeted computer. I lost 60% of the servers
> in my DMZ and not a small number internally from a single trojan that did
> exactly that, so for me this is no longer a very theoretical subject.
>
> Based on the lack of response I am gathering that the Windows 2003 DHCP
> Server Management port cannot be locked down to a fixed location and must
be
> left dynamic.
>
> --
> Will
>
>If it's security that you are worried about and clients on your
>network that you can't trust, then why don't you look at locking down
>their machines and quit trying to reinvent the wheel? You can control
>whether or not a client can download ActiveX via Group Policy. Matter
>of fact, you can do just about anything, from a security standpoint.
Minimizing the attack surface of a server *IS* locking the machine down.
It isn't reinventing the wheel. It's the single most important aspect of
security on any server. The smaller the number of things that an attacker
can probe, the smaller the chances of his finding an exploit. It also
creates lower administrative burdens by minimizing the number of things you
need to strictly administer and configure. Minimizing attack surface is a
key design goal in Windows Server 2008, where Microsoft finally "gets it"
and provides widespread support for lowering the number of active services
that can be attacked. So I do not accept that this is a wrong principle,
or misguided, or that it involves my inventing any concept. I'm just doing
what is at the foundation of any solid computer security design.
It's also a good idea to configure higher level abstractions like group
policy. But that's not mutually exclusive of minimizing the number of
services that can be reached on the target computer. It's like I am asking
for a bullet proof window and you keep trying to get me to upgrade the tires
and engine and hire a security service. You are talking about a different
subject, and it's a worthwhile activity, but it is a different thing.
>And the article that was linked to you originally:
>
>http://support.microsoft.com/kb/154596/en-us
>
>Explicitly states:
>
>You should open up a range of ports above port 5000. Port numbers
>below 5000 may already be in use by other applications and could cause
>conflicts with your DCOM application(s). Furthermore, previous
>experience shows that a minimum of 100 ports should be opened, because
>several system services rely on these RPC ports to communicate with
>each other.
Microsoft - by necessity - has to write documents that can be understood and
used by the mass audience of computer users. So the document you
reference above is about how to easily raise security maybe another 30%
without breaking any other services.
Locking individual servers down on separate subnets behind a firewall is a
very difficult thing to do. That will break a lot of activities on the
server, and you need to understand a lot of different issues to recover a
server to a useful state of activity when you pursue that kind of
ultra-secure design. While it takes more time to set up the server this
way, it raises your security level by 90%. If for example you have a Mail
Server that exposes only the SMTP TCP port and nothing for management, and
allows only the required outgoing ports to DNS for authentication, etc, you
have a largely untouchable box. Unless someone finds a buffer overload
exploit in SMTP itself, they have no straightforward pathway into that box.
Even if they exploit an SMTP bug, where are they going to go with that box?
You have them locked out from any outgoing ports of interest. You have a
very high wall of defense around that box, and if they do break into the
box, the attacker has captured little of interest with not straightforward
mechanism to establish further attacks into other parts of the network.
Speaking of Microsoft documents that recommend opening ranges of RPC ports,
consider the Active Directory section of this knowledgebase:
http://support.microsoft.com/kb/832017/
Two years ago we set out trying to put our domain controller behind its own
dedicated subnet of an ISA firewall, and that required us to figure out that
there were three dynamic RPC services involved (NETLOGON, NT File
Replication, and AD Replication). As it turns out, Microsoft provided
registry keys for all three of those services to lock down their server
activity to fixed TCP ports. We were thus able to configure a firewall in
front of the domain controller to use only fixed ports - NO dynamic RPC at
all - and it just works beautifully. Yes, it was damn hard to figure it
all out. But it did work. No, it doesn't solve all of the security
issues with a domain controller. It's just one of many things to raise
security.
So for some services Microsoft was very throughtful and provided a way to
run them on fixed TCP ports instead of dynamic ones. I was simply asking
in this thread if the DHCP Server management port had a registry key to run
it on a fixed port. The answer to the question is apparently no. I
accept that, and yes I agree the thread should be closed.
--
Will
Similar Threads
Linear Mode
