Thursday, 17 May 2012
Как говорится век живи – век учиcь. Оказалось, что CentOS’вский ssh не в курсе того, что на нормальных операционках ограничение подключений по IP осуществляется путем директивы AllowHosts в конфиге sshd_config. И посему эти ограничения следует прописывать в двух файлах:
/etc/hosts.allow
/etc/hosts.deny
Причем смысл в том, что прописываются в них ограничения для всех пакетов относящихся к INET сервисам. В принципе это конечно довольно удобно, то что не надо лазить по разным конфигам, а настраивается в одном файле, но имхо- все же в конфиге софта было бы понятнее.
(more…)
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Рубрика: IT безопасность, Linux | Ваш отзыв »
Wednesday, 24 Aug 2011
Столкнулся тут с довольно забавным глюком связки ssh + named, в процессе прикручивания сервера доменных имен на работающем фаерволе. Брандмауэр был настроен уже какое то время назад, практически по мануалу который я напостил недавно, и вот на днях возникла необходимость сделать его еще и сервером доменных имен.
Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.
И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;
после чего решил добавить страку разрешающую обращение к фаерволу из внутренней сетки по 53 порту, и перегрузил сервак. После чего ssh у сервера интеллигентно отпал. Точнее сервер крутился и при обращении к нему выдавал запрос имени пользователя, но после его ввода, вместо ожидаемого в ответ запроса пароля, просто отключал пользователя. Поскольку сервер был удаленный, я звякнул тамошнему админу, и попытался его руками все вернуть обратно, но замена новых правил фаервола на новые- ничего не дала. Так что пришлось пилить в контору.
Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.
Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.
Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Рубрика: Сети | Ваш отзыв »
Friday, 25 Dec 2009
Как я уже писал ниже, в ноябре этого года, многочисленные пользователи iPhone в Европе, совершившие процедуру джейлбрейка своего телефона, подверглись атаке вируса iKee.B (duh) Apple iPhone, делавшего коммуникатор участником литовского ботнета. Использованная этим бот вирусом уязвимость, был стандартный пароль ‘alpine’ для пользователя root, и удаленный доступ к iPhone который злоумышленник получал через дополнительно установленный на iPhone ssh сервер.
(more…)
VN:F [1.9.13_1145]
Rating: 6.0/10 (1 vote cast)
VN:F [1.9.13_1145]
Рубрика: iPhone | 1 отзыв »