Защита от брутфорса веб-интерфейса по протоколу HTTPS

[Кинетиковод]

Давно не работает защита от брутфорса вебморды. В бете так и не заработала. С учётом того, что у многих вебморда выставлена наружу это не есть хорошо. Изменения параметров защиты ip http lockout-policy применяются, но сама защита так и не заводится.

[hellonow]

Начиная с версии 3.0 была добавлена поддержка 'lockout-policy' (защита от перебора паролей, брутфорса) для протокола HTTPS. Включено по умолчанию для SSL-сервера. Спасибо @Le ecureuil

Записи попыток подбора паролей в журнале - по аналогии с nginx-сервером (http).

[hellonow]

@r13 @ankar84 @Vik2018 "добавлена защита от перебора паролей HTTPS" - да, все правильно, но это касается старого WebUI \ nginx.

Для нового WebUI поддержку 'lockout-policy' для протокола HTTPS планируется добавить в 3.00

[hellonow]

@Кинетиковод по умолчанию логирование неудачной авторизации отключено.

Чтобы включить логирование, необходимо выполнить команду в cli:

ip http log aut
system configuration save

Выключить:

no ip http log aut
system configuration save

Для HTTP протокола! HTTPS не поддерживается!

[Кинетиковод]

1 минуту назад, enpa сказал:

@r13@Кинетиковод@Vik2018функционал поддерживает HTTP протокол, а не HTTPS.

Весь интернет перешел на https, а он и не защищается. Как мило.

[Кинетиковод]

2 минуты назад, enpa сказал:

@Кинетиковод по умолчанию логирование неудачной авторизации отключено.

Чтобы включить логирование, необходимо выполнить команду в cli:

ip http log aut
system configuration save

Выключить:

no ip http log aut
system configuration save

 

Логирование и защита от брутфорса в виде бана не одно и то же. Логирование я включил, чтобы хотя бы наблюдать за работой сетевых дятлов. А кто баны выписывать будет?

[r13]

2 часа назад, Кинетиковод сказал:

Давно не работает защита от брутфорса вебморды. В бете так и не заработала. С учётом того, что у многих вебморда выставлена наружу это не есть хорошо. Изменения параметров защиты ip http lockout-policy применяются, но сама защита так и не заводится.

случайно не через облако тестируете?

[Кинетиковод]

Только что, r13 сказал:

случайно не через облако тестируете?

Нет.

[hellonow]

@Кинетиковод не тот лог. Бан происходит, но не логируется событие. Надо исправлять.

[Кинетиковод]

1 минуту назад, enpa сказал:

@Кинетиковод не тот лог. Бан происходит, но не логируется событие. Надо исправлять.

Если бы так. На самом деле вы можете перебирать пароли до посинения, а потом ввести верный и авторизоваться. 

Логирование тут не при чём. Защита просто не работает.

[hellonow]

@Кинетиковод мой ип был сейчас забанен и я в течение 15 мин не мог резолвить адрес роутера. Прошло ровно 15 минут и в логе вижу:

I [Nov  9 18:30:22] ndm: Netfilter::Util::BfdManager: "Http": unban remote host 193.0.174.20x.

и сейчас могу попасть в gui.

[hellonow]

@Кинетиковод еще раз попробовал воспроизвести Ваши доводы:

E [Nov  9 18:34:07] ndm: Core::Scgi::Auth: authentication failed for user 222.
E [Nov  9 18:34:13] ndm: Core::Scgi::Auth: authentication failed for user 213123.
E [Nov  9 18:34:20] ndm: Core::Scgi::Auth: authentication failed for user ааааа.
E [Nov  9 18:34:29] ndm: Core::Scgi::Auth: authentication failed for user dfdf.
I [Nov  9 18:34:29] ndm: Netfilter::Util::Conntrack: flushed 8 IPv4 connections for 193.0.174.201.
I [Nov  9 18:34:29] ndm: Netfilter::Util::BfdManager: "Http": ban remote host 193.0.174.201 for 15 minutes.

Все работает.

Функционал отрабатывает для всех заявленных протоколов. Возможно на Ваше устройстве не работает. Но вы не предоставили self-test.

[Кинетиковод]

2 минуты назад, enpa сказал:

@Кинетиковод мой ип был сейчас забанен и я в течение 15 мин не мог резолвить адрес роутера. Прошло ровно 15 минут и в логе вижу:

I [Nov  9 18:30:22] ndm: Netfilter::Util::BfdManager: "Http": unban remote host 193.0.174.20x.

и сейчас могу попасть в gui. А вот записи, что я быд забанен, не было.

У меня такого не происходит. Включить защиту через CLI невозможно. Селф выложу чуть позже раз надо.

[Кинетиковод]

Проверил на Омни, защита работает. Странно.

[r13]

@enpa

У меня тоже что-то не хотит, подключаюсь напрямую по https

PS проверял на 2.13.C.0.0-3

ip http lockout-policy 4 60 10

