PowerShell For Fun

Any remote shell application is dangerous because you open a door to outside world. So does PowerShell Remoting. Previous version of PowerShell Remoting totally depended on NegotiateStream. You have no control of login process or you can not limit user access.  So anyone with a valid local or domain account can login remotely into your computer. As more and more people began to download and install PowerShell Remoting on their computer, I decided to add client access control policy to PowerShell Remoting.

Firstly, you should limit maximum number of clients which can connect to server simultaneously. This is done by modify registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
"MaxClient"=dword:0000000a

Default value is 10. Given 256MB memory is standard configuration for desktop PC, this number is more than enough if you decided to login to your desktop from home network. You can definitely increase this number if you have more clients but remember each runspace will allocate quite a few of memory. So do some experiment and calculation then you can find a reasonable number.

Secondly, you should limit maxium number of clients which can connect to server simultaneously from Same IP address. This is done by modify registry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PowerShellRemoting\Parameters]
"MaxClientPerIP"=dword:00000002

Default value is 2. You can also change that but you don't want all your available slots of connection were occupied by clients from same computer.

Thirdly, you may want to limit which user can login from which IP address. This is done by modify
%Program Files%\PowerShell Remoting\user.xml
Default installation only allow user in Administrators group login from localhost. So you have to have your own user.xml before you can login from another IP. If user.xml file parse error occorred when start service, default policy will be loaded. If you can't login, check log file or EventLog for details of parse error.
User.xml file contain information about your user access control list. It has SEVEN tags:

1. <NetworkACL>: container of one or more access control entry (<NetworkACE>)
2. <NetworkACE>: access control entry container of <Account>, <Access> and <IPRange>
3. <Account>: Valid Group or User
4. <Access>:  Allow / Deny
5. <IPRange>: container of <IP> and <Subnet>
6. <IP>: IPAddress. 0.0.0.0 for any IP, 127.0.0.1 for localhost, 192.168.0.2 etc. IPv6 string should be fine, but I have not been able to test it.
7. <Subnet>: IPv4 subnet. 192.168.0.0/255.255.255.0 or CIDR like format 192.168.0.0/24.

Within <NetworkACE> and </NetworkACE> tags, order matters.

1. <Account>
2. <Access>
3. <IPRange>

Within <IPRange> and </IPRange> tags, <IP> and <Subnet> can be used in any order.
As you can probably already figured it out : After user provide credential and got a token (WindowsIdentity), PowerShell Remoting will try to match User/Group and IP range in records of access control list. If no record was found, access is denied. If a records match User/Group and IP range were found, PowerShell Remoting will assess access in following order:

User Deny > User Allow > Group Deny > Group Allow

For example: if client were a privileged user (Administrators group) from 192.168.0.2, but there were only one record which wanted to deny access of Users group from subnet 192.168.0.0/255.255.255.0. Then access from this client will be denied because any user belongs to Administrators group also belongs to Users group and 192.168.0.2 belongs to subnet 192.168.0.0/255.255.255.0.

After you logged in and get a PowerShell prompt, you can check $UserACL for serialized access control list.

Right now, subnet parsing and match could be buggy. So tell me if you found it did not act as expected.

These changes could make it more difficult to start using PowerShell Remoting. But I believed that you will like them later on. Remember, if you make any changes to previous setting, you will have to restart service to make them take effect.

Stop-Service PowerShellRemoting
Start-Service PowerShellRemoting

There is also some exciting new feature:

1. PowerShell Remoting Client becomes a PSSnapin now. So installation become usier. Just run install.ps1 in client folder and invoke Start-RemoteHost, you are on you way to your remote shell.
2. Ctrl+C Ctrl+Break support.
   
Try

dir c:\windows\system32


And press Ctrl+C to cancel it. If you don't want to handle Ctrl+C, you can set


$RemotingClient.CanHandleCancelKey = $false


But you probably do not want to do that.
Ctrl+Break will also quit PowerShell Session. So Use it with caution.


3. You will find out that information written in log file has been dramatically reduced because I am going to swith to EventLog in later verion.

I can actually run PowerShell Remoting Client with in PowerShell Analyzer. But its ReadLine popup window really bothers me.

Tags: msh    monad   PowerShell