Confuse some SSH bots and make botters block you(mirror.newsdump.org)
mirror.newsdump.org
Confuse some SSH bots and make botters block you
https://mirror.newsdump.org/confuse-some-ssh-bots.html
32 comments
Yeah I probably have a number of false positives from my semi-fascist nginx configuration [2] I just use this for hobby sites and would never be accepted as a commercially supported CDN. They do fancy detection methods whereas I just use simple hacky methods. I tend to tune things so my friends can get through and some random people may get dropped until I look at what they are sending. For what it's worth each method is entirely optional or tunable to a persons needs or fever dreams. Probably language settings.
[1] - https://mirror.newsdump.org/nginx/inc.d/30_generic_http_stuf...
[1] - https://mirror.newsdump.org/nginx/inc.d/30_generic_http_stuf...
This is a terrible idea.
This is a terrible idea.
Many of the things I do are terrible ideas. That is half the reason I keep doing them.
The goal here is to show people some of the things that can be done not that they should do them. It's up to each person to experiment and determine what tickles their fancy.
Many of the things I do are terrible ideas. That is half the reason I keep doing them.
The goal here is to show people some of the things that can be done not that they should do them. It's up to each person to experiment and determine what tickles their fancy.
Lol, I want to know what happened here:
Eventually I blocked Brazil since I always
block them via accept-language in nginx and haproxy anyway.
For reasons I will never understand most people in Brazil
can not and/or will not read or follow even the
simplest instructions. This has been the case since BR was
connected to the internet.
Lol, I want to know what happened here:
Years of running forums and IRC servers. That is where 99% of my moderation requirements came from even when I would try really hard to be hands off.
Years of running forums and IRC servers. That is where 99% of my moderation requirements came from even when I would try really hard to be hands off.
We don't leave any ports open anymore. Everything is behind Wireguard. No key? Your packet goes into the blackhole.
Silent by default.
Silent by default.
That is a good idea. My example is for people that expose ssh/sftp on purpose such as a public SFTP server for sharing who knows what.
be sure to add iptables to drop packets if there's no back and forth exchange of data, then you're good2go as fake/wrong keys don't use resources to determine if a key is legit or not. not that big of a deal and wg just doesn't reply anyways
And good choice on the wireguard only, only issue I had is devops/testing things and not being connected to the wireguard because I'd be connected to another wireguard and couldn't ssh in to the server.
WireGuard _all_ of the things
And good choice on the wireguard only, only issue I had is devops/testing things and not being connected to the wireguard because I'd be connected to another wireguard and couldn't ssh in to the server.
WireGuard _all_ of the things
> add iptables to drop packets if there's no back and forth exchange of data, then you're good2go as fake/wrong keys don't use resources to determine if a key is legit or not.
How does an initial connection work in that scheme?
Seems like a pretty big footgun for questionable benefit, since a main benefit of Wireguard is that it’s very lean in terms of resources.
How does an initial connection work in that scheme?
Seems like a pretty big footgun for questionable benefit, since a main benefit of Wireguard is that it’s very lean in terms of resources.
> The VersionAddendum will cause most poorly coded bots to hang, thus causing the botter to exclude us from their scans rather than us having to block them.
Why does this happen, wouldn't bots just ignore the version information?
Why does this happen, wouldn't bots just ignore the version information?
That would be a "properly designed" bot and not a poorly-coded one
That pretty much sums it up. Someone writes a quick and dirty python/perl thing and all the botters use it rather than writing something around a recent ssh library. Their thing is probably faster but leaves out a lot making them easier to detect or break.
I like this, back when the xterm CVE was common you could probably 0wn any botter who was looking at their logs in xterm.
On a related note that is still a risk today on any site that allows CSS with copy and paste. [1]
[1] - https://thejh.net/misc/website-terminal-copy-paste
[1] - https://thejh.net/misc/website-terminal-copy-paste
Not sure if it's down or if I've been flagged incorrectly as a bot
Safari can't open the page "https://mirror.newsdump.org/confuse-some-ssh-bots.html" because Safari can't connect to the server "mirror.newsdump.org".If the TCP Window size is abnormally small I block those and MSS outside of 1280-1460 but that is prior to anything the browser is doing. Those can been seen with
tcpdump -p -i any -c512 -NNnnvv port 443 and 'tcp[13] == 2'
Same
Interesting bit here. How would this render the firewall useless?
# greater than 1 is a vulnerability by design used by TLA phishers rendering every firewall useless.
# beware of fakademic mid-wits that parrot things they do not understand.
MaxSessions 1If I can get you or someone on your team to run a script meaning I was phishing and someone on your email alias ran it to "help me debug my new script" then I can drop a tiny obfuscated shell script that will execute when you log in. No sudo, no root. Your machine will ssh out to a node I control using gateway ports. I then ssh into your node using a key I dropped plus an sshd running as you and then piggy-back on your multiplexed connection to your development or production data-center making use of a connection that you already authenticated to and already used MFA/2FA. In most cases there will be no logs to gather and the security team will see my connection as you. No hacking tools required, no detection from most security daemons.
It's only a risk if someone on your team runs the script and your local network allows outbound connections to the internet. None of this is theory though management teams will never want to see a demo much less let others in the company see it. A former coworker came up with the design. Shout out to The Godfather.
It's only a risk if someone on your team runs the script and your local network allows outbound connections to the internet. None of this is theory though management teams will never want to see a demo much less let others in the company see it. A former coworker came up with the design. Shout out to The Godfather.
Not sure I follow. Is your main objection to it that it can obfuscate login activity since many systems track login/connection events at the sshd level and are oblivious to SSH multiplexing?
I personally find it extremely useful when working with servers more than 100ms or so away in many contexts, and even closer if the workflow requires making many short-lived connections.
I personally find it extremely useful when working with servers more than 100ms or so away in many contexts, and even closer if the workflow requires making many short-lived connections.
Is your main objection to it that it can obfuscate login activity since many systems track login/connection events at the sshd level and are oblivious to SSH multiplexing?
No, it means anyone that can get your team to execute a script can log in as you in any data-center you have authenticated to regardless of multi-factor authentication without using credentials. It means firewalls do not exist, CVE's not required and credentials are not required.
I personally find it extremely useful
Absolutely, not using credentials and riding the existing channels will always be faster. Removing authentication requirements will always reduce friction.
No, it means anyone that can get your team to execute a script can log in as you in any data-center you have authenticated to regardless of multi-factor authentication without using credentials. It means firewalls do not exist, CVE's not required and credentials are not required.
I personally find it extremely useful
Absolutely, not using credentials and riding the existing channels will always be faster. Removing authentication requirements will always reduce friction.
Feel free to test your SSH bots and HTTP bots against mirror.newsdump.org
I am having fun playing with the slow syn flood of spoofed packets someone is sending. I appreciate them sending it. I like the variability in the TCP MSS, TTL, Window sizes they are sending.
Thus far I am letting some leak through it would seem.
Thus far I am letting some leak through it would seem.
100 SYN received in 15.03 seconds
100 SYN-ACK returned in 3 minutes and 22.03 seconds.
Eventually ran out of things to play with. Actions taken:
- Blackhole routed a few ASN's / data-centers. It's all spoofed packets but good to block data-centers regardless so we are not sending them syn-ack (good hygiene).
- Added a temporary rule when we encounter a syn-flood. [1]
End result: Input 20 packets in 17 seconds, Output syn-ack reply 20 packets in 4 minutes and 44 seconds. That should translate to an acceptable amount of syn-ack if we were actually attacked some day.
Impact: Before, we sent more syn-ack then I would have liked but there was overall no impact to Nginx as we use the "deferred" socket option [2]. Now we send far fewer syn-ack packets for good internet hygiene. Thank-you to the person using the syn flood tool.
[1] - https://mirror.newsdump.org/nftables.txt
[2] - https://mirror.newsdump.org/nginx/http.d/11_bad_sni.conf.txt
- Blackhole routed a few ASN's / data-centers. It's all spoofed packets but good to block data-centers regardless so we are not sending them syn-ack (good hygiene).
- Added a temporary rule when we encounter a syn-flood. [1]
End result: Input 20 packets in 17 seconds, Output syn-ack reply 20 packets in 4 minutes and 44 seconds. That should translate to an acceptable amount of syn-ack if we were actually attacked some day.
Impact: Before, we sent more syn-ack then I would have liked but there was overall no impact to Nginx as we use the "deferred" socket option [2]. Now we send far fewer syn-ack packets for good internet hygiene. Thank-you to the person using the syn flood tool.
[1] - https://mirror.newsdump.org/nftables.txt
[2] - https://mirror.newsdump.org/nginx/http.d/11_bad_sni.conf.txt
On a funny side note, it seems that after blocking ASN's I ended up finding by coincidence this list of ASN's that are related in some way to StormWall [1]. Curious what that means. Perhaps they were trying to get me to add myself to a BGP GRE DDoS scrubbing list with the syn-ack packets. Well played if so! :-D
[1] - https://bgp.tools/as-set/RIPE::as-stormwall-set#reverse
[1] - https://bgp.tools/as-set/RIPE::as-stormwall-set#reverse
Paramiko v4.0.0 (the latest) gets past the version string, it seems, but dies instantly on failed KEX, which is another convenient incompatibility. It does mean that even legitimate SSH bots in Python will fail though.
That is likely from performing hardening in ssh-audit [1]. The way I used to block python, Go and libssh was to use a iptables string search but that capability does not exist at least natively in nftables.
[1] - https://www.ssh-audit.com/
[1] - https://www.ssh-audit.com/
I love this, I remember running a tarpit on port 22 on a spare VM at an old job of mine. Was entertaining to tie up all those scanners and be a pest to their runners.
The extremely large banner in this example is hilarious.
The extremely large banner in this example is hilarious.
I can't load the page (Firefox mobile on android)
Turns out switching from Firefox mobile to Chrome mobile "fixes" this. Thanks for supporting the free and open internet.