Tag Archives: firewalls

Ensuring Cybersecurity: Blocking Discord Access with Firewall Rules

Posted on by
Reply

 

I. Introduction

Purpose of Blocking Discord Access

Social media and communication platforms like Discord are everywhere in today’s digital landscape. However, their widespread use also introduces significant cybersecurity risks. Discord, known for its extensive user base and real-time communication features, can be a vector for malicious actors’ malware distribution and command and control (C2) operations. Blocking access to Discord within a corporate environment is a proactive measure to mitigate these risks.

Importance of Controlled Access to Prevent Malware Command and Control

Controlling access to external platforms is crucial in preventing unauthorized use of corporate resources for malicious purposes. By restricting access to platforms like Discord, organizations can reduce the risk of malware infections, data breaches, and unauthorized communications. This measure helps keep network integrity and security intact, safeguarding sensitive business information from cyber threats.

II. Assessing Business Needs

Identifying Users with Legitimate Business Needs

Before implementing a blanket ban on Discord, it’s essential to identify any legitimate business needs for accessing the platform. This could include marketing teams monitoring brand presence, developers collaborating with external partners, or customer support teams engaging with clients through Discord channels.

Documenting and Justifying Business Needs

Once legitimate needs are identified, they should be documented comprehensively. This documentation should include the specific reasons for access, the potential benefits to the business, and any risks associated with allowing such access. This step ensures that decisions are transparent and justifiable.

Approval Process for Access

Establish a formal approval process for users requesting access to Discord. This process should involve a thorough IT and security team review, considering the documented business needs and potential security risks. Approved users should be granted access through secure, monitored channels to ensure compliance with corporate policies.

III. Technical Controls

A. Network Segmentation

Isolating Critical Systems

One of the fundamental strategies in cybersecurity is network segmentation. Organizations can limit the potential impact of a security breach by isolating critical systems from the rest of the network. Critical systems should be placed in separate VLANs (Virtual Local Area Networks) with strict access controls.

Implementing VLANs

Creating VLANs for different departments or user groups can help manage and monitor network traffic more effectively. For instance, placing high-risk users (those needing access to external platforms like Discord) in a separate VLAN allows for focused monitoring and control without impacting the broader network.

B. Firewall Rules

Blocking Discord-Related IPs and Domains

To block Discord access, configure firewall rules to block known Discord IP addresses and domain names. For example:

! Block Discord IP addresses
access-list 101 deny ip any host 162.159.129.233
access-list 101 deny ip any host 162.159.128.233

! Block Discord domain names
ip domain list discord.com
ip domain list discord.gg
access-list 101 deny ip any host discord.com
access-list 101 deny ip any host discord.gg

! Apply the access list to the appropriate interface
interface GigabitEthernet0/1
 ip access-group 101 in

For comprehensive lists of Discord servers and IPs to block, refer to resources such as:

Creating Whitelists for Approved Users

For users with approved access, create specific firewall rules to allow traffic. This can be done by setting up a whitelist:

! Allow approved users to access Discord
access-list 102 permit ip host approved_user_ip any

! Apply the whitelist access list to the appropriate interface
interface GigabitEthernet0/1
 ip access-group 102 in

C. Proxy Servers

Filtering Traffic

Utilize proxy servers to filter and control web traffic. Proxy servers can block access to Discord by filtering requests to known Discord domains. This ensures that only approved traffic passes through the network.

Monitoring and Logging Access

Proxy servers should also be configured to monitor and log all access attempts. These logs should be reviewed regularly to detect unauthorized access attempts and potential security threats.

D. Application Control

Blocking Discord Application

Application control can prevent the installation and execution of the Discord application on corporate devices. Use endpoint security solutions to enforce policies that block unauthorized software.

Allowing Access Only to Approved Instances

For users who need Discord for legitimate reasons, ensure they use only approved instances. This can be managed by allowing access only through specific devices or within certain network segments, with continuous monitoring for compliance.

Conclusion

