4

We are developing a community portal service using Java-Spring and Angular UI. We are also going to have an Android app soon. Our back-end exposes many services via REST API. There are couple of services which allows anonymous posting and creating service requests.

Here are our questions:

How can we protect API from DDoS-like attacks? Can we do IP whitelisting or put a cap on requests per minute for certain set of APIs? How can we log such malicious requests? Thanks in advance. Best Regards.

(See this question on SF at - https://stackoverflow.com/questions/38637175/how-to-protect-api-from-from-malicious-usage)

  • How do you protect your main website from those same attacks? Or does the API expose services the normal website doesn't provide? – André Borie Jul 28 '16 at 13:56
  • Sounds like this should be the function of your firewall device rather than the web server. – TTT Jul 28 '16 at 13:58
  • 1
    an API is just a funny looking webpage, secure it like any other http traffic. – dandavis Jul 28 '16 at 17:12
  • @AndréBorie The APIs which needs to be protected, create content on server. This is community web portal, so anyone anonymously post content from mobile. If it were HTML form, captcha would do the job! – navaltiger Jul 29 '16 at 6:37
  • @navaltiger put a captcha on the API as well, and have your Android app display the captcha. You could allow people to purchase tokens so they can post without the captcha, so legitimate people can buy those while spammers won't bother. – André Borie Jul 29 '16 at 14:05
1
  1. The API needs to be secure, so don't try to make trade-offs here. It won't be good ;-) However, don't trade-off on performance either, it needs to be very fast so then it will be stable. Use Cookies which are very good (there's plenty of info around here).

  2. Apart from usual security precautions (Cookies etc), the following I found to be the must:

    • Good limits on number of concurrent requests to Tomcat (or whatever you use, it's normally in web connector directive) - you can load-test it so server is not overloading on full load, so that makes servers not crash under full load but also they got well utilized, for example with ab -c <number of connections>. And then, in front of these Tomcats put load balance to distribute traffic and shield from other attacks like packet floods. Load Balancer should have tuned TCP/IP stack for such scenarios (see below).
    • Geographically dispersed servers in Cloud, so with GSLB load balancing and autoscaling
    • Try to use in-RAM cache as much as you can
    • Use scalable databases, like DynamoDB in AWS, but good MySQL instance will also do, so they can scale-up with your load
    • Make sure any single API function is not slow, this can be done in unit tests (so with every test run you can see whatever there's no potential target for DDoS), making all API calls very fast you basically make DDoS problems very small and your website very nice.

The above things in bold are what usually I do after developers do their stuff basically to make it faster and more resilient and that's my 4 golden points :-)

From my experience it takes 20GBps network and 4-6 32 core servers to mitigate any spike like that to Tomcats anyway. It just doesn't happen more than that and the resources today are cheap to deal with it, and even on demand. The problem is when something is slow or not scalable like Databases, then the resources go too high and that's the problem.

For developers doing the API the main point is to use in-RAM cache. The rest is infrastructure / server with Tomcat build. I've seen some developers actually doing things like that and that's good and simple approach. So instead of every time checking Cookie with database, keep it in RAM, use sticky sessions etc. Same for other things. Like one poller to database which loads data into RAM every minute and other threads are using it without ever touching DB. I've seen this approach as well.

Infrastructure-wise, it's good to have Load Balancer in front of Tomcats and if it's not Cloud one, then you can do following.

  1. Setup normal load balancer like HAProxy and put limits for each server, so in case of large number of real HTTP requests you can process them and forward to Tomcats, other software might be able to drop or filter bad requests base on configured rules - you could try Varnish Cache which is Cache, but for Load Balancer with filter it's also excellent and you can program your own logic.

  2. Tune the TCP/IP stack of load balancer so it's resilient to large number of requests or SYN packets. So following tuning is effective:

    • No IPTABLES on it (just filter things on switch)
    • Disable SynCookies net.ipv4.tcp_syncookies = 0
    • Try net.ipv4.tcp_tw_recycle = 0
    • And net.ipv4.tcp_tw_reuse = 0

The last two can help achieving a lot's of incoming new connections per second.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.