Practical to use WinRM from outside NAT and hardware firewall?
CodeSlinger
Am I able to use WinRM/WinRS from outside a hardware firewall to run commands
on machines located behind NAT and a hardware firewall? From outside the
firewall, I want to be able to run Powershell commands or WinRS on machines
inside the firewall and using NAT and not just for the one machine that might
have http port 80 open and forwarded from the router/firewall but for any of
the machines behind it. Is there some other recommended way to do any
management from the "outside"? Thanks, Dave
Marco Shaw [MVP]
the ability to use any encrypted communications and may have to go with
plain text, which won't be secure.
In such a scenario, the way I might architect this is to put a server in a
DMZ, to accept and somehow pass commands to internal machines...
Marco
"CodeSlinger" <CodeS...@discussions.microsoft.com> wrote in message
news:45EC4164-44F1-43EF...@microsoft.com...
Joe Morris
> "CodeSlinger" <CodeS...@discussions.microsoft.com> wrote:
>> Am I able to use WinRM/WinRS from outside a hardware firewall to run
>> commands on machines located behind NAT and a hardware firewall?
>> From outside the firewall, I want to be able to run Powershell
>> commands or WinRS on machines inside the firewall and using
>> NAT and not just for the one machine that might have http port 80
>> open and forwarded from the router/firewall but for any of the machines
>> behind it. Is there some other recommended way
>> to do any management from the "outside"?
>I don't know to tell you the truth. At the very least, you'll likely lose
>the ability to use any encrypted communications and may have to go with
>plain text, which won't be secure.
> In such a scenario, the way I might architect this is to put a server in a
> DMZ, to accept and somehow pass commands to internal machines...
Unless the OP (or the OP's employer) is willing to invest quite a bit of
effort into the design and operation of the network I think that the answer
is "no."
In detail, somewhat simplified (and upon further review, admittedly a bit
rambling...):
I disagree with the comment "you'll likely lose the ability to use any
encrypted communications." Encryption can take place at many levels; in
most civilian environments the need for encryption is the section of the
network where traffic passes across the public Internet between two
physically secure endpoints. The encryption mechanism doesn't have to have
any knowledge or connection to the software that generates or receives the
payload (IOW, it doesn't have to be at the application layer), so the fact
that POSH being used isn't relevant.
Example: at my house I have a commercial encrypting appliance to which I
connect my company laptop. All communications with the company's network are
protected by a very robust encryption algorithm, but my laptop is sending
its communications in cleartext, unaware that there's an encrypted link
between my house and the company network where the traffic emerges from the
VPN concentrator in cleartext again.
Getting to systems behind a firewall should be relatively easy if the
firewall was properly designed (which is not necessarily the case for
consumer firewall products). Identify the protocols to be used and the
(fixed, not dynamic) IP addresses of both endpoints, then create a rule to
allow that traffic to pass inbound and deny all other.
The NAT issue is a problem, since a NAT device works by translating the
internal IP addresses (almost always in the private address space
192.168.x.x/16 or occasionally 10.x.x.x/8) into a random port on the
external (single) IP address. A state table entry is created when an
internal endpoint initiates a connection to an external endpoint, mapping
the internal IP and port to the (randomly selected) external port number to
allow a response from the distant endpoint to be re-mapped to the
appropriate internal address and port. There's typically no mechanism to
permit externally-initiated traffic to communicate with an internal
endpoint.
Note that a private IP address can never be used as a source or destination
address for a packet on the Internet. As its name implies it's intended to
be used only on a private network; that's why your typical NAT device uses
192.168.x.x/24 addresses.
This problem is why many NAT boxes have a DMZ option that allows incoming
traffic to specific port(s) to be redirected to a particular IP address on a
dedicated network cable. This would avoid the NAT issue, but in the process
of doing so it opens the DMZ machine to attack from any of the far-too-many
criminals who search the network for vulnerable systems.
Putting a machine on the DMZ connection and using it as a bridge to the
machines on the NAT-serviced network would require not only providing the
hardware but also writing AND MAINTAINING the software to manage the
forwarding. This isn't an insurmountable issue, of course, but if security
is a concern (and it should be, regardless of the size of the network) it
raises lots of problems if the DMZ system is not completely secure. Hack
into the bridge machine and you've got access to the servers on the NAT
side.
An alternative would be to use a VPN. Connect the low side of a VPN server
to the DMZ connector of the target network's firewall and the high side to
the network where the target servers are located, then from the endpoint
from which the OP wants to run the commands open the appropriate VPN client
and establish a connection before issuing the control commands. The result
is that the distant (control) endpoint will effectively be sitting on the
internal network on which the target servers are located and can assess them
directly, bypassing the NAT device. In turn, however, this requires that
there be some mechanism to authenticate both the distant endpoint and the
individual operating that endpoint. It also assumes that the VPN server
itself is secure, and that the sysadmin for that server knows how to make it
secure and keep it that way.
The OP did not provide (and probably should not have provided) any
information about the organization whose servers s/he wants to manage, so
there's no way for us to determine the degree of security that's appropriate
for the systems involved. If the plan is to allow an external endpoint to
control the internal servers, this should be briefed to the organization's
management with a clear description of the security issues that it
introduces into the network, and the decision *by management* to allow it to
be implemented should be clearly documented in writing, laying out what
changes are to be made and what intrusion monitoring procedures are to be
followed to detect successful or unsuccessful attacks.
Joe Morris
Marco Shaw [MVP]
> encrypted communications." Encryption can take place at many levels; in
OK, agreed. I was thinking one thing, but wrote another. I should have
said something along the lines of "possibly losing all WinRM built-in
encryption in such a scenario".
Marco
Joe Morris
I suspected that was the intent, but since I don't know the technical
sophistication of the OP I wanted to explain my reasoning for the
disagreement and give an example. I hope that didn't come across as jumping
on your response (at least not *too* hard; I tend to be professionally
paranoid about security issues <grin>).
But note that if you insert a VPN into the data path to provide the link
security across the Internet, the tunnel should be invisible to the packet
flow between the control system and the target servers, meaning that the
WinRM encryption would be unaffected...although that still leaves the issues
of authentication, authorization, and auditing to be addressed.
Joe
CodeSlinger
Marco, Joe,
Thanks for the explanations and suggestions. I have an application with
multiple agent computers, a server they talk to and one or more management
consoles that monitor everything and all normally run completely inside but
with WCF I am able to place the server or console components outside the
firewall. All works fine except that the console cannot run commands against
the agent machines using winrm or psexec as it normally can from the inside.
Given your responses, I think I will recommend that for now the console
application that would run such commands stay on the inside and some sort of
RDP be used from outside.
I wish the "Notify me of replies" worked. Is there some trick to having the
discussion group do this when a post get a response?
Thanks, Dave
Marco Shaw [MVP]
> I wish the "Notify me of replies" worked. Is there some trick to having
> the
> discussion group do this when a post get a response?
Hmmm... I don't know if that even works. Might be best to go and setup a
search engine alert perhaps.
Marco
Joe Morris
> with WCF I am able to place the server [...] outside the firewall.
Again putting on my security hat: please don't even *think* about putting
your servers directly on the internet with no firewall. It doesn't matter if
they're running Windows, MacOS, Linux, or Magic Blue Smoke (tm): they have a
vulnerability somewhere, and the nasties will find it if given half a
chance.
This isn't to say that the servers must be behind the normal company
firewall, but they do need to be protected by blocking any unnecessary
access paths, both inbound and outbound. Look at the applications that are
running on the servers: what protocols are *really* necessary for the server
to do its job? Whoever is responsible for the server (perhaps you) should be
able to generate a list for both its general functioning and for
communications with your command console (using a fixed IP address for the
command console, preferably on a different NIC than the one connected to the
Internet).
Don't forget to block access from any of your servers to any other
DMZ-resident device. That way if one is somehow compromised it can't be used
as a springboard into the others.
Google for "DMZ Firewall Rules" for some guidance on this. A good example is
given by an IBM site:
Be hard-nosed about writing the firewall rules and close off *every* access
unless someone can clearly document a need for it. This may make you a bit
unpopular for a while, and it's hard to show that your actions meant that
something nasty didn't happen (example: some people still say that the Y2K
problem [*] never existed because no catastrophe happened...idjuts) but
management, if it's got any brains, will (eventually) thank you for keeping
your company's name off the front page of the local newspaper's story about
computer intrusions.
And don't assume that *anything* is automatically safe. It's interesting
how much information can be obtained by carefully examinging how a system
responds to unsolicited traffic, even if that response is "go away."
We now return you to postings about POSH, already in progress.
Joe
[*] Happy Y2K+10 anniversary!
Charlie Russel - MVP
"Notify me of replies" has been broken for a while. (And isn't something
most of us using an NNTP reader even see.) I know MS is aware of the issue,
but haven't seen a timeline for a fix, I'm afraid.
--
Charlie.
http://msmvps.com/blogs/russel
"CodeSlinger" <CodeS...@discussions.microsoft.com> wrote in message
news:338CE763-AB1E-4A27...@microsoft.com...
joeroc
permit encrypted connections over port 443 & setting up CAP (client access
policies) & RAP (resource access policies) to determine who can connect and
to what resources. You could then connect to an internal machine using RDP
and run winrm from there.
I also agree with Joe in that no machine should be placed on the internet
without locking it down to required services only and then somehow protected
with an additional firewall...and even then the service itself might be
vulnerable.
CodeSlinger
perspective of my agent computers inside their firewall. The Manager/server
machine the agents talked to would be outside the agent's firewall but behind
it's own firewall somewhat like a web server perhaps using TCP port sharing
and yes would be locked down except for this application. I'm a developer and
don't always know the IT and security stuff in detail so very much appreciate
your detailed comments as that gives me plenty to think about and learn and
and suggest how folks should use and configure the software I am developing
rather than setting it all up myself. Happy 2010 and thanks, Dave
CodeSlinger
home so can test this unless I can get someone else to set that up for me to
test with so I don't have to expose my development server to the outside
meanies. WinRM/WinRS is already locked down pretty tight for using within my
workgroup at home so I agree not very feasible to let WinRM straight in and
as suggeted it makes a lot more sense to come in with RDP/TS and use WInrm
once inside. Dave