Tag Archives: configuration

Safeguarding Your SSH Configurations with ssh-audit

Posted on by
Reply

In the vast ocean of network security, SSH (Secure Shell) stands as a towering lighthouse guarding the data traffic to and from your servers. However, how do you ensure that this lighthouse is in optimal condition? Enter ssh-audit, a tool for auditing your SSH server and client configurations.

Ssh-audit supports SSH1 and SSH2 protocol servers, diving deep into the SSH configurations to grab banners, recognize the software and operating systems involved, and even detect compression settings. It gathers information on key exchanges, host keys, encryption, and message authentication code algorithms, providing a comprehensive report on their status.

Getting started with ssh-audit is a breeze. Clone the repository from GitHub, and with a few commands in your terminal, you’re on your way to auditing your SSH configurations. The tool fetches algorithm information, outputting details such as availability, removal or disabling status, and security strength (unsafe, weak, legacy, etc). Moreover, it provides algorithm recommendations based on the recognized software version, aligning your settings with industry standards.

The icing on the cake? Ssh-audit outputs security information, including related issues and assigned CVE (Common Vulnerabilities and Exposures) list, offering you a clear picture of the security posture of your SSH setups.

With ssh-audit, not only do you get to audit your SSH configurations, but you also receive actionable insights to harden your SSH setups against potential threats. So, the next time you’re looking to bolster your network security, try ssh-audit and sail smoothly in the turbulent waters of cyber threats.

Note that MSI has no relationship with the tool or the authors. We just found the tool useful for infosec teams.

 * Just to let you know, we used some AI tools to gather the information for this article, and we polished it up with Grammarly to make sure it reads just right!

3 Essential Tips for Enhancing Site-to-Site VPN Security

Posted on by
Reply

 

Site-to-site VPNs are a crucial tool for securing communication between different network locations. To ensure the utmost security for your VPN connections, consider implementing these three key suggestions:

1. Select Strong Secrets or Secure Certificates

The foundation of any secure site-to-site VPN is the authentication mechanism. Opt for strong pre-shared keys or secure digital certificates when configuring your VPN. Using weak passwords or keys can leave your VPN vulnerable to attacks. Remember, a strong password should be lengthy, complex, and incorporate a mix of letters, numbers, and special characters. Alternatively, employing secure certificates provides an added layer of protection as they are difficult to intercept or guess.

2. Implement Modern, Peer-Reviewed Cryptography

Ensure that your site-to-site VPN employs modern encryption protocols have been rigorously reviewed by the security community. Protocols like IKEv2/IPsec are popular choices that offer robust encryption and authentication mechanisms. Peer-reviewed cryptography guarantees that the algorithms have undergone extensive scrutiny and are less likely to contain vulnerabilities or backdoors. Currently, AES is the suggested cryptographic mechanism for most VPNs. DES and 3DES should be eliminated wherever possible.

3. Create Proper Firewall Rules or ACLs

Managing traffic over your VPN connection is essential for maintaining a secure network environment. Utilize firewall rules or Access Control Lists (ACLs) to carefully regulate data flow between connected sites. You can prevent unauthorized access and potential breaches by explicitly defining what types of traffic are permitted and denied. Regularly review and update these rules to adapt to changing security requirements.

In Conclusion

Enhancing your site-to-site VPN’s security involves strong authentication, robust encryption, and intelligent traffic management. By selecting strong secrets or certificates, implementing modern cryptography, and creating well-defined firewall rules, you can significantly bolster the security of your VPN connections. Securing your network is an ongoing process, so staying updated on the latest security practices and adapting your configurations is essential.

Implement these tips today to build a resilient and secure site-to-site VPN that safeguards sensitive data and ensures seamless communication between your network locations.

 

* Just to let you know, we used some AI tools to gather the information for this article, and we polished it up with Grammarly to make sure it reads just right!

 

Leaking RFC1918 IP Addresses to the Internet

Posted on by
Reply

There has been a lot of conversation with clients about exposing internal DNS information to the public Internet lately. 

There are some security considerations, and a lot of the arguments often devolve into security by obscurity types of control discussions. My big problem with the leakage of internal DNS data to the Internet is that I hypothesize that it attracts attacker interest. That is, I know when I see it at a client company, I often immediately assume they have immature networking practices and wonder what other deeper security issues are present. It sort of makes me deeper attention to my pen-testing work and dig deeper for other subtle holes. I am guessing that it does the same for attackers. 

Of course, I don’t have any real data to back that up. Maybe someone out there has run some honeypots with and without such leakage and then measured the aggregate risk difference between the two scenarios, but I doubt it. Most folks aren’t given to obsess over modeling like I am, and that is likely a good thing.

It turns out though, that there are other concerns with exposed internal DNS information. Here are a few links to those discussions, and there are several more on the NANOG mailing list from the past several years.

Server fault, Quora, and, of course, the RFC1918 that says you shouldn’t leak them. 🙂 

