[00:01] <idmbe> Thank you guys for help and tips, i should leave now 
[09:42] <lotuspsychje> i used to have a recent snaps rss, but cant find it anywhere anymore
[10:35] <lotuspsychje> !23.04
[17:23] <leftyfb> tomreyn: our buddy Toni showed up 10 days later with a compromised machine
[17:26] <tomreyn> leftyfb: was this the marketing person who just wanted a web panel? if so: hehe, you win.
[17:27] <leftyfb> yep
[17:27] <leftyfb> and no. If so, we all lose as they are now contributing to the garbage on the internet
[17:27] <leftyfb> that I have to prevent from hitting all my stuff
[17:28] <tomreyn> i see what you mean
[17:29] <leftyfb> I was wrong though
[17:29] <leftyfb> 2023 Apr 13 14:03:57 <leftyfb>	tomreyn: and I guarantee you that site will still be running 22.04 7 years from now
[17:30] <leftyfb> it didn't make it that far lol
[17:32] <tomreyn> while i think it may be the better choice for him, i'm not sure that just pointing people to a SaaS solution is the right thing to do on an #ubuntu channel. in #security, i would definitely agree, also in #html (or #hosting), if that exists.
[17:34] <leftyfb> tomreyn: they have zero interest in Ubuntu nor security, nor running a server. They just want a website they can "market" all over. 
[17:34] <tomreyn> most likely the better choice for this very person and the internet at large,t hough
[17:34] <leftyfb> pretty sure I've never recommended such services to anyone else
[17:34] <leftyfb> I completely understand
[17:35] <leftyfb> in this case, 1 less cesspool on the internet (the server)
[17:35] <leftyfb> I gave them a link on how to lock down ssh and told them to close off all the ports they had open with ufw. They ignored all of it
[17:42] <tomreyn> they did did seem to like the idea of 'running their own server', even though they didn't really want to care about it. they did consider hiring someone to manage the server. but i guess it would have been too expensive and effectively pointing them to an SaaS is, quite likely, still be the best option for them. on the other hand, it could have been a valuable learning path.
[17:42] <leftyfb> I tried the learning path. Didn't work
[17:43] <leftyfb> though, this is probably the best teaching moment. Don't lock down your server = ccompromised 
[17:43] <tomreyn> what we best learn by are our own mistakes. personally, i nowadays think it's better to let people who ignore recommendations run into those and hope they make a wiser choice next time. even if this impacts our beloved infrastructure.
[17:48] <tomreyn> and that the real options to reduce the impact of abuse through compromised systems is secure default configurations (whereever possible), to improve detection of compromises, and to limit the impact compromised systems can have
[17:48] <lotuspsychje> 24/7 servers are always targets right
[17:48] <lotuspsychje> not an easy matter to keep it secure both novice or expert
[17:49] <tomreyn> anything that's reachable is a target
[17:49] <lotuspsychje> true
[17:49] <leftyfb> things like changing ssh to a non-standard port ... not something to easily make into a default
[17:49] <leftyfb> disabling ssh password, also a paint to get the public key onto the server for the first time
[17:50] <leftyfb> it's also debatable whether he was compromised via ssh or wordpress 
[17:50] <tomreyn> you don't strictly need to switch ssh to a different port as long as you - or - much worse - you host, on their images - don't enable password authentication
[17:50] <leftyfb> either could have had horrible credentials
[17:50] <tomreyn> *youR
[17:51] <lotuspsychje> wordpress is constantly 0day'd
[17:51] <leftyfb> that's what I have fail2ban for :)
[17:51] <leftyfb> and a custom script that keeps wp and all the themes and plugins up to date
[17:51] <lotuspsychje> nice
[17:52] <tomreyn> so your wordpress breaks all the times due to plugin imcompatibilities and badly tested plugin updates?
[17:53] <leftyfb> hardly ever
[17:53] <leftyfb> in 20 or so years I've been hosting wordpress sites, I think I've run into that 2 or 3 times
[17:54] <tomreyn> running wordpress is such a pain, i think 90% of those who do should just switch to static generator.
[17:54] <leftyfb> you just gotta have a competent admin behind it :)
[17:54] <leftyfb> but for just a marketing person, yes, it's a pain
[17:55] <leftyfb> I have a nightly job that updates all the themes and plugins and notifies me when wp itself needs updating. That I do manually 
[17:56] <leftyfb> and if I have a problem with any of it, I have nightly backups
[17:57] <leftyfb> I have a bunch of custom fail2ban jails I setup that look for attempts to login and XSS and hits on plugins I don't have. All get blocked
[17:57] <leftyfb> I'm currently hosting 5 sites, but I used to have a dozen or so at any given moment
[17:58] <lotuspsychje> being informed is crucial for sure
[17:58] <tomreyn> okay, that's a volume where it makes sensens, or should i say, is necessary to spend time on improving automation and processes.
[17:58] <leftyfb> yep
[17:59] <leftyfb> and all new sites/accounts/apache/dns are created using ansible
[18:02] <tomreyn> that's nice. at $work, they went with bitnami images (before they were acquired by vmware) https://bitnami.com/stack/wordpress/cloud
[18:04] <tomreyn> the idea would be you have those images providing OS and just replace the OS image occasionally, while WP self-updates and thus "everything" remains up to date.
[18:05] <tomreyn> in reality, that's not true, because they have custom builds of apache and php and openssl which don't get updated when you replace the image
[18:05] <tomreyn> so you gained nothing, yay
[18:08] <tomreyn> also bringing things back together (WP on the one hand and the OS + services on the other) gets harder on every image upgrade since they diverge and they changed how things are managed, too.
[18:09] <tomreyn> so effectively $work ended up with one outdated bitnami image and stopping to swap out images because "too costly"
[18:11] <tomreyn> i.e. "let's wait for a security incident, then we can talk again"