ssh - UFW default rules... where are they?

05
2014-04
  • The Quantum Physicist

    In the tutorial on UFW here

    https://help.ubuntu.com/community/UFW

    it says that UFW uses the default rules if enabled and not configured. I checked the folder:

    /etc/ufw/

    and the files I found there are

    after.rules
    after6.rules
    before.rules
    before6.rules
    sysctl.conf
    ufw.conf

    So where are the "default rules"? There are 4 different rules files, and I don't know which on is the one it's gonna choose if I enable it.

    I'm afraid if I enable it, it would just block port 22 and I'll lose SSH connection to my server, which is not easy to recover from.

    How can I safely start the firewall?

    • Answers
  • MariusMatutiae

    You may enable UFW, and then issue these commands: 

       sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
   sudo iptables -A INPUT -p tcp --dport ssh -j ACCEPT

    This will surely allow ssh. If you like the setup, yu can write these two lines inside the file /etc/rc.local, and they will be applied at boot (no need of sudo, in this case).

    EDIT

    There are basically three files of importance, in /etc/ufw: sysctl.conf, after.rules, before.rules. The remaining files concern rules for IPv6 (after6|before6.rules), the definitions of the port used by a handful of applications (in the subdirectory ./applications.d), and the file to start ufw, ufw.conf.

    sysctl.conf completely replaces /etc/sysctl.conf, it is thus just a duplicate. It contains information for the kernel that is intended as a set of security measures.

    The rules are separated in before and after (the lines entered from the command line), because the order matters: when reading a series of rules, the firewall will apply the first rule that is relevant, whether that be ACCEPT, DROP, or whatever; the remaining rules are then not even read. It follows that very specific rules precede general rules.

    The before rules are simple: they allow loopback and ICMP (=pings), drop INVALID packets, allow passage of packets if the conversation has already begun (the equivalent of my rule 1 above), allow DHCP, and local traffic, which is bsolutely essential for the operation of the LAN, i.e. especially network discovery, multicast and broadcast.

    The after rules only prevent logging of ports which produce too much material.

    A single rule can be read as follows:

       -A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

    This adds (-A) to the table before-input the rule that ACCEPTs packets of protocol UDP which originated (sport= source port) from port 67 and which are destined for port 68 (dport= destination port). This table is read on INPUT, so that it is ignored whenever the kernel is dealing with an OUTPUT or a FORWARD packet (both types of packets are going out, but OUTPUT packets originated on this machine, while FORWARD packets originated elsewhere and are moving on to their final destination).


    • Related Question

    firewall - UFW as an active service on Ubuntu
  • lamcro
    • Every time I restart my computer, and check the status of the UFW firewall (sudo ufw status), it is disabled, even if I then enable and restart it.
    • I tried putting sudo ufw enable as one of the startup applications but it asks for the sudo password every time I log on, and I'm guessing it does not protect anyone else who logs on my computer.

    How can I setup ufw so it is activated when I turn on my computer, and protects all accounts?

    Update

    I just tried /etc/init.d/ufw start, and it activated the firewall. Then I restarted the computer, and again it was disabled.

    content of /etc/ufw/ufw.conf

    # /etc/ufw/ufw.conf
# 

# set to yes to start on boot
ENABLED=yes

# set to one of 'off', 'low', 'medium', 'high'
LOGLEVEL=full

    content of /etc/default/ufw

    # /etc/default/ufw
#

# Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
# accepted). You will need to 'disable' and then 'enable' the firewall for
# the changes to take affect.
IPV6=no

# Set the default input policy to ACCEPT, ACCEPT_NO_TRACK, DROP, or REJECT.
# ACCEPT enables connection tracking for NEW inbound packets on the INPUT
# chain, whereas ACCEPT_NO_TRACK does not use connection tracking. Please note
# that if you change this you will most likely want to adjust your rules.
DEFAULT_INPUT_POLICY="DROP"

# Set the default output policy to ACCEPT, ACCEPT_NO_TRACK, DROP, or REJECT.
# ACCEPT enables connection tracking for NEW outbound packets on the OUTPUT
# chain, whereas ACCEPT_NO_TRACK does not use connection tracking. Please note
# that if you change this you will most likely want to adjust your rules.
DEFAULT_OUTPUT_POLICY="ACCEPT"

# Set the default forward policy to ACCEPT, DROP or REJECT.  Please note that
# if you change this you will most likely want to adjust your rules
DEFAULT_FORWARD_POLICY="DROP"

