UFW, fail2ban, and Ansible have all been mentioned, which gives me an opportunity to mention a Hugh-like "war story" related to hardening. It appears that Debian 9 (aka "stretch," which is now "stable") included a stupid-ass version of fail2ban. Our cloud machines have always included a kitchen-sink jail.local, including blocks for PHP and MySQL (although we have yet to use either of them) because fail2ban always just logged warnings on start-up and went about its business. The version of fail2ban in Debian 9 doesn't warn when it finds a non-existent log file in the config: it errors out completely and refuses to start. This is a known issue that the devs "just haven't had time to fix." (I blame the fail2ban devs less than the Debian devs, who shouldn't have included this version of fail2ban.) Anyway, one of the options we looked at as a replacement/supplement/alternative was UFW's rate limiting feature. But since UFW is meant to be simple, it's totally unconfigurable. After six connections in 30 seconds, an IP is blocked for 30 seconds or a minute. Note - I didn't say "six failed connections," which I read by implication because that would have been sane (at least for ssh). Imagine using Ansible with that rule being enforced. For those not familiar, Ansible makes several SSH connections PER SECOND. Ansible gets itself banned by the time it's done "gathering facts" (essentially the setup phase, before it does any of the stuff you were trying to achieve in the script). We disabled that little fix in a hurry. For the person with the original question: UFW is fairly good, although simplistic. But don't use its rate-limiting feature. Fail2ban seems to be a reasonable product, but you'll have to hand-craft your configs - no cut-and-paste a "secure version" from the internet, at least not if you're using Debian (which I would also recommend). You should also keep a close eye on the security advisories for your OS (and apply them). For Debian, that's https://www.debian.org/security/ . We have it feed notifications into Slack, which is very helpful. On 30 June 2017 at 11:36, Daniel Villarreal via talk <talk@gtalug.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Mr. Mohammed,
Thanks for sharing your thoughts.
At no time did you ever state that you refused to use IPv6. You actually stated that you do, in fact, use IPv6. Neither did you ever state that IPv4 is "good enough."
Aside from IPv4 vs IPv6, do you have any suggestions for hardening a Linux system?
kind regards, Daniel Villarreal PGP key 2F6E 0DC3 85E2 5EC0 DA03 3F5B F251 8938 A83E 7B49
On 06/29/2017 06:18 PM, Ansar Mohammed via talk wrote:
Again, please follow the thread, this is not about competency or capability on IPv6.
This is a simple question on hardening a Linux system. My entire network runs IPv6 also. But my home systems do not need to be hardened.
There have been many IPv6 only bugs and exploits including last years IPv6 ping of death on Cisco. https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ cisco-sa-20160525-ipv6
The stack simply isn't as battle tested as IPv4.
Oh, and that growing portion of the internet that's IPv6 only is primarily China.
What's your business reason for the additional risk of IPv6?
Does your application support IPv6?
Has your application been tested with IPv6?
Do you have users that are IPv6 only?
If you don't need it on a hardened system, you are just adding another attack vector for no good reason. ...
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQEzBAEBCAAdBQJZVnAAFhx5b3VjYW5saW51eEBnbWFpbC5jb20ACgkQ8lGJOKg+ e0kIaAf/Yw4QQQweyh0NEX2oro/YrvsDZU3r8zPKL/NXc42w38Q9imJr6J6Ue+Si 6jQ5hZRO0O29Q6Z0DcA1nAg+jOhVBl+cK+TF4RVlxDvAIM55WtwuouQaT5TZwXb/ PRLkR6ZzNnmiIb37jbe0hZSK9CYmI/0wPwyCB5JmrlUNanMA93i4AjBBgKKD24qm w0ph6SPscSv44BkynkOS8Qf5yMZsGt8JjOs19HvJ5AlwUx67aLHIrBvF8SWKw2/W 22Md8cey26LdxChdXR1L7pDCyjxw/OBtTX0Q78ypxucYi7zqx3CVP8HIGO1dZX1T Othjz6Gq6UE6nYRIJupcfAA295nbPg== =lWC7 -----END PGP SIGNATURE----- --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
-- Giles https://www.gilesorr.com/ gilesorr@gmail.com