Author: Pete

Offensive Security

VulnHub Walkthrough – The Planets: Mercury

An image of the planet Mercury, from PixabayIn this post, I want to take you through a walkthrough of how to hack your way into an intentionally vulnerable VM provided by VulnHub and created by user SirFlash. You can see more about this exercise and download your own copy of the .ova file to follow along here. I’ve found that the easiest way to run this VM is with VirtualBox, but you do have to do some specific setup/configuration for the machine to work like we want it to. Because we can’t get into the machine, we can’t really configure very much, so the VirtualBox settings are key.

In addition to VirtualBox, you need a machine to do the penetration test from. Kali Linux is very popular, though I have worked through several of these kinds of exercises with Linux Mint. Kali isn’t meant to be a “daily driver” OS and is just a version of Linux with a lot of tools preinstalled. You can install your favorite tools yourself on any distro that you’d like, or even use another preconfigured one (like Parrot, Black Arch, etc). Many tools are also available on Windows, especially if you have Windows Subsystem for Linux installed and configured. However, if you are ever working through tutorials, walkthroughs, books, videos, or forums, Linux is almost always assumed. There are a lot of resources to get started with Linux and it isn’t nearly as daunting as you’d think.

Just as a note, this machine is in a category called “Capture the Flag” (CTF). This is a fun style of game where you can practice certain skills, techniques, and problem solving abilities. It, however, isn’t necessarily indicative of “real world” penetration tests. My goal is to talk through my thought process as we walk through so you can see how I’m using some of the techniques I’ve learned to operate within the guidelines that CTFs often have. Feel free to just read this through as information, but it is also very fun and beneficial if you can follow along.

I’m starting from the assumption that you’ve already installed VirtualBox, downloaded the Mercury.ova file, and have a machine to attack from.

Getting Started

After you download the Mercury.ova file, open VirtualBox. Click the File menu, and then select Import Appliance
VirtualBox File Import Appliance

Next, you will be prompted to locate the file to import. Make sure your source is “Local File System” and then use the file selector to navigate to where you downloaded the .ova file.
VirtualBox File Import Step Two

Then, you’ll be shown a summary of settings. I was fine with what was here and I clicked Finish.
VirtualBox File Import Step Three

It will do its thing and when it is done, you will see the Mercury VM show up in your list of VMs on the left hand side.
VirtualBox Mercury Fully Imported

Next, with the virtual machine selected, you’ll want to click the orange Settings Gear (1), then select the Network menu (2), choose Host-only Adapter from the Attached to: drop down (3), and click OK (4). This will close the dialog box. Then click the green Start button (5) to start the VM. It is possible that you may not have a Host-only Adapter properly configured. If not – and because these details have changed in the past – just work through this Google Search. We’re doing this as a good way to allow VM to VM communication and that’s all.
Setting the VirtualBox Host Only Adapter

Once you’ve hit the play button, the machine will start up and you’ll see some Linux OS information go by and then the box will finally get to a login prompt. This means you’re ready to go. You can now minimize that window and get ready to work.
Mercury VM Login Prompt

For my environment, I have another VirtualBox VM of Kali that I changed the network adapter to Host Only from its normal NAT setting to do this exercise. I booted that up and logged in. The first thing we need to do is make sure we have netdiscover on our box. Kali is Debian based, so it uses apt to install things by default. I opened a terminal and I issued the command sudo apt install netdiscover. I had already entered my sudo password before this, so I wasn’t prompted, but you might be. I also already had this on my box, so your command window may look differently during and after the install.
apt install netdiscover

Then, I ran an ifconfig to see what my available network interfaces were. You can see that I have two network interfaces. One is called eth0 and the other is lo. lo is my local loopback interface, so eth0 is the one I want. Yours may be called something different for many reasons, including how you configured your adapters within VirtualBox.
ifconfig results

Next, I ran the command sudo netdiscover -i eth0. That brought up an auto-updating table that scanned every possible network address connected through that interface (-i eth0). Our goal here is to find out what IP Address the Mercury VM is at. If you aren’t sure, you can scan each one, but in this case, I know it is the one located at
Netdiscover Results

