Category: InfoSec

InfoSec

Understanding Offensive Security

A robot arm holding a robotic sword over a laptop representing Offensive SecurityAt first blush, Offensive Security can seem like an oxymoron or a misnomer. Are we saying that the best defense is a good offense? Not really. When people say that in the traditional sense, they usually mean that by attacking, you don’t give your opponent a chance to attack you, therefore there is less for you to defend against. That’s not what we’re doing here. We are not out attacking the “bad guys” in an attempt to tie up their resources to keep them from attacking us. What we’re really talking about is attacking ourselves internally or through a third party vendor.

Offensive security refers to proactive measures taken to identify, assess, and mitigate vulnerabilities within a system before malicious hackers can exploit them. Unlike defensive security, which focuses on protection and prevention, offensive security involves simulating attacks to uncover weaknesses and bolster defenses. This approach is also known as ethical hacking or penetration testing.

The hacking is “ethical”, because the people performing the exercise have permission to do it and share all of their results with the target and don’t keep, use, or share any vulnerabilities or data they might uncover with the outside world. Penetration testing (pen testing) is a process that involves simulating cyberattacks to identify vulnerabilities in a system, network, or application. Ethical hackers use the same techniques as malicious actors to find and fix security flaws.

Taking this up a notch is something called Red Teaming. Red teaming is an advanced form of penetration testing where a group of security professionals, known as the red team, emulate real-world cyberattacks over an extended period. Their goal is to test the organization’s detection and response capabilities. These groups perform vulnerability assessments, which involves systematically examining systems for vulnerabilities, typically using automated tools. While less thorough than penetration testing, vulnerability assessments provide a broad overview of potential security issues. In addition, offensive security professionals will often use social engineering attacks to exploit human psychology rather than technical vulnerabilities. Offensive security professionals also often conduct phishing simulations and other tactics to test an organization’s security awareness.

So that explains a little of what these teams do, but let’s consider a little more of the why.

  • Proactive Defense: Offensive security allows organizations to identify and address vulnerabilities before they can be exploited by attackers. By staying one step ahead, companies can significantly reduce the risk of data breaches and other security incidents.
  • Improving Security Posture: Regular penetration testing and vulnerability assessments provide actionable insights that help organizations strengthen their security posture. This ongoing process ensures that defenses evolve in response to emerging threats.
  • Compliance and Regulatory Requirements: Many industries have strict compliance and regulatory standards that mandate regular security testing. Offensive security practices help organizations meet these requirements and avoid potential fines and penalties. I can tell you that in several audits and compliance engagements that I’ve had recently that they’ve wanted evidence that we regularly conduct offensive security operations against our company.
  • Incident Response Preparedness: Red teaming exercises and other offensive security activities help organizations test and refine their incident response plans. This ensures that in the event of a real attack, the organization is prepared to respond quickly and effectively.

Ethical Hackers (or White Hat Hackers) are the backbone of offensive security. We’re talking about individuals who have the skillset to “be the bad guys” (Black Hat Hackers), but instead earn a living helping others be prepared. The important thing, though, is that you don’t have to be born a hacker, spend time in the seedy underbelly of the internet, nor wear all black to go into this field. There is a lot of reputable training available and some respected certifications that you can get that can help your employment chances in the field (CEH and OSCP to name two).

If you’re interested, give it a shot. There is almost no barrier to entry. Sites like TryHackMe and HackTheBox have free tiers and there are tons of YouTube channels offering training and walkthroughs and advice. I plan on spending a fair amount of time in future posts talking about various security topics – often from the Offensive Security angle – and working through some of the problems available to us on places like TryHackMe, HackTheBox, and VulnHub so that I can also give back a little and add one more resource to the pile in gratitude to what has been given to me, so stay tuned for that.

InfoSec

Locking Down Mercury

A composite image of Mercury behind cartoon jail bars, both images from PixabayIn my last post, I did a walkthrough for the VulnHub box The Planets: Mercury. This box was conceived and implemented to be low hanging fruit for people who enjoy Capture the Flag (CTF) exercises. The advice for much of what we used to gain our initial foothold are pretty basic. The advice should be pretty familiar to anyone who takes security hygiene seriously and certainly anyone who is running a production web server. Additionally, Injection (SQL and otherwise) is on the OWASP Top 10 consistently. It should be one of the things that should be checked and remediated early, but often isn’t. Nevertheless, we weren’t splitting atoms to find it or to suggest how to fix it. Here are the basic “Don’ts” from the Mercury CTF:

  • Don’t leave default error pages in place
  • Don’t leave public “to do” lists
  • Don’t construct SQL Queries using blind concatenation
  • Don’t leave text files with passwords in plain text (or any encoding) on the server

