Log them in. Give them the data they want but make it false. They think it's working and mark those passwords as good but they don't know otherwise. Now they have no idea if they're really good or bad and they have to verify with multiple other attempts somewhere else.

As someone often engaged in nonmalicious (but unwelcomed) scraping, this is one of the anti scraping measures I fear most

Google did this to me. I wrote a script to find the cheapest flight in matrix.itasoftware.com (now Google Flights), and ran it once per hour. Pretty soon they started giving me only the most expensive flights, as in, 7K+ for a 1K flight.

That sounds like someone personally turned this on for you. Did you try to mask yourself and repeat?

As funny as that would be, I doubt it was done personally against me - who would even take the time to block one person from getting one single cheap flight slightly cheaper?

But I didn't try anything fancy. In retrospective, I probably should have turned on my VPN and see what happened.

Out of curiosity, what kind of "nonmalicious but unwelcomed" scraping?

Not GP but scraping price data off some stores (particularly travel sites) tends to be unwelcomed by operators.

Myself, I did scrapping of a classified ads site once, to have notifications when a particular product I was looking for showed up for sale.

Not GP but scraping data for personal projects off companies overprotective of their data is probably the most common example.

Trying to get your entire reddit history, for example, is an obnoxiously difficult thing to do. It's impossible to get more than 1000 comments with the officially supported mechanism, leading people to do all kinds of strange workarounds to try to find older comments.

As a 10 year redditor, that really frustrates me, since I can't go back and see my early posts any more.

Curious if Reddit will have to provide an easy mechanism to retrieve all of your comments now as part of GDPR.

Check the announcement post. In a comment one of the admins said they will eventually but for now it's email only for residents of the EU.

https://www.reddit.com/r/announcements/comments/8m2yr4/were_...

If everyone in the EU could email them to speed this up that would be great.

(GP here) re: the second part, I guess I consider most scraping 'unwelcome'

To the first part: I would characterize certain scraping, usually behind an authentication wall, as malicious--though admittedly that's not the right word. An example would be scraping Facebook profiles to build a marketing list.

So, by 'non malicious,' i mostly mean 'publicly available data'

I've scraped content from sites with (and without) logins, for offline perusal when I was on a cruise.

This. Make it probabilistic, though, do not log them in every time.

Better to make it deterministic, eg. display a fake success page whenever sha1('salt'+login+password) has two leading zeros.

That way you can easily control the fake success rate, and you make sure that if the attacker realises they are being tricked, they can't just retry successful logins to double check, since they get the same result every time.

Good idea. Doesn't have to be complex - even java hash code with modulus would work.

These suggestions sound good but the real challenge will be to reliably detect fake logins to not suddently and accidentally mess with your real users..

Easy. Set it up just like a honeypot. Except that instead of being a sticky honeypot, it's poisoned honey they get.

OP mentioned the attack is easily identified so legitimate traffic gets served correctly bad traffic gets "logged in" to the poisoned honeypot. 301 after login perhaps

Giving scrapers fake but realistic data is my favorite way of dealing with them (as long as it does not consume too much resources).

It will hopefully waste their time and discourage them from trying to find other ways.

Do their requests indicate support for gzip for other compression protocols? One thing I've heard people do is send a response with a zip bomb that expands to essentially infinite size, causing their program to crash.

https://news.ycombinator.com/item?id=14707674

Unless you have 100% precision in finding bad actors, this may end up zip-bombing some poor unlucky human.

Interesting read. But I'm wondering: how do you _create_ a zip bomb? Do you first need to create a petabyte file? Or can you compute it or something?

I believe you can do it off the command line relatively efficiently by piping output straight into gzip.

ie) perl -e "print '0' for (1..1000000000)" | gzip > zipbomb.gz

This will create a ~ 1MB file that will expand into something 1000 times its size.

Would probably be much more efficient to use /dev/zero:

  dd if=/dev/zero of=/dev/stdout bs=1M count=1024 | gzip > zipbomb.gz