That means that it is now time to scan the box. This is our first “this is a CTF, not real life” warning. All of the scans I’m doing here are “noisy”. What that means is that I’m not sneaking around. I’m running these so they take less time from my perspective and are as instrusive as possible. If I was really doing a penetration test on someone, their monitoring tools would light up. It would be like a criminal pulling up to your house in a loud truck blaring music and wearing jingle bells as they used a battering ram on your front door.

Warning aside, I ran nmap -sC -sV -p- -T4 –min-rate=9326 -vv -oN mercury_nmap.log That command breaks down that I’m using default scripts (-sC) and I’m going to try to detect versions (-sV), I’m scanning all 65535 ports (-p-), I’m going super fast (-T4, where 5 is the highest/fastest), I’m going at 9326 packets per second at least (–min-rate=9326), I want the outputs very verbose (-vv), I want the output to a file called mercury_nmap.log (-oN mercury_nmap.log) and lastly that we’re going to scan Why 9326 packets per second? No real reason that I’m aware of except that someone I was learning from used it once, so I do.

That scan returned a lot of results, but the main things we learned from it are:

Nmap scan report for
Host is up, received conn-refused (0.00054s latency).
Scanned at 2024-03-22 16:11:14 EDT for 96s
Not shown: 65533 closed tcp ports (conn-refused)
22/tcp   open  ssh        syn-ack OpenSSH 8.2p1 Ubuntu 4ubuntu0.1 (Ubuntu Linux; protocol 2.0)
8080/tcp open  http-proxy syn-ack WSGIServer/0.2 CPython/3.8.2

So this machine exposes a web server and has secure shell (SSH) open. My next step is also now built on CTF mentality. I’m assuming that SSH is mid-game in our chess match. I figure I’m supposed to learn something from the web server first that will make the SSH part a little easier. So, I navigated to and got this.
Mercury's Default Webpage

Sometimes, in CTFs, the developers will leave clues in the Source. In this case, that text is all there is. It isn’t even HTML. So my next step was to use a tool to enumerate the website to try to find directories that aren’t linked to by just “guessing” from curated wordlists and seeing what hits. In this case, I used the command gobuster dir -w /usr/share/wordlists/dirb/common.txt -o mercury_gobuster.log -u This just used the gobuster program in directory mode (dir) with the wordlist (-w) of common possibilities, outputting (-o) to a log file against the url (-u) of our website. One of the benefits to using a box made for Offensive Security is that they often come with wordlists like this, though you can find them online, download them, and use them wherever you’re working from.
My gobuster results

Well, the only thing we found is a robots.txt. Because we didn’t find anything else, I did try some larger and larger lists, but they also returned only the robots.txt. I guess that means we should check it out.
Robots.txt Contents

Wow. That’s almost amazing in its uselessness. Now, we are at another point when I took a shot. I know a few things. 1) This box is marked as “Easy” and 2) This is a CTF. Some CTFs (especially harder ones) might have an open port with a trail for you to follow and even more work than this all for it to lead to nothing but a waste of time. But, because this is Easy, I wanted to try to see if causing an error would give us information. Maybe the error page would give us Server OS info and we could try an exploit, or reveal something else entirely. So, I navigated to in an attempt to see the 404 page.
The Mercury 404 Page

Jackpot. This server is using Django (useful), but even more useful is that it tried to resolve my URL by checking the index (we know about that), the robots.txt (ditto), and in a directory called mercuryfacts. Hmmmmm, that sounds promising. Let’s navigate to
The Mercury Facts Home Page

Here we go! We can load a fact and we can see their Todo List. (The Todo List is the sort of thing that is often left in HTML comments in these). So, I checked the Todo link first and found this
Mercury Facts Todo

Okay, information! We know there is either a users table that exists or they are using some (probably poor) other means of authentication in the interim. Also, they are making direct mysql calls (I’m smelling some possible SQL Injection!). What about that other link? I clicked it and it took me to fact 1. I went back and clicked it again and again and the fact isn’t random, this is all get and there is no navigation. So, I started just changing the number. First I went to 2 and got another fact, then to 999 and got no fact. Lastly, I tried a fact id of “pete” and that got me an error page (see how we love error pages that leak information!?)
Mercury Facts Enumeration

