Re: Защитить сетевые сервисы от спама, перебора паролей и DDOS.

2016-01-18 Пенетрантность Oleksandr Gavenko
On 2016-01-18, Лев Аржанов wrote:

> Одним пакетом все задачи не решить. Кроме уже рассмотренного, против
> тупого подбора паролей и перебора url может помочь fail2ban. 

  http://www.fail2ban.org/wiki/index.php/Main_Page

  Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that
  show the malicious signs -- too many password failures, seeking for exploits,
  etc. Generally Fail2Ban is then used to update firewall rules to reject the IP
  addresses for a specified amount of time, although any arbitrary other action
  (e.g. sending an email) could also be configured. Out of the box Fail2Ban
  comes with filters for various services (apache, courier, ssh, etc).

Сканировать по логам - мне понятно и никаких модификаций в существующий софт
вносить не надо.

Далее есть ответ на мой вопрос по поводу практик автоматической блокировки:

  update firewall rules to reject the IP addresses for a specified amount of
  time

Конешно нужно разобраться с адаптерами под формат логов, уживается ли пакет с
logrotate и запоминает ли смещения в файле (перечитывать большой лог и
выдавать повторные алерты - неразумно).

Есть в Debian:

  $ sudo apt-get install fail2ban

Спасибо за наводку!

-- 
http://defun.work/



Re: Защитить сетевые сервисы от спама, перебора паролей и DDOS.

2016-01-18 Пенетрантность Sohin Vyacheslav


18.01.2016 02:53, Oleksandr Gavenko пишет:
> Задача - уведомлять об атаках на VPS + улучшить жизнеспособность VPS.

OSSEC is a free, open-source host-based intrusion detection system
(HIDS). It performs log analysis, integrity checking, Windows registry
monitoring, rootkit detection, time-based alerting, and active response.

http://ossec.github.io

-- 
BW,
Сохин Вячеслав



RE: Защитить сетевые сервисы от спама, перебора паролей и DDOS.

2016-01-17 Пенетрантность Pavel Marchenko
Zabbix это по мониторингу. умеет дергать все что скажут. Делает http проверки. 
Умеет реагировать на алерты заданными действиями, а не просто слать письма. 
Читает логи.

Определение ddos и переборка паролей я думаю это l7 фильтрация и лучше 
переложить это на железку.

Хорошая тулза для глобальной сборки логов и парсинга logstash. Можно заставить 
работать в паре с заббиксом. 

-Исходное сообщение-
От: "Oleksandr Gavenko" <gaven...@gmail.com>
Отправлено: ‎18.‎01.‎2016 3:53
Кому: "debian-russian@lists.debian.org" <debian-russian@lists.debian.org>
Тема: Защитить сетевые сервисы от спама, перебора паролей и DDOS.

Хочу разобраться какие меры и средства могут быть предприняты против:

 * спама (как осмысленного, понимающие API сервиса так и бессмысленного,
   например прощупывающего URL вида /admin, ~root, ...)

 * перебора паролей

 * DDOS

Естественно решение в рамках пакетов Debian и возможно рекомендаций с чем
обращатся к хостеру если есть легко доступные аппаратные решения.

Порылся в офиц. руководстве:

  $ zgrep 'intrusion\|detection' 
/usr/share/debian-reference/debian-reference.en.txt.gz

|   |  | | |monitoring 
and |
|   |  | | |management  
   |
|nagios3|V:1,  |1|, ,  |system for  
   |
|   |I:12  | | |hosts, 
services|
|   |  | | |and 
networks   |
|   |  | | |(Nagios)
   |

|   |  | | |flexible
   |
|   |V:2,  | | |network 
   |
|snort  |I:3   |1707 |, ,  |intrusion   
   |
|   |  | | |detection   
   |
|   |  | | |system 
(Snort) |

Я про эти комплексы знаю не больше чем по Wikipedia или обложке книг.

