81–90 of 127 posts
Earlier quoted context omitted.
Honestly, I don't understand why people make reporting abuse so hard/labour-intensive. It is trivial to record netflow data (and most networks do that already), and then verify incoming abuse reports against those records.
is there a chance of forming some kind of a community fail2ban blocklist? I guess trusting the contributors and admins is the hard part here and that’s why spam lists are a double edged sword?
Earlier quoted context omitted.
is there a chance of forming some kind of a community fail2ban blocklist? I guess trusting the contributors and admins is the hard part here and that’s why spam lists are a double edged sword?
Well that and sane people just disable password auth. fail2ban is a 90s sysadmin solution to a nonexistent problem.
I have it scanning my Ubiquiti NVR logs, I modified Tomcat to log the remote IP from my reverse proxy. If anyone tries to log into my NVR three times then Fail2Ban adds the IP to a permanent blocklist on my OpnSense firewall and then HAProxy kills the TCP connection. They can't even ping after that.
Earlier quoted context omitted.
Honestly, I don't understand why people make reporting abuse so hard/labour-intensive. It is trivial to record netflow data (and most networks do that already), and then verify incoming abuse reports against those records.
the counterpoint is that the antagonists can abuse the reporting mechanisms, so some friction is necessary
I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…
> NIST P-curves are possibly back-doored by the U.S. National Security Agency
Is there any evidence of this? This seems extremely paranoid.
Earlier quoted context omitted.
Same for www. Ratchet up the TLS/SSL - https://ssl-config.mozilla.org/ - go for modern and you'll see a lot of failed connections from bots and scanners. Also, if you don't use any other IP block list, do use DROP from Spamhaus: https://www.spamhaus.org/drop/ - that is small enough that you can run it on the webserver if you don't have much control over your connection to the outside world.
I also do that and even take it a step further for my silly hobby sites. I only accept HTTP/2.0 which blocks 99% of the bots and most search engines. Bing is the only search engine that appears to support H2 in their crawler bots.
It also looks a bit like a nod to security through obscurity.
However the world is a different place nowadays and rather nasty! I think we should insist on the best standards we have and not simply allow old stuff to carry on working through some form of misplaced altruism.
I have come across some criticism of h2 but I don't know enough about the context and haven't researched that so can't comment but if dumping h1 works for you then I say crack on.
I quietly enjoy watching my HA Proxy logs live and watching things bounce off. I have had an on prem MS Exchange (currently 2016) system that passes PCI-DSS for several years. Quite a few URLs will run really slowly from the outside world and then fail to work. Password testing on the OWA will quietly get handed off to a fake page that not only never lets you login, but gradually gets slower and slower and uses very few actual resources. The real OWA page is firing up all sorts of things in anticipation of you authenticating but the HA Proxy fake login is a C process and tiny.
You call your sites "silly hobby" but they are still interweb facing and if you don't protect them they will cease to be just yours and instead be part of a botnet that's trying to hack me and my customers or stealing your electricity to run cryptocoin generation or used as part of the war against Ukraine.
There is a good chance that a determined and skilled haxxor will run rings around both of us but let's crack on and make ourselves a bit trickier to crack than the average. If we make ourselves tough enough to crack then unless you are a valuable target then they will pass eventually but you will have slowed them down a bit.
Earlier quoted context omitted.
That's why I recommend always pointing the default virtual host in the apache or nginx configuration to an empty static site, and making the real site visible only as a named virtual host (requiring the correct Host header), even when the server will be used only for a single site. Most of these automated exploit attempts will never send the correct Host header, and therefore will only see the default virtual host.
Could you give a pointer to more info on that? I couldn't find more details on such a setup while googling it.
I'm still seeing the same number of attempts on my public SFTP servers. As a funny side note I found that by going through the hardening steps on ssh-audit [1], most of the bots can't even negotiate a connection. I only see them because I configured verbose logging. They seem to be using really old ssh libraries in the bot code that severely limit the ciphers available to them. Another interesting side effect is that…
I tried that tool against my Raspberry Pi which should have a reasonably-secure SSH configuration and I got a lot of warnings about: > NIST P-curves are possibly back-doored by the U.S. National Security Agency Is there any evidence of this? This seems extremely paranoid.
I have not seen any evidence, just discussions. [1][2]
[1] - https://crypto.stackexchange.com/questions/10263/should-we-t...
[2] - https://arstechnica.com/information-technology/2015/01/nsa-o...
Earlier quoted context omitted.
I also do that and even take it a step further for my silly hobby sites. I only accept HTTP/2.0 which blocks 99% of the bots and most search engines. Bing is the only search engine that appears to support H2 in their crawler bots.
It is a violation of the old mantra exemplified by Sendmail - "be kind in what you accept but be strict in what you send" (or words to that effect). It also looks a bit like a nod to security through obscurity. However the world is a different place nowadays and rather nasty! I think we should insist on the best standards we have and not simply allow old stuff to carry on working through some form of misplaced altrui…
I agree. I do silly things like this to get rid of the bot noise and to keep snooping bots like Discord/Steam off my files. I doubt any corporation would mimic my practices. Most of my hobby sites these days are static pre-compressed content and block anything other than HEAD and GET requests that match a regex patterns.
All of that said I think that you are right. A targeted attack of my server providers could net console access and I would be very surprised if that console access didn't already provide unfettered access to assorted agencies in the name of lawful intercept. At least that was the case when I was in the wireless industry.
Earlier quoted context omitted.
It is a violation of the old mantra exemplified by Sendmail - "be kind in what you accept but be strict in what you send" (or words to that effect). It also looks a bit like a nod to security through obscurity. However the world is a different place nowadays and rather nasty! I think we should insist on the best standards we have and not simply allow old stuff to carry on working through some form of misplaced altrui…
There is a good chance that a determined and skilled haxxor will run rings around both of us I agree. I do silly things like this to get rid of the bot noise and to keep snooping bots like Discord/Steam off my files. I doubt any corporation would mimic my practices. Most of my hobby sites these days are static pre-compressed content and block anything other than HEAD and GET requests that match a regex patterns. All…
I know what you mean but it really isn't silly, it is socially responsible. You are already doing the right thing but thought of it as a hobby but it really isn't.
The thing about the internet is that you can live in the UK or the US or wherever and have someone from the Russian Federation or the PRC off of China or a NORK or simply a common criminal from anywhere rock up and knock on your website's door and try to behave like a parasite.
Think of these little darlings as parasites and it becomes obvious why you should put some effort in to keeping the buggers out.
Earlier quoted context omitted.
That's why I recommend always pointing the default virtual host in the apache or nginx configuration to an empty static site, and making the real site visible only as a named virtual host (requiring the correct Host header), even when the server will be used only for a single site. Most of these automated exploit attempts will never send the correct Host header, and therefore will only see the default virtual host.
With nginx I also set the return code to 444 on the default virtual host, this is not a real status code but instead tells nginx to kill any connections to this vhost at the TCP level.
However, many scanners still end with a full 400. Either their implemenations are so bad or they intentionally send corrupted requests to try to exploit some vulnerability. I have not digged any deeper.