However, you're restricted to NUL bytes there. However, you can vastly improve your original Perl script by writing more chars at a time:

  perl -e "my \$x = ('0' x 1000000); print \$x for (1..1000)" | gzip > zipbomb.gz

That runs about as fast as the dd variant on my system, and about 10 times faster than your original formulation.

yes 0 | head -n 1000000000 | gzip > zipbomb.gz

?

There is an example available on the page linked to there.

Send them GZipped traffic anyways, since all legitimate clients support it.

> 301 redirect to https://nsa.gov so they might get on someone's radar with the time and resources to stop them

No, don’t do that. Don’t redirect them to anyone else but yourself.

IANAL but it seems pretty clear that you could end up being partly responsible for any damage caused by sending them elsewhere.

Furthermore, even attacking back in any way could be a very very dumb thing to do. Just because someone is attacking you you don’t know that the owner of the system is responsible for that. In fact most likely almost every single machine that is participating in attacks against you are just botnet victims.

The book Aggressive Network Self-defense talks a bit about this. https://www.amazon.com/Aggressive-Network-Self-Defense-Neil-...

I think the only reasonable thing to do is any combination of the following:

- Present captchas and use rate-limiting like you were

- Block / blackhole / null route

- Honeypot that holds onto sockets for as long as possible, but only if you are sure like someone else said ITT that doing so is not DOSing yourself.

Is there an easy way to free a socket without having the networking stack close it for you (and tell the remote?)

You mean without a close()? You probably shouldn’t try to get around that. It’s not always great but you could set SO_REUSEADDR to let the stack let you open a new socket on the same port after you close the first.

I’ve wanted to do the same kind of thing. My business partner who handles the backend, and may be more sensible than me, suggests not wasting my time. Hanging onto the socket is potentially DOSing yourself. You could have a server for it, but it’s a server you could be using for other things. In the bigger picture, spending time on this is a form of DOSing yourself. You could be working on features or customer service or spending time away from work or, perhaps, implementing two factor auth for customers, if you don’t already have it. As much fun as it still sounds to me, I think my co-founder’s advice is best: do make sure you’re locked down but don’t try to get them back, since it’s time & resource consuming, and not very likely to work anyway.

Years and years ago I ran a tar pit [1], and it could handle a tremendous amount of connections with very little overhead. This could be easily done with a 301 redirect to such a system.

[1] http://labrea.sourceforge.net/labrea-info.html

But if everybody did something like this, it could make a difference. Maybe we could use a library/service specifically designed for this purpose. It could keep itself up to date, and other than setting it up, you wouldn't need to spend time on it.

Blue Frog tried something like this over a decade ago.

https://en.wikipedia.org/wiki/Blue_Frog

It didn't work out so well.

> Some attacks originate from Android devices

Some attacks claim to originate from Android devices.

If you want to try to crash the client, you can try gzipping a large amount of null bytes and reply with that. It should compress about 1000 to 1.

Someone else suggested faking a successful login a small percentage of the time, which is a nice trick.

Note that by doing this stuff you could very well provoke a DDoS. Just block the traffic.

I think you may be on on to something the honeypot server...you could create something like Slowloris in reverse. One of the techniques it uses is to send a request one. Byte. At. A. Time. Very. Slowly. You could try doing the same thing with responses from your honeypot, which, assuming they don't give up before they get the full response, could even be redirects back to the honeypot.

But if you can ID them easily then iptables rules might be the most effective use of your time, especially if you can use fail2ban, which makes the whole process very easy.

The TLS thing is interesting, but if some of this traffic is coming from compromised devices it would probably be less harmful for the owner of the device if you didn't make them burn a ton of CPU cycles.

This. Honeypot with fake data once you're sure they are a bad actor. That will reduce their value as a provider of data.

It's fairly easy to create fake, but checksum compliant credit cards.

This works surprisingly well for a class of unsophisticated attackers. nginx, among others, will happily spoon-feed very large numbers of concurrent clients at 1 byte / second.