What we see in that error is that they are just taking the value from the url and just sticking it into a SQL query. Because we had a word and not a number, mysql thought I was trying to address a column in the where clause. I don’t need to go any further, I’m going to jump right into sqlmap to try to exploit this. sqlmap is a tool that attempts sql injection several different ways. When it works, you can dump databases, get table data, and all kinds of good stuff.

The first thing I tested was whether or not this would actually work. So, I issued the command sqlmap -u “” –dbms=mysql –risk=3 –level=5 –technique=U. In this case, the -u is our URL, the –dbms is telling it which database product to try to hit. We know mysql from the todos, but sqlmap can also guess if you don’t provide that. The risk and level values are just about the noise we’re willing to make and how hard we want the tool to try. Lastly, the –technique=U is telling it to do SQL UNIONS in an attempt to exfiltrate the data.
sqlmap initial results

We see that this comes back and the parameter is injectable. This means we can try something else. In this case, I issued the command sqlmap -u –dbms=mysql –risk=3 –level=5 –technique=U –tables. That’s very similar except that I added –tables so it would dump the tables. We got this

sqlmap identified the following injection point(s) with a total of 119 HTTP(s) requests:
Parameter: #1* (URI)
    Type: UNION query
    Title: Generic UNION query (NULL) - 1 column
    Payload: UNION ALL SELECT CONCAT(0x7178717071,0x53574a6856587464485476465941597769575a5a41555270716d78656c466949645264726352434f,0x71766b7171)-- -
back-end DBMS: MySQL >= 8.0.0
sqlmap resumed the following injection point(s) from stored session:
Parameter: #1* (URI)
    Type: UNION query
    Title: Generic UNION query (NULL) - 1 column
    Payload: UNION ALL SELECT CONCAT(0x7178717071,0x53574a6856587464485476465941597769575a5a41555270716d78656c466949645264726352434f,0x71766b7171)-- -
back-end DBMS: MySQL >= 8.0.0
Database: information_schema
[78 tables]
| APPLICABLE_ROLES                      |
| CHARACTER_SETS                        |
              -- SNIP -- 
| PROCESSLIST                           |
| TABLES                                |
| TRIGGERS                              |

Database: mercury
[2 tables]
| facts                                 |
| users                                 |

Okay, the first information_schema db is just something that is a feature of the dbms. I –SNIP–‘ed a lot of that out of there so you could see it, but let’s not have it clog us up. We care about the mercury db and its two tables: facts and users. If we remember, the Todo list wanted to start using the users table, so we’re very interested. Let’s dump it. sqlmap -u –dbms=mysql -D mercury -T users –dump –batch –technique=U –level=5 –risk=3. Our only change this time is to remove the request to list the tables and instead specify the database name (-D mercury) and the table name (-T users) and tell it to –dump it in a –batch.

sqlmap identified the following injection point(s) with a total of 49 HTTP(s) requests:
Parameter: #1* (URI)
    Type: UNION query
    Title: Generic UNION query (NULL) - 1 column
    Payload: UNION ALL SELECT CONCAT(0x7162707a71,0x71554a4b637448434261574e63514344716a56734371626a667a586a62507555586a635a4b717549,0x7176786a71)-- -
back-end DBMS: MySQL >= 8.0.0
Database: mercury
Table: users
[4 entries]
| id | password                      | username  |
| 1  | johnny1987                    | john      |
| 2  | lovemykids111                 | laura     |
| 3  | lovemybeer111                 | sam       |
| 4  | mercuryisthesizeof0.056Earths | webmaster |

Here we go! We have some usernames and plain text passwords. Now we can try to see what that SSH has got going on! Incidentally, if you examine the results of these scans, it took the tool 119 requests to dump the databases and tables and 49 requests to just get these 4 rows of one table. See what I mean about noisy?

Let’s use the webmaster account to get into the box. It seems like the ranking account. In addition, it has the best password, so I’m guessing it has the juicy stuff. So now we issue the command ssh webmaster@ and then hit enter. Enter the password and accept the fingerprint as you’re asked and we’re in. The first thing I did was an ls to list the contents of the directory and there is a user_flag.txt right there. I issued a cat user_flag.txt command and we have our user flag!
SSH into Mercury