Может они неактуальны (их давно вписали в руководство, но обновлять
руководство нету желающих?).

По идее относительно полный список есть тут:

  https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
  https://en.wikipedia.org/wiki/Category:Intrusion_detection_systems

и еще такие класные ключевые слова (по которым напрямую полезную информацию я
не вижу):

  https://en.wikipedia.org/wiki/Intrusion_prevention_system
  https://en.wikipedia.org/wiki/Real-time_adaptive_security

Задача - уведомлять об атаках на VPS + улучшить жизнеспособность VPS.

VPS/VDS - это 256/1024/2048 MiB RAM + 1-2 CPU + 2.0-20.0 GiB STORAGE и там
сервисы для мелкого бизнеса или персональный хостинг (CV/blog/git).



Как мониторить CPU / MEM / IO?

И сообщать на email при превышении порога в течении промежутка времени?

Также интересно чем мониторить размер доступного места в хранилище. Неприятно
будет если логи забьют все пространство.

Я так понимаю nagios3 охватывает эти вопросы. Имеет смысл искать на
альтернативы?



nagios3 - глуп? Т.е. например есть 100% CPU - он скажет какие процесы в top?
Или DOS с определенного хоста - мне дадут IP?



Есть ощущение что с помощью nagios3 не лазят по accesslog и прикладным логам
что бы определить аномальную активность пользователей?

Для этого snort? Есть ли смысл искать / сравнивать с альтернативами? 

С помощью snort можно определять фейковые регистрации на форуме или спам в
коментариях к блогозаписи? Или только пороговая статистика - что то поисходит
чаще чем нужно?



Далее допустим идентифицирован процес, сжирающий 100% CPU в течении 20 мин или
IP адрес бомблящий или перебирающий URL на :80.

Кто будет прибивать автоматом прожорливый процес или добавлять временное
правило в файервол?

Я за структурированый способ оформления правил реагирования, потому как
костыли на cron, клее и резине в состоянии накропать...



Глупый DDOS забивает канал. Будет ли уходить исходящие пакеты с сервера?
Например - отправка письма с алертом?



Как бороться с подбором паролей? Я знаком с одним живым примером - Tomcat 8 в
Debian идет с включеным:

  /etc/tomcat8/Catalina/localhost/manager.xml

В manager.log периодически пишет что кто пытался авторизоваться...