After using fail2ban in production I've noticed Chinese attackers will start using a massive amount of entire subnets, which eventually cause servers to crash with such long Iptable rulsets.

I have an interesting idea.

How about make the login process more resource intensive on the browser side, by running some intensive javascript code before sending it to the server?

The trick would be to make this much more intensive on the client side (say 1s of CPU time), while keeping this relatively easy for the server (say 1ms). We're trying to waste their resources, not ours.

One way I can think of:

1. server sends a random seed to the client

2. client calculates 1000 hashes based an random numbers generated from the seed, something like hash(rand() + password) and sends them to the server

3. server picks a one of those and validates it. In case the hash isn't valid, you'll respond with an invalid password, so the client won't be able to distinguish between a failed authentication because of hash validation or because of a wrong password.

That's doable but you have to process a lot of traffic from the clients because the client would have to send all the answers it has calculated.

Do exactly what bitcoin does: You send a random prefix and require the client to find a random suffix so that hash(prefix+suffix) ends with, say 4 zeros.

So. Someone is wasting your time, so you want to start wasting everyone's time and natural resources playing games with a script?

Stay away from trying to increase computational overhead. Everyone thinks computation is "free", but it isn't. There is a turbine somewhere cranking out annoyed pixies to drive your computation war with this botnet. The fact some actor has decided to distribute the energy cost to someone else doesn't mean you have to double down on the waste by multiplying the botnet operator's energy expenditure being dealt with by oblivious user's a thousandfold.

It's a bit like global thermonuclear warfare. The only winning mover is not to play.

The least resource intensive way of dealing with it is just detection and either preemptive drop (no more useful info) or if you want to get creative, start doing some whois digging with IP's and start blowing up some operator's inboxes with questions as to why you are getting malicious login traffic from their IP block so they can start running down the source from their end.

This is the Internet. We don't know everything going through it, but most operator's are generally open to trying to keep transits clean if they are made aware of a problem in a way that doesn't seem like a DDoS aimed at their time.

That's cool. Didn't know that bitcoin does this. It sounds like a much better approach.

I guess you can fine tune how complex you want this to be by changing the number of zeros you require.

A friend suggested something else - make the client bruteforce a short RSA key (of say, 100 bits)

proof of work. used a lot in email anti-spam.

Wasn't familiar with the term.

Thanks!

Or add https://coinhive.com which will put a load on the client and make you a bit of money.

Can be used like a captcha or placed in between a process. You just specify how many hashes need to be completed before proceeding.

Very bad idea. This might get your page flagged by anti virus scanners or even search engines.

If you manage to do it for only suspicious-looking login attempts, thats actually a great way to both stall them and benefit. it just feels so much win

but are these scripts sophisticated enough to run JS etc?

If you fail to detect a bad botnet once and show the mining script to an important crawler (like a search engine), and then land on a blacklist, it could potentially require a huge effort to get off it again. It's simply not worth the risk.

Some of them can run Javascript, I'm thinking specifically of people who write scrapers in things like PhantomJS (headless browser, very very cool software).

Being too creative about unwanted traffic can backfire. Reminded me of this:

Justin.tv used to redirect people who searched for "porn" keyword (apparently high overlap with people being toxic on the platform) to what they were looking and used an affiliate link. This became a negative newsstory for them.

TechCrunch calling them out: https://techcrunch.com/2009/02/16/justintv-is-redirecting-po...

Article with retrospection: https://www.inc.com/tess-townsend/justin-kan-stop-freaking-o...

Proof of work system.

Require your clients to perform some amount of computation to do a request.

Something like this: https://www.npmjs.com/package/work-token

