ziltoid firewall rules
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
cameron 10cedb8139 Made a few hosts accessible from the outside 2 months ago
.gitignore Added makefile to gitignore 3 years ago
README.md added readme 2 years ago
rules.temp.v4 Add rule for MineTaft 10 months ago
rules.v4 Made a few hosts accessible from the outside 2 months ago
rules.v6 Commenting out lines that don't apply anymore 2 months ago

README.md

firewall

This is the iptables firewall rules for Ziltoid (the firewall)

Instructions to edit rules

The way that you update the configuration file is as follows:

  1. Evaluate the security implications of your service. This is the PUBLIC INTERNET. If you don’t need public SSH, please put it on port 13699. You can specify multiple listen addresses in sshd for example (the Port: #### directive), so that it listens on 22 and 13699 in the labs, and just 13699 from externally. You can also use the VPN or Ziltoid.
  2. Clone down the repository locally to your computer
  3. Ad the changes you want. The standardized format is as follows:
# Device Name (IPv4 address)
# External Access: [List of Service (port number if unusual port or uncommon service)
[list of the iptables rules]
  1. Commit your changes with a meaningful Git message. For example, “Added random.cosi.clarkson.edu SSH”
  2. Log into Ziltoid. As your user (do NOT use sudo!), cd /etc/iptables. Once you do that, run make. Make will do the following things:
    • runs git pull to pull the repository. Typically, this will request your Git server creds.
    • runs sudo iptables-restore < rules.v4. This will ask for your sudo password.

Crisis mode

iptables -S Shows config (ish)

iptables -L Lists rules

iptables -D <rule> Deletes a rule

iptables -A <rule> Adds a rule

iptables -F Clears the entire table USE WITH CAUTION

Ways to improve

Currently, we don’t have a failure mode protection system. If you push a bad config, there is no rollback mechanism other than rolling back the commit, and if you loose connection, that’s it.

This could be implemented better in the future. In the past, we have just been very careful to know exactly what to apply, but not all people are god-tier at iptables configs, so this would probably be beneficial in the future.

Presumably, a way to do this would be as follows:

  • make sync Pull down the latest config
  • make test Apply the latest config, but do not write it out to rules.v4, but rather a different file, and to resync from the existing config if make apply is not run within 5 minutes`.
  • make apply Apply the latest config, and set it to be applied on reboot.
  • make Run make sync test equivelant.