Handling attacks?

[abatie]

I just upgraded to 3.x and want to use the opds server so I can get to my library remotely, but before I open it up to the outside world, I wonder how it handles attacks? Typically I like to block ip addresses that fail x times in y minutes with a few whitelisted addresses.

[kovidgoyal]

Just put a password on it. There is no need for blocking IPs. Indeed, I'm not sure what blocking IPs would do to prevent an attack, anyway.

[davidfor]

What @abatie said is a common practice for defence against a lot of different attacks. The password should prevent access, but it does nothing for a DDoS attack or an attack attempting to crack the password. Blacklisting an IP that an attack appears to be coming from, will reduce the severity of the attack and might stop it completely.

I don't think that calibre should do anything about DDoS attacks. If someone is worried about that, then an appropriate firewall or using a proxy with the defence against these. But, blacklisting an IP after a few password errors might be something that can be done.

[Divingduck]

+1 @davidfor

A bit more implemented safety might be not bad at all.

I made some tests a month ago by opening non standard ports for calibre to the web. It takes less then 5 minutes as first bots attacks to the ports began. No problem at all, but it shows how fast unexperienced peoples can come in trouble without knowing it.

Theses days it's easy to set up a calibre server. Hope the guys make their homework first.

[chaley]

I use fail2ban on my linux-based VPS. It can take a bit of setup to get things right, especially with a service that isn't included in the normal configuration, but once it is running it works well. On my setup it deals with attacks on sendmail, apache (proxy attacks, wordpress, etc), calibre, and other tools. I handle ssh attacks differently because a) there are so many attacks, sometimes coming at rates of 100s per second, and b) I publish the list of attacking IPs as a host.deny file.

I wouldn't ever expose a computer on my home network to the internet no matter what operating system it runs. If a bad guy gets into that machine then there is a very good chance that every other machine on the home net will be hacked. In the past I have built a real DMZ (two firewalls with double-NAT), but these days a cheap VPS works as well or better and I don't need to maintain the hardware.

[kovidgoyal]

Any serious DDos is not possible to mitigate at an application server level. By the time you get to the application server, the request will already have used up a signficant amount of resources. The place to defend against DDoS is at edge routers. In any case, given that calibre is a personal server, I dont exactly see worrying about DDoSes as in its remit.

The best way to protect HTTP application servers in general is to set them up behind a reverse proxy such as nginx. Then you can implement all your safety features/IP bans etc in one place, before any heavy application resources are utilized.

[abatie]

Originally Posted by kovidgoyal

Any serious DDos is not possible to mitigate at an application server level. By the time you get to the application server, the request will already have used up a signficant amount of resources. The place to defend against DDoS is at edge routers. In any case, given that calibre is a personal server, I dont exactly see worrying about DDoSes as in its remit.

The best way to protect HTTP application servers in general is to set them up behind a reverse proxy such as nginx. Then you can implement all your safety features/IP bans etc in one place, before any heavy application resources are utilized.

No, you can't deal with DDOS, but you can stop brute force password attacks easily. While I can setup nginx to do this (and have, at work), I doubt that's true of the average calibre user, and it's a lot of work even when you know how to do it. If calibre logs failed login attempts, I can at least use fail2ban, which would be somewhat easier.

While it's not a huge deal if someone gets access to my library, it provides a much larger attack surface to find vulnerabilities in calibre's server if they do get in.

[kovidgoyal]

Is it even possible to brute force passwords over a network? Given network latencies you'd need to be extremely lucky (or have the user use extremely poor passwords) to actually succeed at brute forcing. A quick back of the envelope calculation, given that both digest auth (with a nonce, which calibre uses) and HTTPS require multiple roundtrips, lets assume a best case latency per auth request of 20ms (in reality it would be much higher). That gives us ~ 4e6 requests a day. Now assume a 8 char password containing letters, numbers and symbols that is not in a rainbow table (i.e. is not a dictionary word or common name or such). That gives us a search space of 8^80. Which means it would take your attacker approx 10^63 years to cover that search space. Now assume even that the attacker uses a million computers to connect to the calibre server in paralllel, that still means 10^57 years. I dont think you have to worry about passwords being brute forced, as long as you use decent passwords.

And the calibre server does log all HTTP requests alongwith a response code, including failed authentications (response code 401) in the access log, so you can use that for fail2ban.

Though again, IP blocking is not going to help you against all but the most incompetent of attackers.

[davidfor]

There are definitely people trying it. A mail server at a previous job had a least one attack a day. Most were dictionary attacks on root and other common usernames. But, there were much more extensive attacks that could go on for days if we didn't block them.

[kovidgoyal]

And this commit should cause failed login attempts to be logged to the main log as well https://github.com/kovidgoyal/calibr...d031ef3e535969

[kovidgoyal]

Originally Posted by davidfor

There are definitely people trying it. A mail server at a previous job had a least one attack a day. Most were dictionary attacks on root and other common usernames. But, there were much more extensive attacks that could go on for days if we didn't block them.

I'm not saying there aren't people trying it, I'm saying they wont succeeed unless you use poor passwords.

[Divingduck]

Originally Posted by kovidgoyal

And this commit should cause failed login attempts to be logged to the main log as well https://github.com/kovidgoyal/calibr...d031ef3e535969

I have just recognize it.

You are are correct in your argumentation. On the other side it is as well true, that these kinds of penetrating attacks in networks 24/7h exists. For me it's more a "little stone in the wall"-thing what helps to make a little bit more prevention against these idiots.

There are a lot calibre users that can't even imagine what they are doing. We can't prevent them for making stupid thinks at all. So it's at least a little bit more passive security benefit for all normal users with a minimum on programming effort.

for implementation.