I know blockchain and PoW is the thing to talk about right now, but if you think about it, client-side PoW is kind of a bad system. the whole point of such a system -PoW or captcha- is to increase the cost for the attacker to do the attack, so rather than $0.00000001/request (if you're renting a russian botnet or something), it costs a bit more, hopefully more enough that it's not worth it for the attacker to continue. a quick search on google says that recaptcha2 solvers can be obtained for $0.003/solve, which makes the cost per attack $0.003. on the other hand, the PoW is much lower. let's assume most of your visitors have a dual core system, and you require 30 seconds of PoW to log in. a dual core ec2 instance (c5.large) can be rented for $0.096/hour. at 30 seconds per solve, it can generate 120 solutions, for a final cost of $0.0008 per attempt. so in this case, going with the captcha solution is clearly the better solution as it costs almost 4x as much per attempt. there's a bunch of other factors not accounted for that makes PoW worse:

* native code can almost certainly run faster than javascript code, even if you're using webassembly. in my experience js cryptominers operate at around half the speed compared to their native counterpart on the same machine

* the attacker can leverage GPUs to compute solutions hundreds of times faster than what your users can

* users have to wait 30 seconds before they can login. you can generate the key while the user's filling in the form to shave off a few perceived seconds, but that will result in a sluggish login form

* users with slow CPUs (ie. anything slower than what's in a c5.large) will take even longer to generate a solution. this is especially problematic for people on smartphones

* users might think that your site's high CPU usage is because you're running a cryptominer on your site!

> which makes the cost per attack $0.003. on the other hand, the PoW is much lower.

If your attacker isn't even paying for the resources they use, such as from botnets or borrowed, then your attack value has gone out of the window. If the indivdual attack is free to the attacker, then you're left with time. PoW guarantees a time value. If a single PoW is too cheap, then ask for more values.

> Someone who wishes to abuse your API by sending large numbers of requests would then need to spend large amounts of time computing the work tokens.

Someone who wishes just to abuse your API with no intention to actually log in will just flood you with reams of requests to obtain new work tokens without executing any of them.

So you're back to regular rate limiting, etc.

How does it solve this problem? A single SHA-256 isn’t a significant amount of work.

You can just loop it to require more CPU. Dynamically even!

So it solves this problem AND it's secure! No brainer.

But you can keep using HTTPS if you want.

Does this actually run fast enough in browsers to be useful?

While the other suggestions are great, I would really like some kind of write up on who these people are. Send them on weird paths, hell yes, but

- not on company time, this is not crucial to the business

- try to collect as much information on the attackers (are they really "hackers"?) as possible, the info they send you, how they react to your challenges ... and share it with us!

Thanks and have fun!

We use PerimeterX and it's generally worked well for us https://www.perimeterx.com/ (and more cost-effective than spending our own time on it, at least for us)

I do share your desire though to try to direct the traffic towards some entity that could be better equipped at cutting it off at its source. It's automated traffic for the most part, so perhaps a clever automated solution could be effective at stirring a bigger or more well-equipped entity to cut if off. Past attempts at FBI reports and such have not amounted to anything for us.

I keep track of login attempts via Redis based on IP address. As soon as one IP address attempts to sign in under different account name (e-mail in my case) and wrong password, IP is added to the set. Once there were more than 3 similar attempts, web server starts to return '403 Unauthorized' errors. In a few minutes (cronjob) IP address is added to the blacklist of 'ipset' (great tool for managing and keeping IPs in sets for iptables), which results in all connections from the offender silently discarded in a kernel firewall. Define your own terms when to purge sets and offer amnesty.

This method discards real traffic though. Consider that many networks exist with shared IP addresses. At my dorm in college we all had the same IP and often had trouble signing in on Reddit because if you failed your first sign in attempt you'd get locked out for 30 minutes. We also got cloudflare captchas often but at least these methods were temporary and upfront to the user, your method just breaks the site for real users. This will only become more common, consider ipv4 tunnels.

I have several e-mail addresses, that I use in combination with several passwords across services. While there's some consistency in which pw I use where, it's not definite. This leads to situations where I have to soft-bruteforce my way through the different combinations of user:pw that are possible. Services that deny me (worse yet, permanently) after a few failed attempts are the bane of my existence.

I've since moved to a password manager, but before they were commonplace this was the only somewhat convenient way to give yourself some protection against password leaks.

As a trade-off to prevent legitimate users from trying to login with non-existent credentials, I display "this login does not exist" message. So unless the customers attempt to enter numerous different logins anyway - they are safe.

I am not worried about bots trying to validate various account lists and build "existing users" list of my service, because those enumerating attempts are quickly prevented.

Your legitimate users don't ever forget their username and take a few guesses?

This is a really really bad way of dealing with abuse. Many companies, universities, libraries etc. share outgoing IP's with many users.

Obviously, what I described was a "basis description". There are many tricks employed to decrease risks of legitimate IPs from being banned. For example, only invalid login attempts from the same IP with several non-existent and invalid password accounts are counted and then counter is reset every 24 hours. Based my site's usage patterns, legitimate users are very unlikely to get flagged in those situations, but I've successfully banned over 65k IPs of botnets trying to bruteforce over stolen email/passwords combos..

You should trick them into thinking they have valid credentials for all their login attempts since it will devalue their dumps which they are likely selling. Most dark actors are highly specialized and these guys are likely selling what they find.

If the client handles XML you can use a "billion laughs attack"

https://en.wikipedia.org/wiki/Billion_laughs_attack

Also, see if they crash with invalid responses. You can serve a malformed document or something like that.

Redirecting to 127.0.0.1 is the most effective strategy. The web hosts who host these compromised sites will notice the increased load and the sites are more likely to get suspended for the good of the internet.

Aren't these compromised machines typically desktops?

Desktops with users who have not noticed any issue. Making them notice an issue could be a good thing.

Question is, would this approach get their attention? Seems unlikely, but maybe some users would wonder why their computer was sluggish, and run a virus scan, do a system update, or take other steps to check for malware.

Let's be clear, I'm not claiming it would work for sure. I said "maybe." Point is, the computer being a desktop should not lead to shutting the idea down.

Not sure how a redirect to 127.0.0.1 (which would simply fail, they're unlikey to be running a webserver) would help?

Eating CPU though should do the trick.

In my experience in webhosting, unless it's CHINANET it's usually compromised CMS's.

Make it useless to even try. Don’t make it easy to detect when someone has burned through an ip - they’ll just pick the next up in the proxy list they bought. Make it so after 100 unsuccessful attempts, flag the ip and only allow it to log into accounts they’ve already logged into before (to stop them from using a real account to detect if they’ve been banned.) don’t say “you’ve been banned” - just shadowban the IP and always fail the auth. After a while they will notice but not after a ton of attempts

Shadowbans, if not implemented completely correctly, are extremely user-hostile and frustrating.

Very true, for example in case of reddit shadowbans it is trivial to check if an account is banned while a legitimate user can go on for a very long time assuming that simply no one is replying, unaware that something like a shadowban exists.

Unless you are 100% certain there won't be any false positives ever, then you should never try to do something that breaks the service.

Rate-limiting the IP's as well as giving them a 5-second delay before handling the http requests should be very effective.

1) Increase delays between failed login attempts. Not sure if by rate limiting it's limiting # of attempts per second alone.

2) Consider (if possible) assigning unique login urls for each user, company, group, etc so not all users access login from same URL.

3) Implement 2 factor authentication