# Set the default application policy to ACCEPT, DROP, REJECT or SKIP. Please
# note that setting this to ACCEPT may be a security risk. See 'man ufw' for
# details
DEFAULT_APPLICATION_POLICY="SKIP"

# By default, ufw only touches its own chains. Set this to 'yes' to have ufw
# manage the built-in chains too. Warning: setting this to 'yes' will break
# non-ufw managed firewall rules
MANAGE_BUILTINS=no

#
# IPT backend
#
# only enable if using iptables backend
IPT_SYSCTL=/etc/ufw/sysctl.conf

# extra connection tracking modules to load
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc"

    Update

    Followed your advise and ran update-rc.d with no luck.

    lester@mcgrath-pc:~$ sudo update-rc.d ufw defaults
update-rc.d: warning: /etc/init.d/ufw missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/ufw ...
   /etc/rc0.d/K20ufw -> ../init.d/ufw
   /etc/rc1.d/K20ufw -> ../init.d/ufw
   /etc/rc6.d/K20ufw -> ../init.d/ufw
   /etc/rc2.d/S20ufw -> ../init.d/ufw
   /etc/rc3.d/S20ufw -> ../init.d/ufw
   /etc/rc4.d/S20ufw -> ../init.d/ufw
   /etc/rc5.d/S20ufw -> ../init.d/ufw

lester@mcgrath-pc:~$ ls -l /etc/rc?.d/*ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc0.d/K20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc1.d/K20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc2.d/S20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc3.d/S20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc4.d/S20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc5.d/S20ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 13 2009-12-20 20:34 /etc/rc6.d/K20ufw -> ../init.d/ufw

    • Related Answers
  • mac

    I remembered that in my frustration of not having the ufw stick as "active" on startup I repeatedly bypassed the 10 second grub countdown immediately as I rebooted to check the results of the earlier suggestions.

    I wondered, since it was mentioned that the script ran at startup, if I was somehow cutting off the script before it could execute. Not so. ufw "active" still appears to stick after choosing ubuntu 9.1 the moment grub pops up.

    It would appear that there was some conflict between ufw's default startup and one or both of Firewall Configuration or Firestarter. Uninstalling them seems to have fixed my problem.

    Hopefully this works for others as well.

  • quack quixote

    The UncomplicatedFirewall docs and a related UbuntuForums post suggest sudo ufw enable is all you need to do for UFW settings to persist across reboots.

    But you indicate that running sudo ufw status after doing an enable still shows the firewall as disabled. ... If true, this indicates something is broken.

    Does it help if you run /etc/init.d/ufw start (or restart)? Have you tried installing the gufw GUI (via Synaptic or other package manager) and configuring with that?

    Please edit your question and include the content of /etc/default/ufw and /etc/ufw/ufw.conf.

    Update:

    OK. Running the init script works, so it appears the service isn't getting started at boot-up properly. It's hard to say exactly why, but I'd bet some inconsistency between Jaunty and Karmic that got confused during the dist-upgrade.

    Use update-rc.d (more info) to create the startup links in the right place:

    sudo update-rc.d ufw defaults

    Then verify that the startup script links have been created:

    ls -l /etc/rc?.d/*ufw

    -- you should get a list of symbolic links like this (or very similar -- the numbers in the link name could be different):

    lrwxrwxrwx 1 root root 17 2009-10-06 22:33 /etc/rc1.d/K01ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 17 2009-10-06 22:33 /etc/rc2.d/S99ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 17 2009-10-06 22:33 /etc/rc3.d/S99ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 17 2009-10-06 22:33 /etc/rc4.d/S99ufw -> ../init.d/ufw
lrwxrwxrwx 1 root root 17 2009-10-06 22:33 /etc/rc5.d/S99ufw -> ../init.d/ufw

    If those are in place, your firewall should get started automatically next time you reboot.

    Update 2: I updated the update-rc.d line above; the old should work but I think this version is a bit more "proper". The old probably won't create the K01ufw links.

  • Area 51

    I've been having the same issue - very frustrating since this is my first foray into making a linux my main os. I tried the solutions presented here with the same negative results.

    However, for some reason I decided to try something else and it looks like it worked...

    I'm not sure whether it was a combination of the two or just removing one but I removed/uninstalled both the Firestarter and Firewall Configuration Tool. I then did the sudo ufw enable once again and rebooted.

    Now it seems to stick. I've rebooted several times with the same results. sudo ufw status comes up active after every bootup now.

    However - I have one more thing to test... be back in a second...