Blocking Discord access in a corporate environment involves a multi-layered approach combining policy enforcement, network segmentation, firewall rules, proxy filtering, and application control. Organizations can mitigate the risks associated with Discord by thoroughly assessing business needs, documenting justifications, and implementing robust technical controls while allowing necessary business functions to continue securely.

For assistance or additional insights on implementing these controls, contact MicroSolved. Our team of experts is here to help you navigate the complexities of cybersecurity and ensure your organization remains protected against emerging threats.

 

 

* AI tools were used as a research assistant for this content.

 

Navigating the Regulatory Terrain: Firewall Rule and Configuration Reviews

Posted on by
Reply

In the ever-evolving landscape of network security, the significance of firewall rules and configuration reviews stands paramount. For organizations, navigating through the complex web of industry standards and regulations is not just a matter of compliance but a cornerstone in safeguarding sensitive data and fortifying defenses against cyber threats. This discourse aims to demystify the regulatory frameworks governing firewall configurations, highlighting their pivotal role in sculpting a resilient network infrastructure.

The Imperative of Regulatory Adherence:

Navigating the labyrinth of regulations like PCI DSS (Payment Card Industry Data Security Standard) and HIPAA (Health Insurance Portability and Accountability Act) is more than a compliance checkbox. It’s an integral strategy to thwart unauthorized access, data breaches, and other security loopholes. A meticulous alignment with these standards underpins your organization’s commitment to unwavering security and data protection.

  • PCI DSS Compliance: Regular firewall configuration reviews ensure alignment with PCI DSS mandates. These reviews should encompass comprehensive documentation and alert mechanisms to adhere to the security management controls and firewall rule examination requirements.
  • HIPAA Conformity: For organizations handling healthcare data, firewall configuration reviews are instrumental in aligning with HIPAA’s stringent requirements, ensuring the safeguarding of sensitive patient data.

International Standards: Aligning with ISO 27001

Embracing global benchmarks like ISO 27001 requires an exhaustive evaluation of firewall configurations. This process entails benchmarking current configurations against ISO standards and rectifying any discrepancies to achieve compliance. Key focus areas include access control, network segmentation, and adherence to security policies.

Understanding Firewall Configuration Reviews: A Deep Dive

The essence of firewall configuration reviews lies in scrutinizing settings, rules, and protocols to uncover vulnerabilities and threats. This thorough analysis enables IT professionals to bolster the firewall’s defense capabilities, enhancing the overall security fabric of the network.

Purpose and Benefits of Routine Firewall Configuration Reviews:

  • Risk Mitigation: Regular reviews unveil security vulnerabilities and compliance deviations, essential in maintaining a fortified network environment.
  • Optimizing Resources: Eliminating outdated or redundant rules enhances network efficiency and performance.
  • Compliance Assurance: These reviews are pivotal in meeting regulatory standards, averting fines, and sustaining a robust security posture.
  • Cost Savings: Proactive reviews and updates curtail the likelihood of breaches and associated financial repercussions.

Defining Firewall Configuration Review:

A firewall configuration review is a meticulous examination of firewall settings and rules. It’s aimed at ensuring optimal protection against unauthorized access and cyber threats. This process identifies potential security gaps and ensures adherence to best security practices.

Partner with MicroSolved for Expert Firewall Configuration and Analysis

At MicroSolved, we recognize the complexities and critical nature of firewall configuration reviews. Our MachineTruth™ service offers unparalleled expertise in firewall configuration and analysis, scalable to global operations. Our team of experts employs advanced methodologies, proprietary machine learning, analytics and custom-built private AI to ensure your firewall configurations are not only compliant with the latest regulations but also optimized for peak performance and security. Since we can analyze all of your firewalls, routers, switches and other network devices simultaneously, we can also ensure that your security posture is consistent everywhere you have a presence!

Embark on your journey towards a more secure and compliant network infrastructure with MicroSolved. Contact us today (info@microsolved.com or +1-614-351-1237) to learn more about our MachineTruth™ services and how we can tailor them to meet your organization’s unique needs.

 