4) To attempt chipping away at their install base, log the IP's of failed login attempts, identify top offenders and report to a few places:

- look up IP addresses on ARIN.net, and an automated email sent to the abuse contact email on file for each IP address with supporting proof. A similar approach is likely used for reaching torrent downloaders.

For botnet/hijacked devices this may cause some issues for the end user but maybe it's good for them to know their device may be compromised. If you're being hit with some VPN/TOR IP's..

https://whois.arin.net/ui/advanced.jsp

- Submit IP's to blacklists if not already there.

5) There should be a service that helps identify if you are being visited via VPN service/TOR IP, perhaps that could be a flag for you as well, or deny outright.

Something like fail2ban, too many bad attempts from any IP should go into a fail2ban rule set that uses iptables rules to null route all traffic to/from that IP for a period of 12+ hours.

There is a "recidivist" option for fail2ban to further ban things that show up in the fail2ban log, repeatedly, every 12 hours, for a much longer period such as two weeks.

It seems short sighted to do this. One dirtbag trying to hack logins using a VPN service would poison the VPN's IP(s) for legit users.

Fail2ban typically bans a single IP, not a range.

Maybe tarpit[1] the connections? By rejecting them quickly you help them move on, but if you instead make the pages load as slowly as possible that would waste a lot of their time.

