always allows port 22

[BenGardiner]

https://github.com/reap3r/firewall/blob/82cdd5a3455fa5d72630ecdabefba705507d84b4/appliance/src/rules_scheduler.py#L52

I am naive as per the system requirements; so I ask this question from a place of ignorance. Do we need to always allow port 22 (presumably for ssh)?

If there are any cases in deployment where a system can live without it then we should block it if we can (e.g. a .conf variable). Ssh servers aren't always perfect, reducing surface is good.

[callrbx]

resolved. now only allows the management port specified in the config file

[BenGardiner]

https://github.com/reap3r/nmfta-bouncer/blob/master/appliance/src/rules_scheduler.py#L55

I think this might drop active remote management connections because the allow/enable sequence here isn't quite what is reccomended by the ufw readme on remote management:

Remote Management
-----------------
On /lib/ufw/ufw-init start and 'ufw enable' the chains are flushed, so
ssh may drop. This is needed so ufw is in a consistent state. Once the ufw is
'enabled' it will insert rules into the existing chains, and therefore not
flush the chains (but will when modifying a rule or changing the default
policy).

You can insert rules before enabling the firewall however, so it is often
a good idea to to:
# ufw allow proto tcp from any to any port 22
# ufw enable

In this case, the chains are still flushed, but the ssh port will be open
after enabling the firewall.

cc @krishnaswin

[krishnaswin]

Based on the logic that I see implemented, I don't think the Rules Scheduler should be managing the IP Address and Ports that runs the REST interface, it should be managed by Network Admin. I propose to remove lines 55 and 56 from source.

[BenGardiner]

I tend to agree; the sysadmin should be responsible for configuring and maintaining any system maintenance interfaces.

Since the rules execution will change firewall rules; there should be some pre- or post- rules file mad available to the sysadmin so they can hook firewall rules execution to ensure they don't get locked out

[krishnaswin]

removed lines that automatically opened port for REST interface.

[krishnaswin]

leaving this assigned to chad to create a shell script that will add the rules to open the port necessary for hosting the REST interface

[BenGardiner]

removed lines that automatically opened port for REST interface.

I'm concerned, I think there is a problem with the state of the code after e746482e4db3b1271f2821df9a4e19c1041b66b1 ; please correct me if I'm wrong:

without the ufw 'hole' added for 22; the firewall rules configured and executed by Bouncer could lock-out ssh access. And (not that e746482e4db3b1271f2821df9a4e19c1041b66b1 changed this) the same is true of :8080 access to the Bouncer REST interface.

Adding ufw holes to a startup or other script outside of Bouncer's execution will end up with those holes being clobbered by the firewall rules configured and executed by Bouncer.

To enable sysadmins to be responsible for management interfaces and access, don't we need to provide a 'hook' so that the sysadmin script is executed before the firewall rules configured and executed by Bouncer?

[krishnaswin]

the rules scheduler does not update any rules not directly set by the REST API (i.e entries present in the SQL Lite database) so we should be fine in this regard. Since the requirement for the Appliance API is to only manage blacklists and whitelist IP Addresses not Ports we should look into adding a validator to make sure the entries in the database table are in fact a valid IP Address

Similarly its probably worth adding a hook to make sure the REST API is not messing with a system controlled entries in ufw. This hook will be called before a call is made to update an ufw entry

[BenGardiner]

Thank you Krishna. The validator and hook sound like a good plan to me.