Выходит что злоумышленник знает об устройстве сервисов, формате данных (пусть
и scriptkid'ер).

Я узнал о проблеме просматривая лог. Формат записи не думаю что
документирован. Мне нужно регвырами по логам самостоятельно узнава

Re: Защитить сетевые сервисы от спама, перебора паролей и DDOS.

2016-01-17 Пенетрантность Лев Аржанов
В Пн, 18/01/2016 в 02:53 +0200, Oleksandr Gavenko пишет:
> Хочу разобраться какие меры и средства могут быть предприняты против:
> 
>  * спама (как осмысленного, понимающие API сервиса так и бессмысленного,
>например прощупывающего URL вида /admin, ~root, ...)
> 
>  * перебора паролей
> 
>  * DDOS


Одним пакетом все задачи не решить. Кроме уже рассмотренного, против
тупого подбора паролей и перебора url может помочь fail2ban. 


-- 
С уважением,
Лев Аржанов



Защитить сетевые сервисы от спама, перебора паролей и DDOS.

2016-01-17 Пенетрантность Oleksandr Gavenko
Хочу разобраться какие меры и средства могут быть предприняты против:

 * спама (как осмысленного, понимающие API сервиса так и бессмысленного,
   например прощупывающего URL вида /admin, ~root, ...)

 * перебора паролей

 * DDOS

Естественно решение в рамках пакетов Debian и возможно рекомендаций с чем
обращатся к хостеру если есть легко доступные аппаратные решения.

Порылся в офиц. руководстве:

  $ zgrep 'intrusion\|detection' 
/usr/share/debian-reference/debian-reference.en.txt.gz

|   |  | | |monitoring 
and |
|   |  | | |management  
   |
|nagios3|V:1,  |1|, ,  |system for  
   |
|   |I:12  | | |hosts, 
services|
|   |  | | |and 
networks   |
|   |  | | |(Nagios)
   |

|   |  | | |flexible
   |
|   |V:2,  | | |network 
   |
|snort  |I:3   |1707 |, ,  |intrusion   
   |
|   |  | | |detection   
   |
|   |  | | |system 
(Snort) |

Я про эти комплексы знаю не больше чем по Wikipedia или обложке книг.

Может они неактуальны (их давно вписали в руководство, но обновлять
руководство нету желающих?).

По идее относительно полный список есть тут:

  https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
  https://en.wikipedia.org/wiki/Category:Intrusion_detection_systems

и еще такие класные ключевые слова (по которым напрямую полезную информацию я
не вижу):

  https://en.wikipedia.org/wiki/Intrusion_prevention_system
  https://en.wikipedia.org/wiki/Real-time_adaptive_security

Задача - уведомлять об атаках на VPS + улучшить жизнеспособность VPS.

VPS/VDS - это 256/1024/2048 MiB RAM + 1-2 CPU + 2.0-20.0 GiB STORAGE и там
сервисы для мелкого бизнеса или персональный хостинг (CV/blog/git).



Как мониторить CPU / MEM / IO?

И сообщать на email при превышении порога в течении промежутка времени?

Также интересно чем мониторить размер доступного места в хранилище. Неприятно
будет если логи забьют все пространство.

Я так понимаю nagios3 охватывает эти вопросы. Имеет смысл искать на
альтернативы?



nagios3 - глуп? Т.е. например есть 100% CPU - он скажет какие процесы в top?
Или DOS с определенного хоста - мне дадут IP?



Есть ощущение что с помощью nagios3 не лазят по accesslog и прикладным логам
что бы определить аномальную активность пользователей?

Для этого snort? Есть ли смысл искать / сравнивать с альтернативами? 

С помощью snort можно определять фейковые регистрации на форуме или спам в
коментариях к блогозаписи? Или только пороговая статистика - что то поисходит
чаще чем нужно?



Далее допустим идентифицирован процес, сжирающий 100% CPU в течении 20 мин или
IP адрес бомблящий или перебирающий URL на :80.

Кто будет прибивать автоматом прожорливый процес или добавлять временное
правило в файервол?

Я за структурированый способ оформления правил реагирования, потому как
костыли на cron, клее и резине в состоянии накропать...



Глупый DDOS забивает канал. Будет ли уходить исходящие пакеты с сервера?
Например - отправка письма с алертом?



Как бороться с подбором паролей? Я знаком с одним живым примером - Tomcat 8 в
Debian идет с включеным:

  /etc/tomcat8/Catalina/localhost/manager.xml

В manager.log периодически пишет что кто пытался авторизоваться...

Выходит что злоумышленник знает об устройстве сервисов, формате данных (пусть
и scriptkid'ер).

Я узнал о проблеме просматривая лог. Формат записи не думаю что
документирован. Мне нужно регвырами по логам самостоятельно узнавать проблемы?

Выходит что сервис, которого ты не понимаешь (не задоукментированы сообщения о
проблемах) - нужно закрывать.



Пускай наоборот мы собственно писаном сервисе. Как сообщать о подборе паролей
- через лог? Или комплексы на подобии snort умеют слушать через сокет?

Интересно конечно что бы сервис ничего не знал об IDS. Я бы общался через
*внешнюю* настройку в системе логирования.

Сейчан начинаю понимать нафик нужен (для Java-приложений):

  http://www.slf4j.org/api/org/slf4j/MDC.html

- что бы структурировано отдавать диагностические данные.

Конешно можно придумать свой формат для