1. https://en.wikipedia.org/wiki/Tarpit_(networking)

I thought this same thing. Figuring out who/when to tarpit might be a little tricky, but here's the basic approach for a Debian system via iptables: https://sysadminblog.net/2013/08/debian-iptables-tarpit/

Came here to suggest that, too. Here’s a tutorial on doing it with the pf firewall:

https://home.nuug.no/~peter/pf/en/bruteforce.html

I would caution against redirecting them to a government run website. I understand the sentiment but it seems like you could quickly run afoul of the regulations surrounding abusive traffic and may be liable if anything bad were to happen.

Loop through these :)

0) Return massive amounts of data.

1) Return empty on requests that go over a requests/second ratio (use memcache)

2) Return fake success pages. [This is super mean]

3) Return dictionary printouts. [Destroys pattern matching]

You can gzip that

fail2ban may prove some use: https://www.fail2ban.org

Whatever you do, do NOT redirect to a gov site.

Yes; if the client is a hijacked browser, it'll have a Referer header in it.

You should just drop packets from badguys unless you are planning on great-cannon-of-chinaing something using 301s. `--reject-with tcp-tarpit` may slow this down but it's probably not worth it if they have 10,000 IPs since that sounds like it's probably comming from a rotating proxy "service."

we use mod_evasive + cloudflare , apache mod evasive is generally effective , we have a static html page which merely says OK for all 403 errors which mod_evasive generates --> this prevents our server resources from being used up to large extent. plus we add abuse IP to cloudflare javascript challenge

Are they actually Android devices? It sounds to me like they're probably just spoofing User Agents.

There are services that specialize in providing mobile proxies at scale for this sort of thing. See luminati.io

I don't understand how that's relevant to what I asked, do you mind elaborating..?

You asked if OP was sure they are android devices and suggested they may be spoofing user agents but it would be relatively easy to tell if they were actually mobile devices on a mobile network by the IP address. Assuming that they are mobile devices on a mobile network, the next question would be how would someone do this other than a botnet of mobile devices, which is essentially what luminati.io is, albeit a little more legitimate. My comment was really just suggested reading for anyone curious.

luminati sells access to desktop devices running hola.org's 'vpn' extension, the software does not run on mobile devices..

Quick way to get lots of IPs by crowd sourcing frameworks usually used for app testing and QA

Attacks usually come from infected computers, routers or other things-of-internet. Could we find a way to inform their owners about malware on their devices? Or even go as far as cleaning malware remotely and rebooting device (which in some cases might be illegal)?

Use https://www.distilnetworks.com/

They use AI to block attacks to your site. You can do a bunch of customizations too. They are expensive though and start at USD 500/mo

Look at using existing products like Cloudflare?

It would seem you don't want to interact too much, so maybe you won't/can't reply to this, but I have a tangential "what if"/suggestion:

Would you, or anyone reading this in a similar position, be interested in sharing further details privately (with or without NDA), and working together to build a solution?

This is the kind of thing I'd love to work on for free. Yes, for free; this is precisely the kind of thing that can't get filed under "awesome exposure!11", and I don't care anyway. I want to learn more about networking and this would be a great hands-on way to do so.

None of these options will solve your issues. Your attackers will simply re-adjust the mechanism as soon as they figure out your heuristics. You'll need to focus on two efforts:

