Iptables for dummies?
- Thread starter clayop
- Start date
flare
Well-known member
The rules from https://darkcointalk.org/threads/drk-guide-rc5-masternode-windows-local-linux-remote-vultr.1367/
step 2 are a good starting point, they will close all ports but 9999 and 22.
But you don't want to do a hot masternode, really ;-)
Test my hosting service instead ;-)
https://darkcointalk.org/posts/25008/
Ignition75
Active member
I had someone with good Linux knowledge setup an image for me that I'm using with all my hot nodes on Digital Ocean. It uses CSF which is a user friendly firewall program that configures iptables for you with a few quick commands.
I also have a dynamic IP and I like it that way. Whenever it's time to upgrade my nodes, I connect through Digital Ocean console, allow my IP through the firewall on each node, then connect through putty and my ftp program to complete the upgrade process.
If you would like to PM me your user ID on Digital Ocean I can send you the build, it cost me 15 DRK but you can have it for free. And I've got a process you can have which was given to me also, just to make sure you are setting correct permissions on files and clearing bash before you log off etc etc...
I also have a dynamic IP and I like it that way. Whenever it's time to upgrade my nodes, I connect through Digital Ocean console, allow my IP through the firewall on each node, then connect through putty and my ftp program to complete the upgrade process.
If you would like to PM me your user ID on Digital Ocean I can send you the build, it cost me 15 DRK but you can have it for free. And I've got a process you can have which was given to me also, just to make sure you are setting correct permissions on files and clearing bash before you log off etc etc...
Ignition75
Active member
Why not Flare? As long as wallet encryption holds you're OK aren't you? I've had many people tell me not to run a hot node but I didn't trust them like I trust your opinion...
flare
Well-known member
I am a bit paranoid on this
If there ever is a weakness found in the darkcoin protocol (buffer overflow or alike) a attacker could gain remote access to the host. If then you missed to clear the bash history (things happen) or there are traces of the password left in memory you are cursed.
I am not saying that it's likely to happen, but why dance with the devil if there is a secure solution (HotCold-setup) available? Just for convenience?
Ignition75
Active member
I'm running a few nodes, I heard it's a pain in the arse to update if you've got cold wallets...I am a bit paranoid on this
If there ever is a weakness found in the darkcoin protocol (buffer overflow or alike) a attacker could gain remote access to the host. If then you missed to clear the bash history (things happen) or there are traces of the password left in memory you are cursed.
I am not saying that it's likely to happen, but why dance with the devil if there is a secure solution (HotCold-setup) available? Just for convenience?
flare
Well-known member
I think it's worth the extra bit of security
Ignition75
Active member
OK... I have quite a few masternodes now... I shall investigate cold wallets...
Stuff iptables...
as root, or add a sudo before each command if not:
Firewall done.
as root, or add a sudo before each command if not:
Code:
apt-get install ufw
ufw allow ssh
ufw allow 9999/tcp
ufw logging on
ufw enable
ufw statusFirewall done.
Figlmüller
Member
Hi,
For iptables I would also recommend to limit the rate of TCP connections and to drop packets with illegal states and prevent SYN flodding.
I never heard of ufw until now, but according to the manual you can limit the rate by simply executing "ufw limit". For example, "ufw limit SSH" will limit the amount of of requests (to 6 per 30 seconds with the default setting afaik).
Also, limiting SSHD to your local IP is a good idea in combination with OpenVPN to get access to SSHD and other management related tools, webinterfaces, etc. from other IPs.
If you are using a virtualization solution such as VMWare ESXi, or XenServer you can also set up a virtual management network which can only be accessed through a gateway instance responsible for routing and hosting OpenVPN. All the servers then host their important management services on a second network card within the virtual management network:
So to attack any kind of management service you first have to break into the virtual LAN.
I use to connect the virtual networks of many hypervisors (not physically located at the same place) using dedicated VMs as a bridge and firewall.
As for iptables: They a pretty straight forward.
That's how it works:
There are many kind of tables, most often you will use the filter table.
Every table has so called chains, by default INPUT, OUTPUT, FORWARD.
Once a packet gets processed by the kernel, it will jump to the appropriate chain and match the rules.
You can either ACCEPT a packet, DROP a packet, REJECT a packet or...
If none of the rules match, the chains default policy will be applied.
You can also jump to other chains, exit the current chain - It's like a book. You start at the top and go through everything - maybe you have to jump back, etc.
So if you get a TCP packet to your INPUT chain, you may want to check the tcp flags and states. You can write an own chain for that. Then you may want to jump to another chain checking for floods,...
For iptables I would also recommend to limit the rate of TCP connections and to drop packets with illegal states and prevent SYN flodding.
I never heard of ufw until now, but according to the manual you can limit the rate by simply executing "ufw limit". For example, "ufw limit SSH" will limit the amount of of requests (to 6 per 30 seconds with the default setting afaik).
Also, limiting SSHD to your local IP is a good idea in combination with OpenVPN to get access to SSHD and other management related tools, webinterfaces, etc. from other IPs.
If you are using a virtualization solution such as VMWare ESXi, or XenServer you can also set up a virtual management network which can only be accessed through a gateway instance responsible for routing and hosting OpenVPN. All the servers then host their important management services on a second network card within the virtual management network:
So to attack any kind of management service you first have to break into the virtual LAN.
I use to connect the virtual networks of many hypervisors (not physically located at the same place) using dedicated VMs as a bridge and firewall.
As for iptables: They a pretty straight forward.
That's how it works:
There are many kind of tables, most often you will use the filter table.
Every table has so called chains, by default INPUT, OUTPUT, FORWARD.
Once a packet gets processed by the kernel, it will jump to the appropriate chain and match the rules.
You can either ACCEPT a packet, DROP a packet, REJECT a packet or...
If none of the rules match, the chains default policy will be applied.
You can also jump to other chains, exit the current chain - It's like a book. You start at the top and go through everything - maybe you have to jump back, etc.
So if you get a TCP packet to your INPUT chain, you may want to check the tcp flags and states. You can write an own chain for that. Then you may want to jump to another chain checking for floods,...
Last edited by a moderator:
