Правильный способ борьбы с угрозами безопасности веб-сервера в рамках бюджета [закрыто]
Во время нашего ежегодного обзора безопасности мне напомнили об инциденте в начале этого года, когда мы получили угрозу для веб-сервера нашей организации. Это было нарушением политики организации и угрозой DDoS-атак на наш сайт. К счастью, ничего плохого из этого не вышло, и это оказалось пустой угрозой. Тем не менее, мы по-прежнему немедленно уведомили ИТ-директора, директора по безопасности, генерального директора и нашего хостинг-провайдера, которые приветствовали наш ответ. Из-за характера нашей организации (в сфере образования) в превентивном реагировании было задействовано много людей, включая координацию с местными правоохранительными органами.
Несмотря на то, что наш ответ был достаточным на пустую угрозу, я понимаю, насколько мало подверглось планирование атак на веб-приложение.Прямо сейчас установка такова:
- Linode VPS, который не защищен корпоративным брандмауэром (за этим стоит длинная история, которую не стоит объяснять)
- БД PostgreSQL на том же сервере, которая разрешает только локальные соединения
- ] сервер Nginx, которому мы в настоящее время следуем лучшим практикам для защиты [ 1 ]
- SSH-доступа, который мы переводим на аутентификацию по сертификату
- Резервный VPS, который имеет все последние настройки сервера и просто нуждается передана последняя версия кода и перенесены настройки базы данных (сейчас используется в качестве тестового сервера, но также рассматривается как вариант геоизбыточности)
Думаю, мой вопрос, вероятно, можно свести к тому, какие еще шаги я должен предпринять, чтобы заблокировать свой сервер а также защитить от DDoS? Мы хотели бы использовать Cloudflare Business с их защитой от DDoS-атак, но нам это не всегда нужно, а 200 долларов в месяц - это немного дорого для организации. Мне это вообще нужно? Есть ли решение, позволяющее временно защитить от DDoS-атак? Если нет, то как лучше всего поддерживать стабильность во время / после атаки? Наконец, какое ведение журнала необходимо реализовать, чтобы мы могли помочь правоохранительным органам в случае атаки?
what other steps should I take to lock down my server as well as protect from DDoS?
- Firewall off any ports and protocols that are unused. Limit access to only trusted IPs where applicable and possible.
- Apply all security patches and updates in a timely fashion
- Implement a network monitor that can alert on suspicious bursts of activity
$200 a month is a bit steep for the organization. Do I even need this?
No. Not until it adds value and becomes a must have.
Is there a solution that allows temporary DDoS protection?
Yes. They may involve a fair amount of upfront time investment in sorting out the complications of implementing their DDoS service. http://www.blacklotus.net/protect/emergency-ddos-protection is one such on-demand service.
If not, what is the best way to maintain stability during/after an attack?
Just sit there and take it. That's the nature of DDoS. You can try and firewall off IPs, but if the attack is really distributed...well that's just like fighting a wildfire with a squirt gun.
Finally, what logging should be implemented so that we can assist law enforcement in the event an attack occurs?
Maintain logs of incoming source IPs and timestamps and any other relevant forensic data. For example if it's a web server, try and log the user agent, the requested resources. Traffic rates, like packets per seconds, and number of request per second are helpful.
DDoS boils down to mathematical analysis. If someone is trying to extort you they're betting that they can disrupt your business enough to force you to pay protection money to prevent it. Scale is a factor, it's easier to take down smaller operators, but they're able to pay less. If you get an email threat - the best course of action is to ignore it. It takes significant botnet resources to initiate and sustain DDoS attacks - they can't just outright blast everyone like spammers. Chances are they're just doing a massive phishing blast looking for easy targets to intimidate. Due to the nature of the the DDoS beast, victims are fairly helpless unless they can deploy a sophisticated packet filtering prevention scheme or have the budget to contract outside services.
inetplumber's answer is great.
I would add that another option is to configure your app to scale, so that you could handle a larger attack without impacting your user. You can set up a Virtual Private Cloud (VPC) on Amazon AWS, for example, with your PostgreSQL server accessible only from inside your VPC. You can set up a load balancer front end to distribute the load among multiple servers.
The advantage of doing it that way is that you could quickly scale up to 100's (or more) of servers with no upfront investment, and very quickly (if you were already configured), making you a much more difficult target. You would only need to pay for those servers during hours you were actually under attack. When you were not under attack, you would only need to pay for your one web server and one database server.
The hard part would be getting set up, and it is certainly somewhat more complex than your current configuration. Setting up to rapidly scale up would require even more work. But if you are looking for something you could do to plan (especially if, due to other issues, you think you might be a target in the future), that would be it.
what other steps should I take to lock down my server as well as protect from DDoS?
if your webapp is not interactive and just displays content: use nginx + proxy-cache with a short-cache-time (1-5 minutes is usually ok). this increases performance a lot and forces an attacker to allocate more resources
setup a resticted firewall that filter everything unneeded IN and OUT by setting INPUT/OUTPUT/FORWARD-Policy to DROP; be sure to log every outgoing connectiona-atempt (except for UPD port 53 :)
if you cannot restrict SSH to a static management-ip, use an alternate high port like 22222, this will prevent a lot of "hello mcfyl - someone in there" - knockers
additionally, use fail2ban/denyhosts to protect ssh from brute force attacks
if you have admin-resources: use OSSEC and a lightweight WAF (there's naxsi for nginx, lightweight and not such a PITA as mod_security), but you'll need someone to setup and maintain such installations
implement backups and use your standby-server as a backup-target
keep your webapp-code up-to-date; if you use an open-source-project, sign up to their security-mailinglist.
try to avoid software that is known to have a lot of vulnerabilities
if you use admin-login and/or managament-webapps: establish basic-auth for those logins + ssl (self-signed cert is OK).
use ssh-tunneling whevener you can instead of opening ports, e.g. for development
If not, what is the best way to maintain stability during/after an attack
- keep calm
- have someone with experience at hand for such a case
- have some emergency-plans ready
the most important thing you did already: thinking about it ( and possible countermeasures ) before it happens.