
Ask HN: "Creative" ways to handle abusive http traffic? - c4e2bedf40955d8
Hi all,<p>I run a pretty popular site that is constantly experiencing some form of abusive traffic- most notably attackers running password dumps against our login endpoint (sometimes from 10k+ ipv4 addresses among several subnets and ASNs).  We&#x27;ve mostly mitigated this with rate limiting, captcha and other forms of &quot;suspicious login&quot; detection. But I&#x27;ve been recently pondering ways to waste their time or resources to make password dumping less appealing.<p>The most recent attack could be accurately and precisely detected, and I noticed the abusive traffic would follow 301 redirects, so I decided to redirect all requests back to their own IP addresses.<p>I don&#x27;t think it really slowed them down, but got me thinking of otherwise to stop&#x2F;slow them down:<p>* 301 redirect them to a &quot;honeypot&quot; server that holds onto sockets for as long as possible and&#x2F;or causes the client to waste time&#x2F;cpu cycles (perhaps, constantly asking the client to renegotiate TLS)<p>* 301 redirect to https:&#x2F;&#x2F;nsa.gov so they might get on someone&#x27;s radar with the time and resources to stop them<p>* Redirect them to a non http protocol, like geo:, potentially blocking the abusive client with a dialog &quot;Want to open this with &lt;Maps Application&gt;?&quot; (Some attacks originate from Android devices- I&#x27;m not sure how deeply the custom protocol hooks are registered and if that would even work)<p>I know abusive web traffic is pretty widespread and was curious how others dealt with it other than standard captcha, rate limiting and iptables rules
======
chasers
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.

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

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

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

~~~
TeMPOraL
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.

------
Buge
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](https://news.ycombinator.com/item?id=14707674)

~~~
timwis
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?

~~~
sprocket
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.

~~~
majewsky
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.

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

?

------
codetrotter
> 301 redirect to [https://nsa.gov](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-...](https://www.amazon.com/Aggressive-Network-Self-Defense-Neil-
Wyler/dp/1931836205)

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.

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

~~~
amerine
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.

------
dahart
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.

~~~
amelius
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.

~~~
beart
Blue Frog tried something like this over a decade ago.

[https://en.wikipedia.org/wiki/Blue_Frog](https://en.wikipedia.org/wiki/Blue_Frog)

It didn't work out so well.

------
ryan-c
> 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.

------
SrslyJosh
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.

~~~
tyingq
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.

------
omribahumi
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.

~~~
jimmies
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.

~~~
salawat
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.

------
r32a_
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](https://www.npmjs.com/package/work-token)

~~~
gruez
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!

~~~
inetknght
> 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.

------
nielsole
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...](https://techcrunch.com/2009/02/16/justintv-is-redirecting-
porn-queries-into-cash/)

Article with retrospection: [https://www.inc.com/tess-townsend/justin-kan-
stop-freaking-o...](https://www.inc.com/tess-townsend/justin-kan-stop-
freaking-out.html)

------
solarkraft
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!

------
nowarninglabel
We use PerimeterX and it's generally worked well for us
[https://www.perimeterx.com/](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.

------
vizzah
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.

~~~
detuur
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.

~~~
vizzah
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.

------
ddtaylor
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.

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

[https://en.wikipedia.org/wiki/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.

------
etcet
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.

~~~
isostatic
Aren't these compromised machines typically desktops?

~~~
natch
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.

~~~
isostatic
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.

------
andrewortman
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

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

~~~
ManlyBread
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.

------
ahje
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.

------
j45
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](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.

------
walrus01
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.

~~~
kardos
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.

~~~
walrus01
Fail2ban typically bans a single IP, not a range.

------
discreditable
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)](https://en.wikipedia.org/wiki/Tarpit_\(networking\))

~~~
jquinby
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/](https://sysadminblog.net/2013/08/debian-iptables-tarpit/)

------
funfunfunction
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.

------
ransom1538
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]

~~~
partycoder
Massive amount of data = not in your best interest, as you pay for this.

~~~
F_r_k
You can gzip that

------
drb91
fail2ban may prove some use:
[https://www.fail2ban.org](https://www.fail2ban.org)

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

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

------
cleanyourroom
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."

------
innodb1
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

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

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

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

~~~
funfunfunction
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.

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

------
butz
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)?

------
timewarrior
Use [https://www.distilnetworks.com/](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

------
plasma
Look at using existing products like Cloudflare?

------
exikyut
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.

------
xtrapolate
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.

~~~
spydum
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.

~~~
xtrapolate
> "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.

------
graystevens
Would be interesting to know if they fit the ‘classic’ credential stuffing
methodology ([https://breachinsider.com/blog/2017/credential-stuffing-
how-...](https://breachinsider.com/blog/2017/credential-stuffing-how-breached-
credentials-are-put-to-bad-use/)) 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.

------
jlgaddis
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!).

------
m3h
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?

------
AnaniasAnanas
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.

------
JimDabell
> 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.

~~~
tambre
> 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.

------
dsign
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...

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

------
todot
There is another way .

1\. just redirect them to their OWN IP .

2\. Just welcome them with a WebJelPool Note : WebJelpool will have infinite (
random ) list of Links with no factual result .. these links will only open a
new Pool of random & infinite list of URL .. & so on . bot / person will be in
a mess with no facts .

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

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

------
jedberg
Set up CloudFlare in front of your site. They were literally built to use
every method of f'ing with spammers on your behalf.

------
procastrinator
Reduce attack surface. Only show login panel for your country or vpn. Show 404
for all others.

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

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

edit: why downvote?

~~~
natch
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.

------
Boulth
Redirect loop.

------
txsh
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.

------
qop
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

~~~
mchannon
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.

~~~
qop
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?

~~~
mchannon
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.

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