But none of those are how we gained root on the box. We took advantage of a misconfiguration on the server that was intended to let the user read from a log file. The Mercury box wanted to allow the user to read records from the /var/log/syslog file. Normally, that file requires elevated permissions to read it. The Admins on this example box chose to create a script that reads the last 10 lines from the file and then gave the user permissions to run sudo on this script. Unfortunately, we were able to use symlinks to cause that script to allow us to ultimately open a root shell instead.

But what could the Admins have done differently? The best solution here is probably using Access Control Lists (acls). Linux file systems for a few generations have supported these by default. To work with them, we can just install a package and then configure the permissions.

Take a look at these simple commands that could have prevented this avenue of privesc on Mercury.

# Install the acl package
# In Debian-based systems
sudo apt-get install acl
# In RedHat-based systems
sudo yum install acl

# See if your file systems supports ACLs
grep acl /etc/mke2fs.conf

# If they do, you will see acl in the default mount options
default_mntopts = acl,user_xattr

# If not, you should be able to run this command to set it up
# This has not been tested by me, as every Linux box I could find already had the permissions
sudo mount -o remount,acl /

# Looking at the ACL on the file to start, we see that I (user) have read and write
# the adm group has read, and everyone else has no permissions.
getfacl /var/log/syslog

# Output
getfacl: Removing leading '/' from absolute path names
# file: var/log/syslog
# owner: syslog
# group: adm
user::rw-
group::r--
other::---

# Now I'm going to configure a user to have read permissions using
# setfacl which was added when we installed the acl package
sudo setfacl -m u:exampleuser:r /var/log/syslog

# Let's check again
getfacl /var/log/syslog

# Output
getfacl: Removing leading '/' from absolute path names
# file: var/log/syslog
# owner: syslog
# group: adm
user::rw-
user:exampleuser:r--
group::r--
mask::r--
other::---

# You notice that now we have another user row in the output, saying
# that example user has read permissions on the file

That’s it! It took me a total of less than two minutes and this avenue of escalation could have been prevented. This is a good example of how thinking like an attacker can help you be a better Administrator if you think about how every change you make to a system could be exploited and then think about a better way. When in doubt, look for guidance, don’t get “creative”.

InfoSec

Firewalls: Rules? A Guide with Examples

Rules are meant to be broken… as long as it’s not my rules

Signs representing a lot of rules

Introduction

Previously, we’ve talked about what firewalls are and what types of firewalls exist. This time, I want to dig into what kinds of rules these firewalls have that make them work as the last post in my Firewall miniseries.


Basic Firewall Rules and Configurations

For some of these rules examples, I’m going to include one way to declare each rule using iptables, which is available as a very simple host-based firewall on Linux system. (The Wikipedia summary is that iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules). I chose to use examples this way because it is indicative of the general thought process that is used to create these kinds of rules, even if the syntax can vary. This isn’t an iptables tutorial and a total and proper implementation for each example might contain other commands, as well.

Other examples are more complicated and aren’t really suited for iptables and I give some simplified examples for other products in the marketplace that meet the challenge.

IP Address-Based Rules

  • Example Rule: Deny all traffic from external IP 142.250.189.174 to any IP within the network.
  • Use Case: This rule is useful when you want to block specific external threats known by their IP addresses.
  • Simple Implementation: sudo iptables -A INPUT -s 142.250.189.174 -j DROP
  • Implementation Explanation: sudo executes the command as a super user (Administrative permissions). iptables is the Linux command utility program. -A INPUT explains that this is a rule for inbound packets. -s 142.250.189.174 means that this rule applies to packets coming from the source (the -s) of 142.250.189.174. -j DROP means that the result will jump (-j) to the DROP action, meaning the packet will not be passed along to the rest of the system.

Port-Based Rules

  • Example Rule: Allow TCP traffic only on port 443 (HTTPS).
  • Use Case: Ideal for web servers that should only communicate via web traffic ports.
  • Simple Implementation: sudo iptables -A INPUT -p tcp –dport 443 -j ACCEPT && sudo iptables -A OUTPUT -p tcp –dport 443 -j ACCEPT
  • Implementation Explanation: We covered sudo iptables -A INPUT and -j ACCEPT above. The -p tcp means that this rule applies to the protocol (-p) of TCP and destination port (–dport) of 443. && just allows us to put two Linux commands in one line. Then the only difference in the second command is that we’re making a rule to allow outbound traffic as well as inbound traffic (-A OUTPUT).