The thing about CTF boxes is that there is often a User flag and then a Root (or Admin) flag. We’re only half done. Might as well keep exploring. What’s in this mercury_proj directory? To find out, I typed cd mercury_proj/ && ls and saw a notes.txt file. I called cat notes.txt and got 2 users and 2 passwords of some sort. So, we know the webmaster password, so if we can work out the encoding or hashing, we might have a shot. At a minimum, this looks like Base64 encoding (the == padding at the end of the linuxmaster user’s password is often a giveaway as = is used as padding in base64). But just because it is base64 doesn’t mean that’s the answer, encryption will often use base64 as the final step so all of the characters are printable. But, I use the echo command to echo each value and then pipe (|) it into the base64 utility, asking it to –decode. We see that the webmaster password is the one we know, so we can trust that this linuxmaster password is probably their password value.
Base64 Encoded Passwords

We can check that immediately by calling su linuxmaster and providing that password. It is accepted and a whoami tells me that I’m now linuxmaster. Is this over now? Is it this easy? We wish! I dug around but didn’t find any other flags, so I’ll spare you those searches.
Changing to Linuxmaster user

That means that our next step is likely privilege escalation. There are a few ways to go, but one of the easiest is to look and see what applications that the user might be able to call sudo on and act as root. Issuing the command sudo -l will tell you just that.
Finding Linuxmaster sudo Permissions

Okay, so we can run a specific bash script as sudo. Oh, that’s good news. Sometimes, we can edit what’s in the file and just do whatever we want. Other times, we can take advantage of what’s in the file and take advantage of the command another way. Let’s see what we’ve got. In the image above, you can see that I followed that up with cat /usr/bin/ to see what’s in the file. It just calls the Linux tail program to get the last 10 lines out of the /var/log/syslog file. This is actually a common kind of misconfiguration. The /var/log/syslog file needs elevated permissions or at least very specific permissions in order to read it. Instead of creating a group and giving that group permission to the file or using access control lists (ACLs), the admin figured he could give this user (and perhaps others) sudo permission on this script that only did one simple thing. But, they weren’t expecting this.

Linux (as well as many operating systems) store files in directory structures. The correct way to call every single program is to give its full path every time. We don’t do that. We just want to type ls or cat, not /bin/ls and /bin/cat or /usr/bin/ls and /usr/bin/cat. That’s where the path variable comes in. It defines a bunch of places/directories (in order) that the operating system is going to look for the thing you asked for. We can see what that should have been above. When using sudo, it is supposed to ignore your normal PATH and use the secure_path, which in this case for this user was declared as /usr/local/sbin, /usr/local/bin, /usr/sbin, /usr/bin, /sbin, /bin, and /snap/bin.

We’re going to take advantage of this because you also see that we have the env_reset permission when using sudo. That lets us CHANGE where all it is willing to look for commands. So, what we’re going to do is create a symlink (think shortcut, of sorts) in our current directory called tail that actually points to /bin/vi. That means whenever the current directory is in the path and someone calls tail, vi will run instead. Some of you who are familiar with vi or vim will know that it can basically run like its own little operating system. So, if I can run get this bash script to run as sudo and then open vi, I can then do things within vi as root. Here are the steps:
We actually take advantage of the flaw

In this case, the first thing I do is make sure I’m in my home directory, somewhere I have full permissions, just in case (cd ~). Then I create a symlink (ln -s) pointing to /bin/vi whenever someone calls the command tail (which is called from within that script). So, I update my own PATH variable to be my current directory plus the existing path variable. export PATH means I’m making that environment variable, the equals sign means I’m assigning whatever is on the right hand side to the variable. The . is my current directory (where I put the symlink), the : is concatenating these values, and $PATH is the current PATH environment variable. So in one sentence, I updated my local PATH environment variable to include what it already had, but putting my current directory in first position so it is checked for a command match there first.

The next line is me doing a typo, you can ignore it. I left it in to show that I’m human, too ๐Ÿ˜‰ But the right version of the command says sudo –preserve-env=PATH /usr/bin/ I’m calling for the elevated permissions, but then I’m using –preserve-env (because we have the env_reset permission) to use my new PATH environment variable (which includes my local directory) instead of the one carefully defined for me in secure_path. When I hit enter, vi automatically opens.
Our VI Window