So, you might wanna check and see if you have these exposures, and if so, and you don’t absolutely need them, then remove them. It makes you potentially safer, and it makes the Internet a nicer place. 🙂 

If you have an actual use for leaking them to the public Internet, I would love to hear more about it. Hit me up on Twitter and let me know about it. I’ll write a later post with some use scenarios if folks have them. 

Thanks for reading! 

Network Device Reviews, A Less Common Assessment

Posted on by
3

One of the less common assessments that MicroSolved performs for our clients is a Network Device Review (NDR). These assessments are aimed at helping clients assess the current state of specific devices or system configurations and improving them. 

Common devices assessed via this service include:

  • Firewalls
  • Routers and switches
  • IDS/IPS deployments and configurations
  • Load balancers
  • Workstation and server install and image baselines
  • ICS & SCADA devices from back end to customer premise

This type of assessment is performed using a combination of automated tools and manual time with our security engineers. The methodology leveraged to perform the assessment is very similar to our other assessments, with the engineers doing detailed analysis of attack surfaces and evaluation of relevant controls. Reports follow a more technical path for these services, with a technically focused report set and a small management level summary, keeping the cost of these services significantly less expensive than our deeper pen-testing and fuzzing assessments.

Customers often use these services to perform spot validation or as a part of an overall hardening project to improve their security posture organically. To learn more about the NDR service, get in touch with your account executive or contact us via info (at) micro solved (dot) com for a free conversation about how the NDR can help your organization.

As always, thanks for reading and stay safe out there!

Terminal Services Attack Reductions Redux

Posted on by
3

Last week, we published a post about the high frequency of probes, scans and attacks against exposed Windows Terminal Services from the Internet. Many folks commented on Twitter to me about some of the things that can be done to minimize the risk of these exposures. As we indicated in the previous post, the best suggestions are to eliminate them altogether by placing Terminal Services exposures behind VPN connections or through the implementation of tokens/multi-factor authentication. 

Another idea is to implement specific firewall rules that block access to all but a specific set of IP addresses (such as the home IP address range of your admins or that of a specific jump host, etc.) This can go a long way to minimizing the frequency of interaction with the attack surfaces by random attacker tools, probes and scans. It also raises the bar slightly for more focused attackers by forcing them to target specific systems (where you can deploy increased monitoring).

In addition, a new tool for auditing the configuration of Terminal Services implementations came to our attention. This tool, called “rdp-sec-check”, was written by Portcullis Security and is available to the public. Our testing of the tool showed it to be quite useful in determining the configuration of exposed Terminal Services and in creating a path for hardening them wherever deployed. (Keep in mind, it is likely useful to harden the Terminal Services implementations internally to critical systems as well…)

Note that we particularly loved that the tool could be used REMOTELY. This makes it useful to audit multiple customer implementations, as well as to check RDP exposures during penetration testing engagements. 

Thanks to Portcullis for making this tool available. Hopefully between this tool to harden your deployments and our advice to minimize the exposures, we can all drive down some of the compromises and breaches that result from poor RDP implementations.

If you would like to create some threat metrics for what port 3389 Terminal Services exposures might look like for your organization, get in touch and we can discuss either metrics from the HITME or how to use HoneyPoint to gather such metrics for yourself. 

PS – Special thanks to @SecRunner for pointing out that many cloud hosting providers make Terminal Server available with default configurations when provisioning cloud systems in an ad-hoc manner. This is likely a HUGE cause for concern and may be what is keeping scans and probes for 3389/TCP so active, particularly amongst cloud-hosted HITME end points.

PSS – We also thought you might enjoy seeing a sample of the videos that show entry level attackers exactly how to crack weak passwords via Terminal Services using tools easily available on the Internet. These kinds of videos are common for low hanging fruit attack vectors. This video was randomly pulled from the Twitter stream with a search. We did not make it and are not responsible for its content. It may not be safe for work (NSFW), depending on your organization’s policies. 

 

Tip: Pre-loading Wasp Configuration Databases

Posted on by
Reply

Thanks to a couple of users who have provided this excellent tip for reducing the initial number of alerts that come in when you first deploy HoneyPoint Wasp as it learns it’s environment.

The tip is to load an initial copy of Wasp on a trusted, fresh desktop workstation image and then execute all of the applications your organization generally supports. Then, let the Wasp run for about 48 hours and populate its database with the accepted applications and the like from the default image.

Once complete, use copies of this database in your installation across the enterprise. You will then get delta alerts instead of the base alerts for things you already know and trust. This eliminates the initial set of alerts from each Wasp workstation you deploy and greatly reduces the management load of the initial roll out.

Thanks to the two folks who really worked out this method, tested it and wrote up notes for us to share the idea with you. Much appreciated!

To learn more about using Wasp to extend your malware protection, gain security visibility easily to the workstation layer and create anomaly detection techniques for your security program, give us a call or drop us a line. We look forward to sharing tips like these and success stories with you as they come in from users.