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!
https://www.youtube.com/watch?v=Rm4I7MGKdPY
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
Alternatively
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
To delete the FTP(21/TCP) rule indicated by the number 2 in the screenshot above, we can simply do:
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
Or
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.
IPTables
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
#!/bin/bash
HOSTNAME=YOUR.DNS.NAME.HERE
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root"
exit 1
fi
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
else
if [ -n "$old_ip" ] ; then
/usr/sbin/ufw delete allow from $old_ip to any port 3000
fi
/usr/sbin/ufw allow from $new_ip to any port 3000 comment $HOSTNAME
echo iptables have been updated
fi
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!
Python3
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.
subprocess.call(
"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.