[How to] Configures Iptables with INPUT rules (with dynamic NBD)


#21

By the way, I’ve used your slightly modified code in Shorewall’s /etc/shorewall/started post script:

#!/bin/sh

for ip in $(/usr/local/bin/oc-metadata | sed -nE 's/VOLUMES_[0-9]+_EXPORT_URI=.*nbd:\/\/([^:]+):.*/\1/p');
do
    iptables -I INPUT 1 -i eth0 -s $ip -j ACCEPT
done

(and chmod +x /etc/shorewall/started to make it executable).

I had to ensure that this was at the top of the INPUT chain, so used -I instead of -A. I’m sure someone can come up with a more elegant Perl version that makes use of Shorwall’s functions directly, but this was sufficient for me.

Hopefully that’ll help someone, and will also put an end to the /nbd0 IO / RO errors I seem to be generating (did see the post regarding 3.2.34 kernel, which I am using).


#22

Hey,

I came across this thread while configuring UFW (an iptables wrapper) on Ubuntu 14.04, and I found a somewhat different solution to the problem of NBD connections dropped by the packet filter.

Per default UFW inserts a rule allowing traffic for already established connections (iptables -A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT). This also covers NBD connections since they are established during boot, before the packet filter is active. So everything should be fine, and you shouldn’t need a custom INPUT rule allowing NBD traffic.

However, when you activate UFW it also sets the default policy for INPUT to DROP, causing NBD connections to be dropped before the above rule is activated. This causes the server to crash. Here’s what I did to fix this:

  1. Set the default INPUT policy to ACCEPT: Edit /etc/default/ufw and set:

    DEFAULT_INPUT_POLICY="ACCEPT"
    
  2. Append a drop-all rule to the INPUT chain: Edit /etc/ufw/after.rules, add this line just before the final COMMIT line:

    -A ufw-reject-input -j DROP
    
  3. Disable UFW logging (this seems to cause issuses with Scaleway’s default kernel):

    ufw logging off
    
  4. Enable UFW (don’t forget to allow SSH traffic):

    ufw allow ssh;
    ufw enable
    

That’s it, UFW is up and running, and NBD shouldn’t cause issues.


UFW Ubuntu 16.04
Enable ufw in Debian or Ubuntu results in lock out
UFW Ubuntu 16.04
Can't mount nbd0 after reboot
Setting up firewalls using UFW
How to attach and detach additional volumes to an existing C1 server | Scaleway
#23

Hey Thomas,

that’s a very good solution for UFW users, thanks! I can confirm that it’s working on ubuntu 14.04 servers on Scaleway. Even after rebooting the system.


Can't enable ufw firewall on Ubuntu 16.04 Baremetal server
#24

There is no way to have the activated log?


#25

Hi,

For some reasons, my ufw is up and running with @Thomas method but I can’t add a rule for a specific ip to a specific port :

ufw allow from xxx.xxx.xxx.xxx/32 to any port xxx proto tcp

does not work even if the rule seems up on ufw status :

To                         Action      From
--                         ------      ----
xxxx/tcp                   ALLOW       xxx.xxx.xxx.xxx

Any ideas ?


#26

thank you it’s working :slight_smile:


#27

Bonjour Xavier,

que faut-il ajouter d’autre pour activer une règle default output drop ?
Avec cela (mixé avec votre config) la connexion freeze. J’ai manifestement de … truc dans les yeux

iptables -A INPUT -i eth0 -s $fbx -j ACCEPT

iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

iptables -P INPUT DROP
#iptables -P OUTPUT DROP

Merci, A+,
Gilles


#28

I can’t make it work. How could you do it?


#29

Hello Thomas,

Thank you for your contibution.
To stay closer to the ufw philosophy to have INPUT with DROP policy, I did modified your point 2:

Append a drop-all rule to the INPUT chain: Edit /etc/ufw/after.rules, add this line just before the final COMMIT line:

-P INPUT DROP


#30

Great ,you have saved my life!


#31

From a quick test, the “-P INPUT DROP” line by itself does not appear to be enough … that line alone does not block incoming traffic, whereas the original “-A ufw-reject-input -j DROP” works fine for me … have I done something wrong, or should both lines be added?

One remaining wrinkle is that “ufw status verbose” indicates that the default incoming policy is accept (I guess it just reads this from its defaults file) whereas thanks to this final line in fact the default policy is drop! This might confuse! I wonder how to get ufw to report the true state of affairs!

Anyway, thanks to everybody here for the information, which has allowed me to bring up UFW on a scaleway C1 ARM server running Ubuntu 14.04LTS without taking the machine down in the process :slight_smile:


#32

Make sure to allow that IP from the Scaleway Firewall too.


#33

The code from Thomas does not work anymore at least not with Ubuntu 16.04


#34

Thanks a lot, you saved me a lot of time. You should write a How-To!


#35

Well that’s good to know, but now I already screwed this up by enabling UFW, which then interrupted my ssh session. I rebooted, and only had access to a read-only filesystem. The I rebooted into the rescue image, and now I can’t mount the nbd0 device due to the “superblock error”, see Can’t connect via SSH

I really want to fix this, because I really don’t want to have to set up that server from scratch again.


#36

Hello Thomas,

Thank you for your solution to UFW users.

I confirm that your solution is working but when i reboot the server it cause a kernel panic just before syncing disk

My instance type is C2L and my system is Debian 9.


#37

Merci beaucoup de l’aide !!
Ça devrait être visible quelque part car ufw est quasiment un standard à ce stade.


#38

@vad1mo
It is working for me !


#39

Seems to be working also on my fresh U18.04 C1… but I haven’t had the guts to reboot it yet, especially as the serial console doesn’t seem to work :slight_smile:


#40

I confirm it also works on U18.04 C2S even after reboot. Thanks!