Protocol-Specific Rules

  • Example Rule: Allow ICMP (Internet Control Message Protocol) for internal network devices only.
  • Use Case: Useful for allowing internal network testing and diagnostics while blocking potential external pings or other ICMP-based attacks.
  • Simple Implementation: sudo iptables -A INPUT -s 192.168.1.0/24 -p icmp -j ACCEPT && iptables -A INPUT -p icmp -j DROP
  • Implementation Explanation: In this case, our source (-s) is given as a subnet. You’d put whatever subnet represents your internal network (this is a shorthand way to represent every possible IP address that can exist on a network). The protocol (-p) is icmp and we will jump (-j) to ACCEPT. Again, we && to put two commands together and then create another rule that drops all other ICMP packets. It is important that these rules are included in this order or else the broad DROP will execute first before the limited ACCEPT rule is considered.

Stateful Inspection Rules

  • Example Rule: Allow outgoing traffic on any port but restrict incoming traffic to responses to established connections only.
  • Use Case: This is common for businesses that want to ensure outbound traffic is unobstructed while maintaining tight control over incoming requests.
  • Simple Implementation: access-list YOUR_ACL_NAME extended permit tcp any any established
  • Implementation Explanation: This rule is using a Cisco ASA, which has stateful firewall capabilities. In this case, this rule assumes you already have an access list (here represented by YOUR_ACL_NAME) and you address the access-list named YOUR_ACL_NAME and extended (rather than standard) will filter traffic on multiple criteria. In this case, we are allowing (permit) tcp traffic from any address to any address as long as it was already established.

Time-Based Rules

  • Example Rule: Blocking all inbound traffic during non-business hours.
  • Use Case: For organizations that want to limit access during off-hours for security purposes.
  • Simple Implementation: It’s complicated 😉
  • Implementation Explanation: There are a few ways to do this. One way is to run cron jobs (scheduled jobs) on your Linux server that add and remove iptables rules at the appropriate times. Other firewalls, like pfSense Plus and OPNsense make it easy through an interface. Here are the steps to do this in OPNsense:
    1. Define a Schedule: First, go to “Firewall” then “Schedules” in OPNsense. Create a new schedule and define the time periods (8 am to 5 pm) and the days of the week (Monday to Friday).
    2. Create Firewall Rule: Next, create a firewall rule under “Firewall” > “Rules” and select the interface where the rule should apply. Configure the rule to match your desired traffic (e.g., set the action to “Pass” for allowing traffic).
    3. Apply the Schedule to the Rule: In the rule settings, you will find an option to apply the schedule. Select the schedule you created in the first step.
    4. Activate and Test the Rule: After saving the rule, it will become active according to the schedule. It’s important to test the rule to ensure it behaves as expected during the specified times.

Configuring Your Firewall

Applying rules in a firewall is often very easy. You can see that the commands aren’t very long and UIs can make even complex rules creatable in a minute. However, defining and configuring your firewall rules correctly is very complicated. It is important that the rules are applied in the right order (“deny all traffic” needs to be the last rule applied, after the few approvals that you add for traffic you want, for instance). It is also important that your rules fit your business and your needs. Certain companies might need to allow traffic over port 22 (ssh). Some of those companies might allow free connections to the port, while others might “IP Whitelist” and only allow certain locations to connect. Other companies might allow the default RDP port of 3389, while other companies that have no Windows Servers would never need that port opened. The team defining these setups must understand the entire organization’s needs in order to lock the network down correctly. It is a razor’s edge: too strict and the company could not function effectively, too permissive and the company could be vulnerable to intrusion by threat actors. But here are the 30,000ft view of the steps that the team would undertake to configure a firewall.

  1. Identifying Network Requirements: Understanding what services and traffic are necessary for your network.
  2. Defining Clear Security Policies: Knowing what your organization’s security policies are in terms of what should be allowed or blocked.
  3. Implementing and Testing Rules: Gradually implementing rules and testing them to ensure they don’t disrupt legitimate traffic.
  4. Regular Updates and Monitoring: Keeping the firewall rules updated according to the evolving network needs and security landscape.

Whew, that’s a lot. If you’re new to this entire idea and reading this from a beginner’s point of view, I hope that I didn’t make this super confusing. I am hoping that by seeing these scenarios and beginning to “think in firewall logic” that you’ll begin to understand more fully the roles that firewalls play and how someone would begin to think about setting them up. It definitely has more in common with “who can come into my clubhouse?” than stupid scenes in movies where say ridiculous statements like “our firewall is at 19%”.

InfoSec

Firewalls: How Many Kinds Can There Be?

A graphic representing different types of firewallsIn the realm of network security, firewalls play a crucial role in protecting our digital assets from various threats. Whether you’re a budding IT professional or just curious about how network security works, it’s essential to understand the different types of firewalls and how they function. This blog aims to demystify these critical security components without oversimplifying or using buzzwords.

What is a Firewall?

We covered this last time, but – as a refresher – at its core a firewall is a network security device that monitors and controls incoming and outgoing network traffic based on predetermined security rules. Essentially, it acts as a barrier between your internal network and external sources, such as the internet, to block malicious traffic like viruses and hackers.

Types of Firewalls

1. Hardware Firewalls

Hardware firewalls are physical devices that sit between your network and the gateway to the outside world (typically your internet connection). They are especially useful in protecting entire networks. Think of them as a first line of defense; they filter traffic before it reaches individual computers on a network. Examples include broadband routers and enterprise-level devices that offer more robust features.

2. Software Firewalls

Software firewalls, on the other hand, are installed directly on individual computers or servers. They offer more granular control at the device level. This type of firewall is particularly useful for controlling the outgoing traffic, as it can restrict which applications on your computer can access the internet. However, they require more maintenance and are only as secure as the host device.

3. Next-Generation Firewalls (NGFW)

Next-Generation Firewalls are a step above traditional firewalls. They integrate additional features such as encrypted traffic inspection, intrusion prevention systems, and the ability to identify and block sophisticated attacks. NGFWs are more intelligent in their filtering and can make decisions based on applications, users, and content rather than just IP addresses.

4. Web Application Firewalls (WAF)

Web Application Firewalls are specifically designed to protect web applications by monitoring and filtering HTTP traffic between a web application and the Internet. They are particularly effective in preventing web-based attacks such as cross-site scripting (XSS), SQL injection, and cookie poisoning.

Choosing the Right Firewall

Selecting the right type of firewall depends on your specific needs:

  • For home networks or small businesses, a hardware firewall, often combined with a software firewall on individual devices, can offer sufficient protection.
  • Larger organizations with more complex needs might opt for NGFWs due to their advanced features and ability to handle larger volumes of traffic.
  • If you’re running a website or web application, a WAF is essential to protect against web-specific attacks.

Conclusion

In today’s landscape, understanding the various types of firewalls is fundamental for anyone interested in network security. From hardware firewalls that protect entire networks to NGFWs and WAFs that offer advanced features for complex and specific needs, the right firewall can act as a formidable barrier against cyber threats. Remember, the effectiveness of a firewall depends not only on its type but also on proper configuration and maintenance. Stay informed and stay secure.

InfoSec

Firewalls: Huh, What?

Image representing a firewall using a lock and circuits. In today’s world, security is more than just locking your doors; it’s about safeguarding your presence online. Firewalls serve as the first line of defense in network security, but what exactly are they, and why are they crucial for both servers and personal devices like laptops and desktops? Let’s delve into the world of firewalls and understand their role in protecting our privacy.

What Are Firewalls?

A firewall is a network security device that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules. It’s like a bouncer for your network, meticulously checking the credentials of every packet of data that attempts to enter or leave.

Firewalls can be hardware-based, software-based, or a combination of both. Hardware firewalls are physical devices that act as a gate between your network and the outside world, while software firewalls are programs installed on individual devices that control traffic through port numbers and applications.

The Importance of Firewalls on Servers

Servers are the heavy lifters in the realm of computing. They manage, store, and send critical data, making them a prime target for cyber attacks. A firewall on a server acts as the first barrier against these threats. It filters out unauthorized access attempts and malicious traffic that could compromise the server’s integrity. For businesses, this means protecting not just their operational backbone but also their customer data from breaches.

Why Personal Devices Need Firewalls

While servers are like the bank vaults of data, personal devices are the wallets. They may not hold the same quantity of data, but the quality and sensitivity of the information can be just as significant. A firewall on your laptop or desktop is essential because:

  • It protects your device from unauthorized access.
  • It shields your personal information from malicious entities.
  • It helps prevent malware and viruses, which can spread to other devices on the same network.

In simple terms, having a firewall is a basic yet powerful way to ensure that your personal – often sensitive – information remains confidential and intact.

Do Mobile Phones Need Firewalls?

Mobile phones are a unique case. They are constantly connected to the internet and contain a wealth of personal information. Modern smartphones operate with a default set of security measures, including app-based permissions and in-built traffic management, which act like rudimentary firewalls.

However, the question of whether you need an additional firewall for your mobile device depends on your use case. For the average user, the in-built security measures, along with careful app management, should suffice. But for those using their phones as business tools or who store sensitive data, a dedicated mobile firewall app can add an extra layer of security.

To Firewall or Not to Firewall?

The answer is simple: Yes, firewall away. The internet is an open sea of information where data pirates abound. A firewall is your trusty vessel keeping you afloat and away from unwanted boarders. Whether it’s on a server maintaining critical data, a laptop storing your personal memories, or a mobile phone with access to your digital identity, the features of firewalls are an essential component of digital security.

Remember, in the vast digital landscape, a firewall is your best watchdog, standing guard between your secrets and privacy in the ever-evolving threats of the cyber world.

Stay safe, stay secure, and let firewalls be one of the first lines of defense in your digital security.