Ejabberd. Защита на костылях

[Slipeer]

Не пробовали использовать вместо построчного перебора на bash'е подобную конструкцию на sed:

sed 's/(<регулярка, описывающая характерный признак первой строки>)/\1/; !t fin; N; N; N; s/\n/ /; : fin'

для подготовки «оптимизированного» лога?

[Bansher]

Честно говоря не хватило у меня времени на полноценное изучение sed и awk. У меня есть стойкое ощущение что при их помощи скрипт можно было бы уместить в 3-4 строки. Но уж больно меня торопили.

[Slipeer]

Пренепременно найдите его в рамках оптимизации Ваших скриптов: один вызов sed'a может работает гораздо быстрее цикла на bash!

[Bansher]

Абсолютно согласен. По сравнению с bash sed даже не летает, а телепортируется :)) Slipeer, я понял вашу мысль в каком направлении курить :)

[lightoze]

А что будет в этом случае?

1. =Дата, время====
2. Сообщение о подключении с ip адреса 1
3. =Дата, время====
4. Сообщение о подключении с ip адреса 2
5. =Дата, время====
6. Сообщение об ошибке 1.
7. =Дата, время====
8. Сообщение об ошибке 2.

[Bansher]

Лог ejabberd пишется строго — «время, ip, время, событие». Давно за ним наблюдаю. Пока не путается.

[Slipeer]

ну…
В этом случае предложенный мною вариант, по крайней мере, не хуже оригинала автора.
Но, подозреваю, что такого случая не будет — иначе лог теряет весь свой смысл — при такой записи невозможно определить какая ошибка к какому адресу относится. (Либо у нас недостаточно исходных данных о формате лога).

[ZimniY]

Bansher, ещё посмотрите в сторону inotifywatch/inotifywait на файле оригинального лога. Это даст Вам возможность отслеживать изменения лога в реальном времени (если меня склероз не подводит). В данном случае можно отрезать последние 4 строки от лога «на лету» и отдавать Вашему парсеру для fail2ban.

[Bansher]

Спасибо. Посмотрю.

[Osipov]

Да еще в ip адресе в качестве разделителя используются запятые О_о.

Кортежи же (см. www.erlang.org/doc/reference_manual/data_types.html), классический вывод. Иначе реализовать логирование можно, только не стоит оно того.

А вообще надо придумывать такие пароли, чтобы в разумное время их невозможно было подобрать.

[aim]

проблема в том что разумное время иногда — это бесконечность.

[equand]

github.com/athoune/mod_syslog + syslog-ng
И будет Вам счастье.
Направьте на скрипт и будет реалтайм парсинг

[foxmuldercp]

Хм. Еще, конечно, вариант — найти в коде демона код, отвечающий за логирование и немного пошаманить для фейл2бан

[shanker]

Я правильно понял, что проблема возможности прослушки трафика не устранена (и такая задача вообще не ставилась изначально), а сделано логирование попыток неудачного ввода пароля (т.к. сервис «висит» наружу для всего инета и любой может попробовать приконнектиться)? И теперь копошитесь в логах пытаясь выяснить подбор пароля то был или сотрудник сам ошибся?
Какое примерное кол-во сотрудников пользуется сервером (всего, а не в единицу времени)?

[aim]

начнём с того что делать пароль от почты общим с ещё каким-то сервисом — фейл.
делать вообще пароль от публичного по-определению сервиса (того же jabber) общим — фейл

one service — one password.

SSO — это фейл, если это не SSO на аппаратных ключах. и то наверняка если подумать больше пары секунд можно найти и в этом сценарии массу недочётов.

[Bansher]

Джаббер привязан к почтовому LDAP для возможности создания актуального общего ростера. В противном случае у него не было бы преимуществ перед Google-talk или чатом facebook или той же аськой.

[Bansher]

Да, изначальная задача логирование попыток неудачного ввода пароля.
В настоящий момент сервис в стадии тестирования. Пользуется около 50 сотрудников.

[shanker]

А почему не желаете использовать port knocking для решения вопроса подключения к порту с заранее неизвестного IP адреса? Можно каждому сотруднику выдать утилиту со скриптом, который будет делать нужную последовательность пакетов для внесения разрешения на подключение с адреса «стучащегося».
А чтоб iptables не захламлялся старыми адресами — можно его периодически чистить по крону. Я вообще чищу каждые сутки в 4 ночи

[Slipeer]

От таких постов мне, порой страшно становится…
Сервисы делаются для пользователей, а не наоборот!
Заставлять пользователя принять позу лотоса, три раза прокукарекать, открыть талмут с паролями, найти и ввести пароль к jabber только для того, чтобы узнать как на какой стадии у Васи подготовка макета — вы не считает, что это уже слишком?
Безопасность — это, в первую очередь, проблема администратора и нельзя её полностью перекладывать на пользователя, заставляя помнить кучу сложных паролей, или на каждом новом месте плясать с бубном для подключения к сервису компании.

[shanker]

Согласен, пользователю доставит определённые неудобства. Но у любого способа свои минусы. Вот у Вас получается что:

Чем больше пользователей — тем больше лог, который нужно анализировать на поиск попытки взлома. И анализ этот нужно проводить перманентно, с некоторым периодом повторения.

Сервис всем доступен снаружи, его могут похакать, заDoSить, через него могут прорваться в локалку компании. В общем, можно много чего нафантазировать. Тут нужно уже смотреть реальную конфигурацию Вашей сети, чтоб понять насколько это вероятные события.

Использование port knoсking хоть и доставит проблем конечным пользователям (в виде периодического запуска bat-файла и необходимости таскать с собой дополнительный исполняемый файл knock.exe или для линукс пользователей установки пакета), но снимает минусы по безопасности, описанные выше.

Так что тут уж каждый сам себе решает что наиболее важно в ситуации.

[Slipeer]

Вывод тут один: не выпускать такой сервис пользовательскими портами наружу ;)
Для общения с внешним миром использовать связи сервер-сервер.
А пользователи за периметром… пусть VPN поднимают, что ли…