consider including ufw in appliances?!

[JedMeister]

[update] As noted below, on further investigation, I have concerns about potential conflict with Webmin firewall. @mitchellurgero has suggested a nice compromise: Provide a script to easily install and configure ufw. We could also have a confconsole plugin to leverage that script to make it super simple for users to install.

---

I recently stumbled across the work that @mitchellurgero has been doing (based on TurnKey).

I've invited him to come and work a bit more closely with us on future developments, so hopefully we may see him about a bit! :smile:

One thing I did notice was that he's including ufw. On face value, I thought that it was more-or-less a redundant addition as we already leverage iptables and the webUI (in Webmin) works quite well.

After a brief google, my position is much softer. It's appears to be a very nice and quite intuitive commandline interface for iptables. Considering that it's in the Debian repos, is quite small (~800kb installed) and shouldn't require us to install any additional dependencies.

I'd like to hear more thoughts from others about pros and cons for adding ufw to v15.0!

[mitchellurgero]

I was using UFW because by default I want to not allow access to webmin - This is because my TKL VM's in my own infrastructure are directly connected to the internet (as in ufw/iptables is the only firewall I have) so restricting access was something I wanted to do personally. I can go into specifics of what, how, and more of the why when I have a bit more time. :)

EDIT 1: UFW is an amazing command line tool for IPTables. It has simple syntax (ufw allow 22) as an example. This allows an admin (who maybe doesn't like webmin, or just doesn't want to have an "extra risk" on their server so to speak to easily just allow/deny ports, ip address, networks, etc using iptables which TKL already leverages! :D If you go on github.com/mitchellurgero/tkl-gnusocial as an example you will see the setup is simple, add to plan/main, add a few lines to conf/main like ufw enable --yes and ufw allow :PORT: and boom done. I leverage this in my appliances by only allowing essential ports and then informing the admin (via the confconsole as well as README.MD) that webmin, adminer, webssh, etc etc are blocked by default (reason listed above). UFW just allowed me to quickly fine tune iptables reliably without needing webmin.

I did however keep webmin for those who want/use it. (I don't personally as I see it as just another point of exploit but I am also much more paranoid about security than most). ufw doesn't require much as you pointed out, but it also doesn't need more than maybe half a meg of RAM too while in use. I'd say it's worth the inclusion for those who want it, at the very least include it on appliances like wordpress, LAMP, etc since those appliance can be reasonably assumed to be accessible directly from the web.

[DocCyblade]

@JedMeister - I also use ufw on my internet VPS. I give it a thumbs up

[ghost]

Probably the most user friendly firewall available. I see it shining if implemented into confconsole options. With a few simple confconsole options we could give users easy control over firewall options through a menu locking down or opening up default appliance ports. Not much use for those famiiar with iptables, but very useful for less tech savvy users. Arguably this could be done with just iptables as well. I concur with @mitchellurgero on the appliances directly accessible from the web. Could even make the default option prevent access on applicable appliances with confconsole option to enable access should the user desire to.

I have to get "smart" on the confconsole options for the TVheadend appliance I am working on and could look into doing the confconsole plugin for firewall if desired.

[JedMeister]

I've had a bit of a look at this and whilst it does seem like a cool thing, it can be added quite easily via apt. Seeing as the images have grown quite a bit for the v15.0 release, I'm quite loathe to add more stuff that may or may not be used by many users. I was tempted to close it, but I think it's worth having some more discussion so I'm just going to repin it to v15.1.

[mitchellurgero]

UFW is only a meg or so for the install - and I believe to be worth the install especially since it can be used CLI and in Webmin (AFAIK) any admin worth their lick in the IT field will want a firewall, and IPTables (UFW's backend) is a perfect way to do basic, and even some advanced firewalling, for new comers and sys admins alike.

[JedMeister]

Agreed that it's not that big so isn't a huge amount of extra size.

However, it's another frontend for IPTables so may have unintended consequences when used in combination with Webmin (which uses IPTables directly) or if IPTables itself is used directly.

I'm not against including it, but until we can do some more testing of what side effects there may be with our current use of IPTables I don't really want to risk it this close to an already well overdue release.

[mitchellurgero]

Having it included will not damage anything - at the very least I think a script could be included that installs, and configures UFW with the standard ports used in TKL.

[JedMeister]

Hi @mitchellurgero - apologies on my radio silence. I've been trying to laser focus on getting v15.0 finalised ASAP (it's been dragging soooo long). We getting there now though...

The issue that I have with including ufw by default is that it somewhat clashes with the Webmin firewall (that leverages IPTables direct). I haven't done extensive testing, but it appears that if a user uses ufw to adjust firewall rules, but then uses Webmin firewall, the Webmin rules will overwrite all ufw settings and take precedence.

This may not be expected or understood by users and IMO may cause issues. My thought is that if a user wants ufw and manually installs it, they are more likely to consider whether there may be a clash (and are also probably much less likely to use Webmin anyway). Having said that, I don't know for sure and it's only my opinion.

I'm not sure that it's a great idea, but one way we could go is have a simple bash wrapper around ufw that provides a warning re Webmin. Essentially just a bash script (i.e. /usr/local/bin/ufw) that echos a warning re potential conflict with Webmin, then passes all arguments (untouched) to the "real" ufw.

However, your suggestion on making it easy to install ufw and cover default turnkey ports is probably a better idea! We could also add a warning note re webmin as part of that process. That would allay my concerns. I might add a note to the top of the OP on this issue. If we can develop a simple script for that (plus a confconsole plugin too?) it'd be awesome to include it for v15.1.

[mitchellurgero]

@JedMeister That's an interesting take - as far as compatibility, Webmin overwrites all IPTables rules when it saves (It calls iptables -f then iptables-restore).

That being said, even if you decide not to include it, I think block webmin to only be accessible via the local network (which can be gotten by using the netmask and ip address of the first available eth device) so that TKL appliances deployed on VPS's (which are not firewalled normally by default) are not exposing a critical port to the internet.

[JedMeister]

as far as compatibility, Webmin overwrites all IPTables rules when it saves (It calls iptables -f then iptables-restore).

TBH, I hadn't checked the mechanics, just saw the effect.

I think block webmin to only be accessible via the local network (which can be gotten by using the netmask and ip address of the first available eth device) so that TKL appliances deployed on VPS's (which are not firewalled normally by default) are not exposing a critical port to the internet.

But if a server is running remotely, then wouldn't that just block access to Webmin completely? Also FWIW most TurnKey users running on "VPS" use Amazon. Our AMIs have pre-configured "security group". It's not ideal, as it listens to all addresses.

We take security seriously, but we're in a bit of a bind as much of our userbase tend be relatively newbish and demand "user friendly".

Having said that, we'd certainly like to attract more seasoned users and developers. So having it super quick and easy to "lock things down" could assist that end?!

Your suggestion on making it super easy to install ufw, could nicely complement a confconsole plugin to lock down Webmin (or perhaps even shut it down altogether for users who don't intend to use it).

[mitchellurgero]

Yea - at the very least, allowing the removal of Webmin, and install of ufw would be nice through confconsole.

[JedMeister]

(Oops just realised I neglected to post this earlier...)

This is (or at least could be) related to the Webmin component of #1194

As per that one, I'd love to add this for v16.0 but I'm running out of time.

To do this properly, I need to have a better understanding of both ufw config and the underlying functionality of Webmin's iptables integration (and how their respective configs can be switched back and forth, thus we can then switch between them.

Then re #1194 - we could install (or at least offer to install) ufw if Webmin is disabled!?

[JedMeister]

I still think that there is value in this, but with the potential clash between Webmin and ufw, I'm not really keen at this point.

Let's revisit in v17.0.