If I type :, I’m automatically popped into command mode and typing shell and hitting enter opens a shell in my current context, which thanks to the sudo call on the file, is root. You can see here that I type whoami and I’m told that I’m root. I issued a cd ~ && ls command to change into root’s home directory and list out its contents. I see that there is a root_flag.txt file and a quick cat root_flag.txt and we can see that file’s contents.
We are root and showing the root flag

That’s it. In doing this box, we used the following skills:

  • nmap scan
  • gobuster scan (directory enumeration)
  • Found Error Page misconfiguration
  • Detected and exploited SQLi (SQL Injection)
  • Luck (found additional credentials)
  • symlinks
  • Misconfigured permissions, specifically around sudo and the secure_path variable

Not bad for a day’s work! Next time, I’ll take off a Red Team hat and put on a Blue Team hat and explain how the Administrators could have better protected this file and the sudo permissions (if they used them anyway).


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


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 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 -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 means that this rule applies to packets coming from the source (the -s) of -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 -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%”.


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.


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.


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.


Information Security Threats: DOS and DDOS

A flood overwhelming a dam
As part of this series on information security, we’ve been talking about the types of threats. We covered types of malware, types of phishing, and today we’re going to cover the types of denial of service attacks.

In our modern world where everything is connected to the Internet, the threat of cyber attacks looms large. Among the most disruptive of these are Denial of Service (DoS) and Distributed Denial of Service (DDoS) attacks. Let’s delve into what these attacks are and how they work.

What is a DoS Attack?

A Denial of Service attack is a malicious attempt to disrupt the normal traffic of a targeted server, service, or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic. DoS attacks achieve effectiveness by using a single internet-connected device, like one computer, to flood a target with requests until normal traffic is unable to be processed.

The Mechanics Behind a DoS Attack

  1. Exploiting Vulnerabilities: The attacker finds a vulnerability in a target system that can be exploited. This could be as simple as a web server that crashes under too many requests.
  2. Flood of Requests: Once the vulnerability is identified, the attacker sends a large number of requests to the server, more than it can handle. Think of a mailbox that is too stuffed with letters that no new ones can be delivered.
  3. Service Disruption: As a result, the server is unable to handle legitimate requests, leading to denial-of-service to regular users.

What is a DDoS Attack?

A Distributed Denial of Service (DDoS) attack is a more complex, powerful version of the DoS attack. Here, the attack is launched from multiple compromised devices, often distributed globally. These networks of compromised devices are known as botnets.

Understanding DDoS Attacks

  1. Building a Botnet: Attackers infect multiple devices with malware, turning them into bots. These devices can range from computers to IoT devices. You might think that you’re safe because “who would want your information?”. The truth is that your computer, computing power, and bandwidth are still a pretty valuable commodity.
  2. Coordinated Attack: The attacker then uses this botnet to send a massive number of requests to the target simultaneously.
  3. Magnified Impact: The distributed nature of this attack makes it more difficult to stop since it comes from multiple sources and can generate more traffic than a single source. Stopping it isn’t as simple as blocking an IP Address or IP Range.

The Implications of DoS and DDoS Attacks

The impact of these attacks can be extensive. Businesses can experience service disruptions, financial losses, and damage to their reputation. In severe cases, critical online services like banking, healthcare, or government services can be affected.

Protecting Against DoS and DDoS Attacks

  • Robust Infrastructure: Organizations should invest in robust server infrastructure that can handle high traffic volumes.
  • Security Measures: Implement security measures like firewalls – including next-generation firewalls (NGFW) – and intrusion detection systems (IDS) to identify and mitigate attacks.
  • Monitor Traffic: Regular monitoring of network traffic can help in early detection of unusual patterns that signify an attack.
  • Response Plan: Have a clear response plan in place to quickly address and mitigate the impact of an attack.

Aside from Ransomware, DoS and DDoS attacks represent some of the most significant threats to network environments today. They are capable of bringing down websites and other services. Understanding these attacks is the first step in defending against them and it is crucial for individuals and organizations alike to be aware of these threats and to take proactive measures to protect their digital assets.