|
| ▲ | Meekro 8 hours ago | parent | next [-] |
| I've done PHP development for over 20 years, including some pretty large projects. I've never had a situation where a security flaw in PHP itself forced me to scramble to patch something before it got hacked. On the other hand, for my Linux servers, I had to do that twice in the last month with CopyFail and DirtyFrag. |
| |
| ▲ | diek 5 hours ago | parent | next [-] | | CVE-2021-21703 [0] is a similar class of bug in the PHP interpreter itself that was pretty recent https://www.sentinelone.com/vulnerability-database/cve-2021-... | | |
| ▲ | ipaddr 3 hours ago | parent [-] | | This is not a PHP language interpreter bug this is a PHP FPM bug. | | |
| ▲ | diek 2 hours ago | parent [-] | | That's a fair point, using 'interpreter' specifically was imprecise language on my part. My main point was php-fpm is developed by the core PHP team and is often the default in how PHP projects deploy these days, and that CVE was very similar to the recent 'fail' LPE vulnerabilities in the kernel. |
|
| |
| ▲ | ggallas 6 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | dylan604 7 hours ago | parent | prev | next [-] |
| Every time I venture in the the web server's error log, I see all of the skiddie's attempts at accessing the most common things with most of them being .php files. Lots of /wp/admin.php and /phpadmin/ type requests. Of course, none of those are available which is why the requests are in the error log. I've never paid attention, but I wonder how long (as in how little time) for a new server to come online before it starts to get probed by a skiddie. Whether they are just war dialing IPs or paying attention to new domain announcements but I'd put it on a few hours tops. |
| |
| ▲ | hamburglar 6 hours ago | parent | next [-] | | Dismissing these as script kiddie attempts is no longer correct. This is a real industry now. It’s not like the large scale actors are going to pass up a valid unpatched vector just because it’s old hat. | | | |
| ▲ | rstupek 5 hours ago | parent | prev | next [-] | | If you get a letsencrypt certificate it will get probed within a minute | | |
| ▲ | jmb99 an hour ago | parent [-] | | I’ve tested this recently (this post week). Had a dns entry up and pointing to an nginx server for ~12 hours, zero requests. 17 seconds after the letsencrypt cert was issued, the floodgates opened. Over a dozen of requests per second. | | |
| ▲ | walrus01 41 minutes ago | parent [-] | | I don't think it's necessarily specific to LE but rather to public certificate transparency logs. LE being free and easy to automate means it's very widely used these days, but if you theoretically go to a "pay" root CA and get a cert that covers thing.com and www.thing.com , the same probing will happen on the same time scale. |
|
| |
| ▲ | doublerabbit 4 hours ago | parent | prev [-] | | 22 minutes. I got my new ISP with fibre. Placed my web server online. 22 minutes my honey pot got stung. |
|
|
| ▲ | hvb2 8 hours ago | parent | prev | next [-] |
| > They cannot be that bad if they are managing to be ductape of the internet. I think there are just a whole lot of tools written for them. So non devs can spin things up and click some things together. Is that safe and secure? Maybe, if the devs did their work well. But I'm positive no one reads the docs on how to configure something securely. I think the real reason is that it's very cheap to host, and always has been |
|
| ▲ | ChocolateGod 8 hours ago | parent | prev | next [-] |
| cPanel is Perl. |
| |
|
| ▲ | anamexis 8 hours ago | parent | prev | next [-] |
| How does that follow? |
| |
| ▲ | cinntaile 8 hours ago | parent [-] | | They have a big target on their back so the low hanging fruit is (mostly) gone. |
|
|
| ▲ | bsder 3 hours ago | parent | prev [-] |
| > They cannot be that bad if they are managing to be ductape of the internet. Oh, it very much can be that bad. Most "security" relies on the Hungry Tiger Theory of Security(tm). My system doesn't need to be "secure". My system simply needs to be more secure than yours. As long as there is an easier and/or more valuable target somewhere, I'm "secure". I don't need to outrun the hungry tiger; I only need to outrun you outrunning the hungry tiger. That theory, of course, doesn't hold anymore when there are enough tigers to simply eat everybody. And that's what AI did; it multiplied the tigers enough that they can just gorge on everything. Now, people are going to have to put in "actual security" or lose real money over and over and over. And since everybody has outsourced everything, nobody knows how to fix it quickly. The lawyers are going to have a field day. At the end, however, we'll have real security on our internet facing systems. But man, it's going to be painful for a while. |