(1) Being able to identify the IPs from which attacks originate, in real time. You will need to blacklist those hosts (for a limited period of time).

(2) Minimizing and limiting the impact of traffic you previously flagged, on your infrastructure. Ideally, as hostile traffic is flagged, a response is never sent (at the TCP/UDP level). You absolutely do not want to serve any flagged requests. Block traffic as early as possible.

so, I tend to disagree: your solutions were the old approach, where you keep trying to block, and hope they dont have a wealth of new source IP's to spawn their attacks from. I think what we find is, this doesn't work any longer.

The new approach I would advise is along your very first point: don't let the attackers know you are on to them: silently sink their traffic into a dead service that doesnt even attempt a password login, but don't let them know. You continue to handle their password bruteforces, but you DONT ever return a success. This could be a straight up static page. This kind of approach only works if you are happy to pay the bandwidth price.. but the nice part is: you keep the attacker occupied, they have no idea they aren't making progress, and the users accounts are safe.

> "hope they dont have a wealth of new source IP's to spawn their attacks from"

You'd still be able to detect new addresses and block as necessary. I don't see your point, of course the solution proposed isn't entirely hermetic, but how does your suggestion overcome this exact issue?

> "This kind of approach only works if you are happy to pay the bandwidth price"

Precisely the reason why most people would rather opt-out of serving malicious requests.