Ноя 9 23:06:34
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:06:44
ndm
Core::Scgi::AuthPool: cleanup: 2 -> 1.
Ноя 9 23:06:49
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:06:49
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:07:00
ndm
Core::Syslog: last message repeated 15 times.
Ноя 9 23:07:04
ndm
Core::Scgi::AuthPool: cleanup: 3 -> 2.
Ноя 9 23:07:06
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:07:06
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:07:06
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:07:06
ndm
Core::Scgi::Auth: authentication failed for user test.
Ноя 9 23:07:22
ndm
Core::Syslog: last message repeated 3 times.

 

Изменено 9 ноября, 2018 пользователем r13

[Кинетиковод]

7 минут назад, r13 сказал:

У меня тоже что-то не хотит, подключаюсь напрямую по https

У меня на Экстре не работает, на Омни работает. Прошивки одинаковые.

[Vik2018]

В 09.11.2018 в 21:30, Кинетиковод сказал:

На самом деле вы можете перебирать пароли до посинения, а потом ввести верный и авторизоваться.

Аналогичная история!

Nov 15 00:22:49 ndm: Core::Syslog: the system log has been cleared.
Nov 15 00:22:51 ndm: Http::SslServer: "SSL proxy xx.xx.xx.xx: 25177": ALPN protocol: HTTP/1.1.
[E] Nov 15 00:22:51 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:22:53 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:22:54 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:22:56 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:22:58 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:22:59 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:23:01 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:23:03 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:23:05 ndm: Core::Scgi::Auth: authentication failed for user guest.
[E] Nov 15 00:23:06 ndm: Core::Scgi::Auth: authentication failed for user guest.
Nov 15 00:23:12 ndm: Core::Scgi::Auth: opened session ZJOVKMEJOHNYZIGN for user admin. 

В 10.11.2018 в 02:12, r13 сказал:

У меня тоже что-то не хотит, подключаюсь напрямую по https

PS проверял на 2.13.C.0.0-3

Keenetic Giga с версией ПО 2.13.C.0.0-4 также не банит адрес атакующего, хотя в настройках задано "ip http lockout-policy 5 15 3". Подключаюсь из интернета по доменному имени (https), заданному в KeenDNS.

Саппорт, будет ли решение проблемы для актуального релиза (не беты)?

 

Изменено 14 ноября, 2018 пользователем Vik2018

[hellonow]

Уточнение. 

@r13 @Кинетиковод @Vik2018 'ip http lockout-policy' - функционал поддерживает HTTP протокол, а не HTTPS. Не путайте пожалуйста.

Для HTTP протокола защита срабатывает, как положено. 

 

 

[ankar84]

Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.

[Кинетиковод]

Только что, ankar84 сказал:

Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно.

Непонятно почему с точки зрения авторизатора http атакующего можно банить, а https нет. Попытки подключения авторизатор отслеживает у обоих. Или он у https дятла не видит адреса? Надо это дело исправлять.

[Vik2018]

1 час назад, enpa сказал:

'ip http lockout-policy' - функционал поддерживает HTTP протокол, а не HTTPS. Не путайте пожалуйста.

Верно, @enpa, и в документации сказано, что для HTTP (TCP/80) и Telnet (TCP/23). Только непонятно, почему официальная техподдержка в таком случае утверждает "в Keenetic OS 2.14 beta, как и 2.13 проблем с безопасностью системы нет"! Ведь по умолчанию, при обращении к интернет-центру по http, он автоматически редиректит на https, а далее можно "перебирать пароли до посинения".

1 час назад, Кинетиковод сказал:

Весь интернет перешел на https, а он и не защищается. Как мило. 

 

1 час назад, ankar84 сказал:

Тоже считаю, что защищать http, но не защищать https, который keenetic os даёт из коробки (за что огромное спасибо, это большая работа) это весьма странно. 

Может быть уважаемые разработчики всё же обратят внимание на это досадное недоразумение...

[r13]

1 час назад, enpa сказал:

Уточнение. 

@r13 @Кинетиковод @Vik2018 'ip http lockout-policy' - функционал поддерживает HTTP протокол, а не HTTPS. Не путайте пожалуйста.

Для HTTP протокола защита срабатывает, как положено. 

 

 

не не не Девид Блейн, еще в 2.11 было

 

[Vik2018]

Цитата

Версия 2.11.A.6.0-0:

• включен автоматический редирект на доменах с SSL-сертификатом, с возможностью отключения:
• добавлена защита от перебора паролей HTTPS

@enpa, прокомментируйте ситуацию, если Вы имеете отношение к разработке.

@ndm, @Le ecureuil, @eralde просьба также подключиться к дискуссии.

Изменено 16 ноября, 2018 пользователем Vik2018

[ankar84]

4 минуты назад, r13 сказал:

не не не Девид Блейн, еще в 2.11 было

Действительно, начиная с версии 2.11.A.6.0-0 где явно указано, что защита от перебора https есть.

[Le ecureuil]

Все вам уже сказали в этой теме.

В 2.11.A.6 была добавлена защита https для старой морды (читай digest / basic авторизации).

При работе с новым Web используется form-based авторизация. Вот для нее для http была сделана защита, для https - не успели. Да и это не настолько критично - боты не умеют нашу form-based auth, и при запросе "GET /" всегда отдается "200 OK", потому пока они ее научатся определять и пытаться подбирать пароль - мы доделаем и https.

В задачах есть, будет сделано.