I think we are now at step 5 and we can improve the Server Manager with these features in the future. By now one can install yum-cron (but we must implement required metadata to make it work properly with our repositories, whilst upstream are ok).
My proposal is now to wait the 7.4 release announcement, that will be likely Monday, Oct 30 (@alefattorini is working on it).
Then we can publish an advisory, with the information I already shared here.
A few days after that, we can fully disclose the issue - and tell the nice story behind that
Testing updates before releasing them is so critical it should be top priority number one
Another system i am (was) using didnāt do that properly.
It made my system unbootable ! That is unacceptable.
And now Iām supposed to debug their custom debian stuff to find the problem ? No thanks
We have Nethserver and itās rock solid
Please keep testing the updates as much as possible.
I am a firm believer that security notices should be released as soon as a fix is ready or itās (the flaw) wide use is anticipated. We rely on you guys to supply accurate and detailed information about the threat as soon as possible so that we can determine the impact and act accordingly.
Any sysadmin not following DTAP is asking for problems and any sysadmin who doesnt make time for security deserves them. So please, make sure security updates do not break a system as much as possible, but do not hesitate too much in informing those of us who covered their bases appropriately. Any sysadmin claiming DTAP is too costly should try a 1tb harddisk and VirtualBox on just about any client hardware.
Run that update on a similarly configured install and check if it survives is not hard nor time consuming ā¦ it just requires some commitment to follow through.
This would work, unless the security threat is a major one, in which case I rather know it now, and be forced to disconnect my server from internet to mend the issue, then to exist in ignorance while script kiddies are abusing a 0-day which fix is being QA-ed ā¦
agreed, though IMO you should be able to mitigate most of those using fail2ban and a solid IPS/firewall configuration as well as monitoring. You can also mitigate some risk by going through centos and hardening yourself to your satisfaction. I cant say 100% my network is safe, no one ever can, but I am confident that it is as reasonably safe as I can make it, port scans are auto block in shorewall, vulnerability scans same, ddos and any form of probing is immediately blocked perm, beyond that the only way you might be in trouble is IF there is a 0-day floating out there and IF someone targets you personally, and IF they dont get banned on the at least 3 different nets protecting RED interface. I am also geoblocking, so countries that are known for basement script kiddies (russia, china, north korea) are blocked as a country. Best thing for you is to know your network, know your security, know what you are dropping and know how to spot anomalies.
Well, yes it would to a certain degree. 0-day doesnāt matter if you drop the packet. Shorewall blocks everything by default and only allows a couple things. I always set httpd admin to green only (default is red/green), and cockpit/ssh as well. If you need access to any of that, vpn in. Change VPN port, change SSH port. Its all isolated as well. Set a good admin pass and even if someone ābreaksā in on 1194(vpn) or smtp/imap, still cant do anything. Plus we get security updates from centos repos. The gateway isnt the problem, its not managing users behind the gateway properly. Almost every breach today comes from users giving info/not being educated properly. If a user downloads malware that accesses server information, thats not the servers fault thats the local admin not doing his job in regards to locking users down and social engineering training. Just my 2c
Agreed ā¦ I usually neglect to name common sense. I meant a 0-day on an open service. It goes without saying, to me, that you do not open ports that do not absolutely need to be open. But yeah, thatās not intuitive to everybody, so thanks for making this point.