Would be interesting to know if they fit the ‘classic’ credential stuffing methodology (https://breachinsider.com/blog/2017/credential-stuffing-how-...) or if they have moved on to something more sophisticated.

My email is in my profile if you fancy talking specifics, would love to hear about what you’re seeing.

Tarpitting is popular with SMTP, you might be able to do something similar in your web server (but only to those you have identified as "abusers", obviously!).

Would requiring clients to hash passwords for a large number of times before sending them help? I imagine a 3s second effort would be unnoticeable by human users but hurt the attack rate? That and maybe block the offending IPs, at least temporarily?

My suggestion would be to use some alternative log-in method such as client-side public-key authentication (like what ssh is doing, TLS also has support for it). That would make brute-force attempts essentially unfeasible.

> I decided to redirect all requests back to their own IP addresses.

I think this one is something to avoid. What happens if you have a false positive? You've just redirected one of your legitimate users to the attacker.

> You've just redirected one of your legitimate users to the attacker.

I interpreterd it as being redirect back to your own address. E.g if I'm an attacker and my IP is [FE80::2], then I'd be redirected to [FE80::2]. Same for an user. And if you've got attackers from 10k IPs, then I'd think it'd be unlikely that you'd single out a single attacker IP.

Oh, the HTTP scourge.... We run a few websites and we have been doing some work around automatic HTTP traffic... what astonishes me is how much there is...

There's a good video on Toxiproxy from a software engineer at Shopify. I recommend you check it out.

The iptables MIRROR target is fun. Be aware of spoofing though.

Return gzip encoded zip bomb pages. Will crash shabby bots.

What if a legitimate user travels abroad and needs to use the website?

Create two systems: one administrative one for regular users. You don't want regular users anywhere near your administrative system.

edit: why downvote?

I didn't downvote but I think people really hate it when a web site doesn't work in their country for no good reason that they can see. So they're probably mad at you for suggesting a solution that involves allowing people only in certain countries to use a site. You might not have even been suggesting that... maybe you just meant one different login panel per country, which seems a bit silly to me. But downvoters vote on what they think they read, not what you think you wrote.

Redirect loop.

The more creative the solution, the more the script kiddie will enjoy defeating it. You avoid a bully or you punch them in the nose. Never play games with them.

Do NOT redirect to a .gov website.

CFAA is a tractor beam they can use against anyone they don't like.

I work cyber security (well, mostly application security these days and not so much networking/telecomms) and I've also been involved with a small spat as a contractor a few years back. Basically, I had broken a collection source for the FBI by fixing and securing a resource for a certain department for a certain state, and maybe hypothetically it had to do with a very sunshiney state and maybe hypothetically it was a department that involved wheeled objects.

The firm I worked for was contacted by an investigator, which, lemme tell you, when an FBI agent appears at your work and asks your boss what sort of assignment you're working on, have no illusion that he's not about to cover for you in any way. Not that I did anything wrong. So anyways, the investigator asked me why I made all these WAN changes and about what packet filtering I had added/removed/reconfigured, all this technical domain knowledge and be really had a good idea of what I was actually doing. So I was comfortable. Eventually he left, basically saying we may be contacted further or potentially if the "investigation" became more serious, be made to appear in court.

Well the following week, a different guy comes in, and basically sealed me in our little coffee room and interrogated me. I was cooperative as I could be because I thought he was well informed like the other guy and generally had an understanding with my work, but he was a complete asshole.

It ended up that (thank God) all my paperwork was in order and my contract was pretty intensively detailed about what work I was going to be doing, I hired an attorney and he took good care of me. Never made it to court, but I ended up owing the lawyer a couple grand (funny how THEY always get paid) and yeah. Luckily I didn't go to federal prison, and my gratitude pushed me to greener pastures and better states.

TL;DR, your judgment has gotten you this far, so trust yourself, but I've poked the government before and I almost went to federal prison. Ymmv

Has this occurred more than 5 years ago?

Because if not, you're not out of the woods.

I hired the attorney too. I thought (and he thought) it wasn't ever going to make it to court. I moved on to a different job in a different state. Years later, surprise surprise.

NEVER say anything but the word "lawyer" to a law enforcement official. FBI agents make a policy of not recording interrogations (euphemistically referred to as "interviews") with anything but their own notes. Every word you thought he was trying to put in your mouth, he did, successfully, and when and if it makes it into court, it's your word against his, and nobody will believe you.

Yeah this was in 2002. I never heard anything since then about it.

I realized later how badly I fucked up that second interview because you're right, I shouldnt have said anything. It's embarrassing but I was more or less "good fed, bad fed"'d.

I've not had any major incidents of this nature since then, but rest assured, I know what to do now.

Were you a contractor too, or a state employee? How bad did it end up?

Pretty bad. It hasn't ended yet, and it won't for years to come.

The bad part is that the agent's notes can be used to convict not only you, but other innocent parties as well. That happened with me- I've never talked to an FBI agent in my life, but after being woken up half-naked with 17+ FBI agents storming the house and pointing M4 assault rifles at her head, trapped in a fenced backyard, my wife did talk to them, no Miranda warning (2011).

Naturally, half the things in the notes were literally impossible for her to have said. The agent himself didn't even memorialize them in a 302 until 2 days after the whole-house search and seizure. That was good enough for the judge to call it consensual and admissible.

For more details, mattchannon dot org.

Good God, it's depressing what they're capable of.

Don't talk to police:

https://www.youtube.com/watch?v=d-7o9xYp7eE

What to do:

https://www.youtube.com/watch?v=b8S4isIxo2w

It's simple really:

https://lawcomic.net/guide/?p=2897

> but he was a complete asshole

What did he do?

He would frame my answers in such a way to assign malicious intent, accuse me of trying to siphon data out of the system or maliciously make the system less efficient.

"oh! I see, you want to stop the government from looking up drivers' social security numbers..."

"no, but that data doesn't need to be in the same table that the civilian website queries from, just in case."

"just in case what? Just in case I don't catch you stealing civilian's personal information? Just in case I don't catch your ass performing treason in my goddamn system?!"

"no no no, I'm just saying that information should be divided according to where it is expected to be used from, that way if there was ever to be an incident, the more sensitive information is farther away from where the attack surface is"

" so you've thought this through, tell me: how are you gonna do it? When I'm not looking, you empty out a government database and sell it to someone. Who? How? When?? Are you gonna make me sit here all day before you tell me?"

That type of shit.