In the last PowerShell installment, we discussed the usefulness of a package management solution in a Windows environment, specifically the PackageManagement Module introduced in PowerShell 5.0. There are, however, some security-related implications to enabling access to community-sourced repositories. As such, some enterprises may want to disable access to these repositories, effectively limiting the package management solution to only managing installations present on the local machine. Another option is to host and curate your own repository with applications that undergo an approval process. Luckily, it’s a lot easier than it sounds.
What is NuGet?
NuGet is a central repository of over 100,000 unique packages. More than just a repository, it is Microsoft’s supported mechanism for delivering packages in a Windows environment. Essentially, a NuGet package is just a ZIP file with the .nupkg extension and is easy to add to your locally hosted repository.
Setting up a NuGet Repository
Setting up a repository is pretty straightforward, but it does require a few tools. Specifically, it requires Visual Studio and an operating system that can run IIS. For the purpose of this post, I will be using Windows Server 2016 and Visual Studio 2015. The first step is to enable IIS and .Net which can be done using PowerShell with the following command:
This is essentially all of the PowerShell that is needed for setting up your repository. The next steps will all be done using Visual Studio. The next step is to create a new ASP.Net web application as seen in the image below:
Configure the solution name and location of your project as desired and select “OK”. You will then be prompted to select from a variety of ASP.NET templates. Select “Empty” and click “OK”:
Then, you will need to add NuGet.Server to your project’s references. This can be done by right-clicking on “References” and selecting “Manage NuGet Packages”. On the page that appears, you will be able to search for any desired packages. In this case, search for “NuGet.Server” and select “Install”:
You may receive an error message that states something like “targeted framework in your project is not supported.” If you are installing the latest stable version of the NuGet Server (currently 3.1.2), you need to ensure that your project is targeting the .NET 4.6 framework. This can be done by navigating to the ‘Properties’ page of your project as shown in the image below:
Once this change has been made, you can attempt to install the NuGet Server again. This time, the result should not contain any issues. After the installation, you will notice the presence of a few new folders in your project, as well as the web.config file. The default location for any packages hosted by your repository will be the “Packages” folder within your repository. However, you can modify this in web.config to specify your desired location:
The final step before building your project is configuring your IIS settings. For a basic configuration, you can do this directly from Visual Studio in the ‘Property’ page of your project. By navigating to the “Web” section and then the “Servers” subsection, you can select Local IIS from the drop-down menu and configure your project URL as desired. When you are ready, click “Create Virtual Directory”:
More advanced configurations can be handled within the IIS console.
The final step is building your project. To do so, right-click on the project in the Solution Explorer and click “Build”. Once this step is completed, navigate to your configured URL to verify the server is functioning properly.
Configuring Your Workstations
That’s it! You now have a local repository up and running. How do you get your workstation to reference it? This can be done using the Register-PackageSource cmdlet as follows:
Populating packages on your repository is as simple as dropping .nupkg files in the location you configured in your web.config file. Once that task is complete, use the following command to list your available packages:
What’s Next?
Admittedly, this has probably been the least ‘PowerShell-y’ installment in our series. That being said, the ability to manage which packages are available to your organization is a key factor in mitigating security risks. How can you prevent your users from simply adding other repositories to the PackageManagement Module, especially if you have an environment where users have administrative rights? This is where a hidden PowerShell feature called JEA comes into play. JEA stands for Just Enough Administration and provides a variety of ways to granularly control what your users can and cannot do. Next week, we will explore JEA’s capabilities in-depth and take a look at what implementation looks like.
About Automox
Facing growing threats and a rapidly expanding attack surface, understaffed and alert-fatigued organizations need more efficient ways to eliminate their exposure to vulnerabilities. Automox is a modern cyber hygiene platform that closes the aperture of attack by more than 80% with just half the effort of traditional solutions.
Cloud-native and globally available, Automox enforces OS & third-party patch management, security configurations, and custom scripting across Windows, Mac, and Linux from a single intuitive console. IT and SecOps can quickly gain control and share visibility of on-prem, remote and virtual endpoints without the need to deploy costly infrastructure.
Experience modern, cloud-native patch management today with a 15-day free trial of Automox and start recapturing more than half the time you're currently spending on managing your attack surface. Automox dramatically reduces corporate risk while raising operational efficiency to deliver best-in-class security outcomes, faster and with fewer resources.
