Bug Bounty Diaries #10 – Linux UFW & IPTables

If you have read the last article, you know that I am currently working on my VPS and on writing my own Recon script. So the stuff that I have learned in week #19 of 2020 hasn’t changed much from week #18, as I mostly spent my time coding away in VSCode and setting up my Droplet on Digital Ocean. The next week will be more interesting in regards of actual hacking, as we will be talking about API!


Linux UFW

The Linux UFW is a firewall that you can use on every Linux System. If you are setting up a VPS for Hacking, you need to secure it accordingly. Because I also run a Web Server on my VPS to process my recon results and display them nicely formatted, I have to secure access to it, therefore I needed to create a couple of firewall rules to restrict access to my own IP address using DynDNS.

Let’s look at a couple of basic commands to get started.

Installing UFW

sudo apt update && sudo apt install ufw

Setting Default Policies

To get started on the same level, we are going to set policies to the default value. Don’t worry, UFW is not enabled yet.

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allowing SSH

Obviously, if we still want to be able to connect to our Droplet, we need to enable incoming SSH access. That’s easily done.

sudo ufw allow ssh


sudo ufw allow 22

Enabling UFW

Now we are ready to enable the UFW. Now, make sure you have set up the SSH correctly! If you did a mistake, you won’t be able to access your server anymore! If you use a Digital Ocean Droplet, you can still sign in via the Web Gui Shell, in case you get locked out.

sudo ufw enable

Enabling Access from a specific IP Address

Let’s assume you have a static IP address on your WAN and you want to only be able to access your server from your own network. We can do this using UFW rules as well.

sudo ufw allow from your.ip.address.here

This allows all incoming traffic from your IP address.

You can also allow traffic from your IP to a specific port or service only:

sudo ufw allow from your.ip.address.here to any port 22

Simple, right?

Denying Access

To deny access, it’s just as simple.

sudo ufw deny http

Denies access to port 80 in general.

Deleting Rules

To delete rules, it makes the most sense to first look at all of your rules and then delete them by number.

sudo ufw status numbered

Linux UFW

To delete the FTP(21/TCP) rule indicated by the number 2 in the screenshot above, we can simply do:

Linux UFW 2

Doesn’t get much easier than that, does it?

Disable or Reset the UFW

In case you want to start fresh or disable the UFW altogether, it’s simply achieved by doing:

sudo ufw disable


sudo ufw reset

It is indeed pretty useful to know your way around in the UFW, especially if you live stream Hacking as I do.


Now, because I do not have a static IP, I set up my VPS to only allow access from my DynDNS name, which exceeds the capabilities of UFW. UFW is basically just an interface for IPTables, and you can do way more specific stuff using the latter.

To achieve what I wanted, I needed to add an IPTables rule.

sudo iptables -A INPUT -p tcp --src YourDynDNSName --dport 22 -j ACCEPT

With this, the server would only allow incoming connections on port 22 from the DynDNS Name that ultimately resolves to my IP Address. Cool!

There is a problem tho, this rule would be gone after a reboot. To circumvent this, we have to install iptables-persistent to save the rules after a reboot. That’s the easy part.

sudo apt install iptables-persistent

After the installation, the tool asks you if you want to save your IPTable rules now. Nice!

Now there is a more complicated problem. This would add your CURRENT IP to IPTables, once your IP gets updated after a 24h disconnect, you would need to re-create this rule to update to the new IP address as well.  I found a script on StackExchange that helps us circumvent this as well.

Create a new bash script named iptables_update.bash


if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root"
   exit 1

new_ip=$(host $HOSTNAME | head -n1 | cut -f4 -d ' ')
old_ip=$(/usr/sbin/ufw status | grep $HOSTNAME | head -n1 | tr -s ' ' | cut -f3 -d ' ')

if [ "$new_ip" = "$old_ip" ] ; then
    echo IP address has not changed
    if [ -n "$old_ip" ] ; then
        /usr/sbin/ufw delete allow from $old_ip to any port 3000
    /usr/sbin/ufw allow from $new_ip to any port 3000 comment $HOSTNAME
    echo iptables have been updated

Save the script and run chmod to give it execute permissions

sudo chmod +x iptables_update.bash

Now copy the script to your /etc/ directory

sudo mv iptables_update.bash /etc/

After this is done, we create a new Cronjob that executes this script every 5 minutes, which means that your DynDNS IP address gets updated every 5 minutes, awesome!

sudo nano /etc/crontab

And add the following line on the bottom of the other rules:

*/5 * * * * root /etc/iptables_update.bash > /dev/null 2>&1

Boom! DynDNS access finished. That was cool to learn for me. Let’s move on.

Burp Collaborator

I learned a couple of things that help me to understand Burp Collaborator better again. I love Collaborator. Below are my raw notes.

  • Requests sent to Collaborator are randomized (xxx1.burpcollaborator.com xxx2.burpcollaborator.com, etc)
  • Requests can get picked up much much later
  • Running BIND9 DNS makes a lot of sense

I want to dive into those sweet XXE’s so bad baby!


Now, I create my Recon script in Python3. There will be a guide very soon that covers exactly that, so I won’t go into the details too much in here. There is just one thing that I have learned that I want to show you.

        "echo hello{jim} and also hello to you {joe}".format(jim=jim, joe=joe), shell=True)

I learned that multiple arguments can be used within one line of code, specifically (jim=jim, joe=joe). Those relate to actual variables. So far, I thought I can only use one of them per line, only jim for example. Turns out, you can use as many as you want. This is very useful when creating a Recon script. It will make more sense after you have watched the accompanying video to this article where I will go more in-depth into this command.

Conclusion Week #19

This concludes what I have learned in Week #19 of 2020. Turned out to be a longer article after all. I really have spent a ton of time in the last few months studying those topics and creating content. I am at a point where I start to feel burned out, and when I feel like this, it’s time for a break. Which means, the next part of the Ethical Hacking Diaries will be probably one week delayed or put together with week 20 + 21.

I decide to take the entire next week off of computers to reset myself and get excited again about Bug Bounties and creating content. Mental Health is the most important part of my life and when I start to feel worn out, I pull the break.

I hope you understand and I hope to see you back in the next Episode of the Ethical Hacking Diaries.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share via
Copy link
Powered by Social Snap