Re: Attaching DHCP Server Management to Fixed TCP Port

<RemyMaza@xxxxxxxxx> wrote in message
news:c2c2b9ad-1e0d-4a58-8bcc-f982f32acfb1@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 12, 2:46 am, "Will" <westes-...@xxxxxxxxxxxxxx> wrote:
"Juergen Kluth" <jkl...@xxxxxxxxxxx> wrote in message

news:u$KssK%23gIHA.4712@xxxxxxxxxxxxxxxxxxxxxxx

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


.

Relevant Pages

  • Re: group opinion requested
    ... If you are not hosting your own website, you can close port 80 inbound. ... I and PSS didn't think it was copromised prior ... >> If you suspect a security issue, you can call the MS Security Team. ... They will check your server thoroughly. ...
    (microsoft.public.windows.server.sbs)
  • Re: Getting Data from behind a firewall.
    ... 1434 port is the port used in the Slammer worm. ... Any open port, even yes, a VPN connection can be a security risk. ... Just because you've only opened up the firewall for traffic from only that IP ... Security Baselines for setting up a server? ...
    (microsoft.public.sqlserver.security)
  • Re: Getting Data from behind a firewall.
    ... 1434 port is the port used in the Slammer worm. ... Any open port, even yes, a VPN connection can be a security risk. ... Just because you've only opened up the firewall for traffic from only that IP ... Security Baselines for setting up a server? ...
    (microsoft.public.security)
  • Re: sbs 2008 - no Internet access possible to 2nd server
    ... IIS can have security flaws and if your webserver gets compromised, it is better to have that server on its own network so the baddies don't get back to your LAN. ... I have had clients, in the past insist that I use the 'free' port forwarding setup. ... Agree with Larry that it is not a good practice to publish web site in the ...
    (microsoft.public.windows.server.sbs)
  • Re: hack using xp_cmdshell
    ... I'm no security expert, so please forgive if I'm not using the right ... install SQL Server in Windows Only mode and then Switch down to Mixed mode, ... Is the SQL Server instance a default instance? ... > port 65300, which has never been open on my firewall. ...
    (microsoft.public.sqlserver.server)
Loading