I was using Rapid7's Nexpose to scan one of our web servers (windows server 2008), and got a vulnerability for timestamp response.
According to Rapid7, timestamp response shall be disabled:
http://www.rapid7.com/db/vulnerabilities/generic-tcp-timestamp
So far I have tried several things:
Edit the registry, add a "Tcp1323Opts" key to HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters, and set it to 0. http://technet.microsoft.com/en-us/library/cc938205.aspx
Use this command: netsh int tcp set global timestamps=disabled
Tried powershell command: Set-netTCPsetting -SettingName InternetCustom -Timestamps disabled
(got error: Set-netTCPsetting : The term 'Set-netTCPsetting' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.)
None of above attempts was successful, after re-scan we still got the same alert.
Rapid7 suggested using a firewall that's capable of blocking it, but we want to know if there is a setting on windows to achieve it.
Thanks.
I will just try to explain why you are having the problem in PowerShell. Cannot speak to Nexpose part...
PowerShell is complaining because you do not have the modules required. Unfortunately, even though you might have the latest PowerShell version, you cannot have them on Windows Server 2008, because Microsoft ties them newer OSes. In other words, to be able to use that command, you would need to be on Windows Server 2012/R2/Windows8/8.1 etc... whichever OS the module that includes that CMDlet was released on.
Related
I have a script hosted on Windows 2016 server. This script is used by all IT teams.
Currently, to run the script, users use the following command:
powershell \\ServerName.mydomain1\Share\MyScript.ps1
Everything is working fine.
I would like to create a DNS alias like MyScript.mydomain2.
I can access to the server correctly ussing the alias. But, if I want to run the script using
powershell \\MyScript.mydomain2\Share\MyScript.ps1
it does not work. I've got an error told me I must sign the script.Â
If I use the serveur name instead alias, all is working. If I create an alias in the same domain than the server, all is working. If the alias is stored in another DNS domain, I've got the error.
The problem was the SPN on the server. Because an alias is used, a new SPN "HOST/MyScript.mydomain2" have to be added.
It workss fine now.
Thank you for your help,
Olivier
The new UNC path is not among the locations your systems trust for script execution. To resolve the issue you can either:
Sign the script.
Add \\MyScript.mydomain2\Share to the list of trusted locations (more specifically to the "Local Intranet" zone, e.g. via group policy). See the Scripting Guy blog for details.
Override the execution policy when invoking the script:
powershell -ExecutionPolicy Bypass -File \\MyScript.mydomain2\Share\MyScript.ps1
Beware that overriding the execution policy will only work if it isn't defined via local or group policies.
Trying to deploy some software that uses AppFabric in IIS. Yes, I already know AppFabric is deprecated; I didn't architect this software, so don't look at me! I also have the CU7 update for AppFabric installed.
I'm on Windows Server 2016 with IIS 10. No matter what I click on involving AppFabric in IIS, I get an error: The method or operation is not implemented.
Opening up the Event logs, I see that the method in question is a PowerShell commandlet: error running cmdlet 'out-lineoutput'. The method or operation is not implemented.
Out-LineOutput allegedly was introduced in PowerShell 5, and I've read that it only exists in regular PowerShell (not ISE). Beyond that, I haven't found any reference to that commandlet in regards to AppFabric.
What's driving me extra nuts is that I have a sandbox machine, also running Server 2016, where everything is working OK. I have confirmed that:
the PSModulePath environment variable is the same on both; and
running Get-Module at a Powershell prompt shows the same modules installed on both.
I've tried uninstalling/reinstalling AppFabric and the CU7 patch, adding my Application Pool Identity(ies) to the AS_Administrators group . . . nothing is working. Help me, Stack Overflow!
It turned out this was due to a registry key entry setting logging. In regedit, go to
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription
Check out the EnableTranscripting property. If this is a 1, change it to a 0.
On Windows Server 2012 Datacenter with Microsoft Dynamics CRM 2016 installed, I want to run a deployment command but for every commands I get this error: "(500) Internal Server Error".
I first run this:
Add-PSSnapin Microsoft.Crm.PowerShell
and it will work fine and when I check it with get-pssnapin and Get-Help *Crm*, every thing is fine and every thing that I need is registered. but when I want to run a cmdlets command like these, I face the error: Get-CrmSetting or Get-CrmCertificate or ...
For example for Get-CrmSetting TraceSettings it give me this error:
How can I solve this problem and error?
Thanks
According to this article, you might want to try:
Get-CrmSetting –SettingType TraceSettings
Here are a couple more items to investigate, from this article:
To use the XRM tooling cmdlets, you need PowerShell version 3.0 or
later. To check the version, open a PowerShell window and run the
following command: $Host
Set the execution policy to run the signed PowerShell scripts. To do
so, open a PowerShell window as an administrator and run the
following command: Set-ExecutionPolicy -ExecutionPolicy AllSigned
Verify the (CRMDeploymentServiceAppPool Application Pool identity) has SQL SEVER SysAdmin permission. This is needed to perform any CRM configuration changes and organizational operations.
Note: it does not matter if the account executing the PowerShell is a system admin or SQL server sysadmin because these operations are executed via the deployment web service.
Deployment Web Service (CRMDeploymentServiceAppPool Application Pool identity)
....Sysadmin permission on the instance of SQL Server to be used for the configuration and organization databases.
....
(500) Internal Server Error, refers to a HTTP response status code. This means that the Powershell command is calling a URL and the URL is reporting a error.
You need to know the URL to really find out what the problem is. One way you can get the URL, is downloading Fiddler Classic. Once installed, you have to enable HTTPS decryption.
In my case the URL was...
https://<my-crm-domain>/XrmDeployment/2011/deployment.svc?wsdl
When I ran this URL on the server where CRM is installed, I got an exception stating...
Could not load file or assembly 'Microsoft.Crm.Application.Components.Application'
All this meant, I needed to copy a file, Microsoft.Crm.Application.Components.Application.dll, from C:\Program Files\Dynamics 365\CRMWeb\bin into folder C:\Program Files\Dynamics 365\CRMWeb\XRMDeployment\bin.
Once this was done, the URL worked and therefor my PowerShell command as well.
I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.
Usually I can find an answer to PowerShell questions by researching forums and adapting. However, after searching high and low, I cannot find an answer.
I am logged in as a domain administrator working on two enterprise servers in a test domain. $Server2003 is Windows 2003 server running PS v2. $Server2008 is Windows 2008 R2.
Problem: When I am working from $Server2003 I cannot use any commands to access or verify information on $Server2008. This error happens regardless of who the administrator is.
I have used PowerShell fairly extensively in our environments and haven't run into this error before. The error is not present when running commands from $Server2008 on $Server2003. In addition the error is not present when running commands from a production domain. I can also ping the 2003 or 2008 server regardless of which machine I am logged in as.
Examples:
From $Server2008: ping $Server2003 - returns pings
From $Server2003: ping $Server2008 - returns pings
From $Server2003: test-path \\$Server2008\D$\ - Get-ChildItem : Cannot find path '\\$Server2008\D$\' because it does not exist
From $Server2008: test-path \\$Server2003\D$\ - True
The commands I want to run are a lot more complex than test-path; however, if I cannot get the simple command to work I doubt I'll have much luck with a complex one.
The two servers have the same domain, are in the same forest, and have the same domain controllers.
Any ideas where to start?
EDIT: Wanted to add that I have tried using test path from Server2003 to a different 2008 server located in our dev environment (same domain) and it runs the test-path and commands successfully.
can you access the 2008 server remotely by other means? Like the Services MMC? Also, what if you create a share on 2008 rather than rely on the admin share?
The cannot find path error means that it doesn't exist or you don't have permissions. Does it work from a dos prompt?
UPDATE
I just noticed that you used single quotes, the variable will not expand. Enclose it in double wotes and try again