* 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!

 

Comparing 2 Models for DMZ Implementations

Posted on by
7
I recently had a discussion with another technician about the security of the two most popular DMZ implementation models. That is: 
  • The “3 Legged Model” or “single firewall” – where the DMZ segment(s) are connected via a dedicated interface (or interfaces) and a single firewall implements traffic control rules between all of the network segments (the firewall could be a traditional firewall simply enforcing interface to interface rules or a “next generation” firewall implementing virtualized “zones” or other logical object groupings)
  • The “Layered Model” or “dual firewall”- where the DMZ segment(s) are connected between two sets of firewalls, like a sandwich
 
Both approaches are clearly illustrated above, and explained in detail in the linked wikipedia article, so I won’t repeat that here. 
 
I fully believe that the “3 Legged Model” is a lower risk implementation than the layered model. This outright contradicts what the wikipedia article above states: 
 
     “The most secure approach, according to Stuart Jacobs, [1]is to use two firewalls to create a DMZ.” — wikipedia article above.
 
While the Layered model looks compelling at first blush, and seems to apply the concept of “more firewalls would need to be compromised to lead to internal network access”; I believe that, in fact, it reduces the overall security posture in the real world, and increases risk. Here’s why I feel that way. Two real-world issues that often make things that look great at first blush or that “just work” in the lab environment, have significant disadvantages in the real world are control complexity and entropy. Before we dig too deeply into those issues though, let’s talk about how the two models are similar. (Note that we are assuming that the firewalls themselves are equally hardened and monitored – IE, they have adequate and equal security postures both as an independent system and as a control set, in aggregate.)
 
Reviewing the Similarities
 
In both of the models, traffic from the DMZ segment(s) pass through the firewall(s) and traffic controls are applied. Both result in filtered access to the internal trusted network via an often complex set of rules. Since in both cases, traffic is appropriately filtered, authorization, logging and alerting can adequately occur in both models. 
 
Establishing Differences
 
Now the differences. In the 3 Legged model, the controls are contained in one place (assuming a high availability/failover pair counts as a single set of  synced controls), enforced in one place, managed and monitored in one place. The rule set does not have cascading dependencies on other implementations of firewalls, and if the rule set is well designed and implemented, analysis at a holistic level is less complex.
 
In the Layered model, the controls are contained across two separate instances, each with different goals, roles and enforcement requirements. However, the controls and rule sets are interdependent. The traffic must be controlled through a holistic approach spread across the devices, and failures at either firewall to adequately control traffic or adequately design the rule sets could cause cascading unintended results. The complexity of managing these rules across devices, with different rule sets, capabilities, goals and roles is significantly larger than in a single control instance. Many studies have shown that increased control complexity results in larger amounts of human error, which in turn contributes to higher levels of risk. 
 
Control Complexity Matters
 
Misconfigurations, human errors and outright mistakes are involved in a significant number (~95%) of compromises. How impactful are human mistakes on outright breaches? Well according to the 2015 Verizon DBIR:
 
“As with years past, errors made by internal staff, especially system administrators who were the prime actors in over 60% of incidents, represent a significant volume of breaches and records ,even with our strict definition of what an “error” is.” —DBIR
 
Specifically, misconfiguration of devices were involved in the cause of breaches directly in 3.6% of the breaches studied in the DBIR. That percentage may seem small, but the data set of 79,790 incidents resulting in 2,122 breaches that means a staggering number of 76 breaches of data were the result of misconfigurations.
 
This is exactly why control complexity matters. Since control complexity correlates with misconfiguration and human error directly, when complexity rises, so does risk – conversely, when controls are simplified, complexity falls and risk of misconfiguration and human error is reduced.
 
Not to beat on the wikipedia article and Stuart Jacob’s assertions, but further compounding the complexity of his suggestion is multiple types of firewalls, managed by multiple vendors. Talk about adding complexity, take an interdependent set of rules and spread them across devices, with differing roles and goals and you get complexity. Now make each part of the set a different device type with it’s own features, nuances, rule language, configuration mechanism and managed service vendor, and try to manage both of those vendors in sync to create a holistic implementation of a control function. What you have is a NIGHTMARE of complexity. At an enterprise scale, this implementation approach would scale in complexity, resources required and oversight needs logarthmically as new devices and alternate connections are added. 
 
