"Too many failed AUTH attempts" protection in Redis AUTH command?
James Chou
Lately I've been researching security practices for Redis, since it
seems too easy for anyone with a Redis client to connect to a db
(given the ip, port, and brute-force the auth key)
According to http://redis.io/commands/auth, I noted this:
"Note: because of the high performance nature of Redis, it is possible
to try a lot of passwords in parallel in very short time, so make sure
to generate a strong and very long password so that this attack is
infeasible."
Now, if there would be a built-in feature where if there are too many
(over a certain threshold, as specified in the config) failed AUTH
attempts, the server could ban the IP, or not allow any more AUTH at
all (until the server proc gets killed by a sysadmin).
I have not come across anyone that suggests this, so I thought I might
throw it out there and see what you guys (including Salvatore ;-)
think!
Regards,
James
James Chou
DDoS prevention. The attacker may not only be interested in data
access, but to block off access for other users. Banning the attacker
IP may lessen the impact...
Regards,
James
On Oct 20, 11:33 am, James Chou <james.j.c...@gmail.com> wrote:
> Hello all,
>
> Lately I've been researching security practices for Redis, since it
> seems too easy for anyone with a Redis client to connect to a db
> (given the ip, port, and brute-force the auth key)
>
Salvatore Sanfilippo
DOS is not possible this way, AUTH is just a common command.
I think a feature like you suggested is not very helpful in this
context. There is no "user" for this password, an human I mean, so all
the sysadmin needs to do to avoid this attack is picking a good very
long password.
Instead the protection can easily become a good excuse to pick a weak
password, or something you can use to actually mount a DOS.
Cheers,
Salvatore
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
>
--
Salvatore 'antirez' Sanfilippo
open source developer - VMware
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
James Chou
That does....make a little sense... as you said, AUTH is just a
command that gets issued to the redis server, just as a million GET/
SET/any-other-command per second *won't necessarily ruin it for other
users*. When I said users, I meant "data consumers", i.e. any clients
connecting to a redis server.
I'm just wondering, though, since larger-than-usual number of AUTH
commands issued at a redis server in a short period of time would
suggest some bad guy is trying to break in, that may or may not be in
the best interest of the server to continue to serve up responses to
their AUTH commands (and even unnecessary - although it's the same
"invalid password" response every single time)...
I just realized this is probably more of a performance-related
question than security-related...
Just a thought, but thank you for your reply!
James
Josiah Carlson
level. The moment that Redis gets a socket connection accept from a
client, that will take time to process, even if it is just to close
the connection in a blacklist scenario. So the potential DOS can
happen regardless.
The right answer is: the plain-text password situation is not
security. It keeps honest people out, and applications from
accidentally connecting to the wrong database. It's like the lock on
your front door.
Security starts with not leaving Redis accessible to 3rd parties, as
in: don't leave your Redis open to the world (just like people don't
leave MySQL, Postgres, Oracle, etc. databases open to the world, why
does it make sense to leave Redis open?). If someone has network
access to make calls to your Redis and attempt to brute-force the
password, you've got other network security issues, and it may be at
least as easy to gain access to the machine, debug memory regions
looking for the key, copy the dump, set up an ipfilter rule to copy
traffic somewhere else, sniff traffic to/from the box via ARP
poisoning, etc.
Summary: the password was never meant to be secure.
Regards,
- Josiah
James Chou
Very true, your points are well-noted. I am really new in the security
realm, and I may be just looking everywhere with no clear sense
direction on exactly what to protect...so I thank you for using real-
world analogies to make these points clearer.
In regards to passwords, here's something just for kicks: "Password
Strength" from http://xkcd.com/936/
Cheers,
James
Josiah Carlson
> Hello Josiah,
>
> Very true, your points are well-noted. I am really new in the security
> realm, and I may be just looking everywhere with no clear sense
> direction on exactly what to protect...so I thank you for using real-
> world analogies to make these points clearer.
If you're not already reading Bruce Schneier, you should be.
> In regards to passwords, here's something just for kicks: "Password
> Strength" from http://xkcd.com/936/
The real answer is to memorize a single very difficult password (12
character upper/lowercase alphanumeric, randomly generated), then use
key escrow in a password agent provider (like ssh-agent in linux). Or
replace that password with public/private key and NFC with a device
under your skin. But that's just the paranoid part of me talking.
Regards,
- Josiah