So, which is less complex, a single implementation, on a single platform, with a unified rule set, managed, monitored and enforced in a single location – OR – a control implemented across multiple devices, with multiple rule sets that require monitoring, management and enforcement in interdependent deployments? I think the choice is obvious and rational.
 
Now Add Entropy
 
Ahh, entropy, our inevitable combatant and the age old foe of order. What can you say about the tendency for all things to break down? You know what I am about to point out though, right? Things that are complex, tend to break down more quickly. This applies to complex organisms, complex structures, complex machinery and complex processes. It also applies to complex controls.
 
In the case of our firewall implementation, both of our models will suffer entropy. Mistakes will be made. Firewall rules will be implemented that allow wider access than is needed. Over time, all controls lose efficiency and effectiveness. Many times this is referred to as “control drift” or “configuration drift”. In our case, the control drift over a single unified rule set would have a score of 1. Changes to the rule set, apply directly to behavior and effectiveness. However, in the case of the Layered model, the firewalls each have a distinct rule set, which will degrade – BUT – they are interdependent on each other – giving an effective score of 2 for each firewall. Thus, you can easily see, that as each firewall’s rule set degrades, the private network’s “view” of the risk increases significantly and at a more rapid pace. Simply put, entropy in the more complex implementation of multiple firewalls will occur faster, and is likely to result in more impact to risk. Again, add the additional complexity of different types of firewalls and distinct vendors for each, and the entropy will simply eat you alive…
 
Let’s Close with Threat Scenarios

Let’s discuss one last point – the actual threat scenarios involved in attacking the private network from the DMZ. In most cases, compromise of a DMZ host will give an attacker a foothold into the environment. From there, they will need to pivot to find a way to compromise internal network resources and establish a presence on the internal network. (Note that I am only focusing on this threat scenario, not the more common phishing/watering hole scenarios that don’t often involve the compromise of a DMZ host, except perhaps for exfiltration paths. But, this is outside our current scope.) If they get lucky, and the DMZ is poorly designed, they may find that their initially compromised host has some form of access to the internal network that they can exploit. But, in most cases, the attacker needs to perform lateral movement to compromise additional hosts, searching for a victim that has the capability to provide a launching point for attacks against the internal network.
 
In these cases, detection is the goal of the security team. Each attacker move and probe, should cause “friction” against the controls, thereby raising the alert and log levels and the amount of unusual activity. Ultimately, this should lead to the detection of the attacker presence and the incident response process engagement.
 
However, let’s say that you are the attacker, trying to find a host that can talk to the internal network from the DMZ in a manner that you can exploit. How likely are you to launch an attack against the firewalls themselves? After all, these are devices that are designed for security and detection. Most attackers, ignore the firewalls as a target, and continue to attempt to evade their detection capabilities. As such, in terms of the threat scenario, additional discreet firewall devices, offer little to no advantage – and the idea that the attacker would need to compromise more devices to gain access loses credibility. They aren’t usually looking to pop the firewall itself. They are looking for a pivot host that they can leverage for access through whatever firewalls are present to exploit internal systems. Thus, in this case, both deployment models are rationally equal in their control integrity and “strength” (for lack of a better term).
 
Wrapping This Up
 
So, we have established that the Layered model is more complex than the 3 Legged model, and that it suffers from higher entropy. We also established that in terms of control integrity against the most common threat scenario, the implementation models are equal. Thus, to implement the Layered model over the 3 Legged model, is to increase risk, both initially, and at a more rapid pace over time for NO increase in capability or control “strength”. This supports my assertion that the 3 Legged model is, in fact, less risky than the Layered model of implementation.
 
As always, feel free to let me know your thoughts on social media. I can be found on Twitter at @lbhuston. 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!