Fyodorov.Alexey Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 Всем привет. В общем, у меня в логах нынче периодически появляются записи такого вида - Jul 15 05:33:49 Heffalump sshd[8796]: Invalid user stephen from 64.60.196.155 Jul 15 05:33:51 Heffalump sshd[8801]: Invalid user richard from 64.60.196.155 Jul 15 05:33:53 Heffalump sshd[8806]: Invalid user george from 64.60.196.155 Jul 15 05:33:55 Heffalump sshd[8811]: Invalid user john from 64.60.196.155 Jul 15 05:33:59 Heffalump sshd[8821]: Invalid user angel from 64.60.196.155 Jul 15 05:34:01 Heffalump sshd[8826]: Invalid user games from 64.60.196.155 Jul 15 05:34:03 Heffalump sshd[8831]: Invalid user pgsql from 64.60.196.155 Jul 15 05:34:08 Heffalump sshd[8846]: Invalid user ident from 64.60.196.155 Jul 15 05:34:10 Heffalump sshd[8851]: Invalid user webpop from 64.60.196.155 Jul 15 05:34:12 Heffalump sshd[8856]: Invalid user susan from 64.60.196.155 Jul 15 05:34:14 Heffalump sshd[8861]: Invalid user sunny from 64.60.196.155 Jul 15 05:34:16 Heffalump sshd[8866]: Invalid user steven from 64.60.196.155 Jul 15 05:34:18 Heffalump sshd[8871]: Invalid user ssh from 64.60.196.155 Jul 15 05:34:20 Heffalump sshd[8876]: Invalid user search from 64.60.196.155 Jul 15 05:34:22 Heffalump sshd[8881]: Invalid user sara from 64.60.196.155 Jul 15 05:34:24 Heffalump sshd[8886]: Invalid user robert from 64.60.196.155 Jul 15 05:34:26 Heffalump sshd[8891]: Invalid user richard from 64.60.196.155 Jul 15 05:34:28 Heffalump sshd[8896]: Invalid user party from 64.60.196.155 Jul 15 05:34:30 Heffalump sshd[8901]: Invalid user amanda from 64.60.196.155 Jul 15 05:34:31 Heffalump sshd[8906]: Invalid user rpm from 64.60.196.155 Jul 15 05:34:35 Heffalump sshd[8916]: Invalid user sgi from 64.60.196.155 Jul 15 05:34:39 Heffalump sshd[8926]: Invalid user users from 64.60.196.155 Jul 15 05:34:41 Heffalump sshd[8931]: Invalid user admins from 64.60.196.155 Jul 15 05:34:43 Heffalump sshd[8936]: Invalid user admins from 64.60.196.155 Jul 15 05:35:00 Heffalump sshd[8981]: Invalid user dean from 64.60.196.155 ну и т.п. адреса "интересующихся" моей машинкой варьируются каждый день. Действо происходит обычно ночью, с одного IP адреса в среднем по нескольку десятков таких попыток захода. После этого успокаиваются. Не думаю что такие кулхацкеры станут серьезной проблемой, но хотелось бы подстраховаться, что-ли. может ограничить тремя попытками подключения с одного адреса в течении например, часа. или оставить только возможность авторизации по открытому ключу?.. Единственно что только не хотелось бы ограничивать возможность захода на компьютер только с фиксированных адресов. Или, на самом деле в этом и проблемы никакой нет? Что посоветуете, опытные товарищи? Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Ineu Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 Мне в какой-то момент надоело то, что такой ерундой забиваются логи, поэтому я просто убрал ссш с белых адресов, оставив только доступ из локалки. Необходимости попадать в систему снаружи с тех пор ни разу не возникало. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
vpk_vpk Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 Можно поставить knock-server. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 Действительно, чем морочиться, наверно проще всего оставить возможность подключения к ссш только известным хостам.. Вопчем пока оставил возможность захода только через паблик кей, два неавторизованных подключения одновременно, логлевел уровня дебаг, и ListanAddress два айпи с которых хожу через запятую (кстати черт его знает, как оно правильно - через запятую или черзе пробел. в мане не написано. опять вот какой-то оболтус развлекается - Jul 16 16:37:17 Heffalump sshd[11776]: Invalid user guest from 219.84.161.123 Jul 16 16:37:17 Heffalump sshd[11776]: reverse mapping checking getaddrinfo for 219-84-161-123.sonet.coowo.com failed - POSSIBLE BREAKIN ATTEMPT! Jul 16 16:37:18 Heffalump sshd[11780]: reverse mapping checking getaddrinfo for 219-84-161-123.sonet.coowo.com failed - POSSIBLE BREAKIN ATTEMPT! Jul 16 16:37:26 Heffalump sshd[11786]: Invalid user paul from 219.84.161.123 Jul 16 16:37:26 Heffalump sshd[11786]: reverse mapping checking getaddrinfo for 219-84-161-123.sonet.coowo.com failed - POSSIBLE BREAKIN ATTEMPT! надоели мне эти черти Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 кстати вот как один умный человек предлагает решать данную проблему - Цитата Цитата: ^rage^ пишет: имхо POM для iptables успешно решает такую проблему. TARPIT+TIME(вроде второе так называется). Т.е. когда лимит числа пакетов на опр. порт превышается - в ход идут ловушки В iptables это решается одной строчкой -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN SYN -m limit --limit 1/sec --limit-burst 2 -j REJECT --reject-with icmp-port-unreachable --limit 1/sec порог срабатывания (количество пакетов в единицу времени), при достижении которого применяется -j --limit-burst 2 - этот параметр описать несколько сложнее и во всех документах по iptables он описан очень мутно. лучше всего его описать с помощью широко распространенной модели "дырявого ведра" (leaky bucket). Так вот в этой модели второй параметр задает объем ведра. По сути этот параметр определяет гистерезис срабатывания фильтра. Для выбора реальных значений следует посмотреть логи. например в моей системе приведенные в примере значения параметров отрубают весь паразитный трафик на порт ssh начисто. взято здесь Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Hans R. Steiner Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 А можно замутить что-нибудь такое: локалка 10.137.0.0/16 внешняя сеть 199.88.31.0/24 наша машина: 127.0.0.1/8 10.137.0.1/24 199.88.31.1/24 машина, которой у нас нет: 199.88.31.92 iptables -P INPUT DROP iptables -A INPUT -d 127.0.0.1 --dport ssh -j ACCEPT iptables -t nat -A PREROUTING -d 199.88.31.92 --dport ssh -j DNAT --to-destination 127.0.0.1 Бред... не знаю, будет ли работать, но интересно Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Hans R. Steiner Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 есть еще приколы с перенаправлением ирафика на его же источник, но их я уже не помню... давно не баловался Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 Hans R. Steiner писал(а) Mon, 16 July 2007 17:55 есть еще приколы с перенаправлением ирафика на его же источник, но их я уже не помню... давно не баловался а если адрес источника пакета подставной?.. зафлудишь ни в чем неповинный хост. вот тут про TARPIT . Попробовать, что ли. Перевесить ssh на левый порт, а остальные порты слить в TARPIT. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 а вы разрешите аутентификацию только по открытому ключу. для верности. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 ну дык я так и сделал. но то ли я очепятался в адресе ListenAddress, либо еще где-то в конфиге sshd накосячил, но в общем не могу пока к удаленной машине после ребута подключиться. sshd не поднялся. доберусь до дома, погляжу что там приключилось. честно говоря, сам не знаю за каким чертом я ее решил перезагружать, надо было запустить еще один sshd с другим конфигом, для тестирования, вдруг не поднимется.. но теперь уже поздняк. вот до чего годы работы в виндовс доводят. если вы советуете оставить только открытый ключ, тогда к вам вопрос - если оставить аутентификацию только по открытому ключу (другими словами, если запретить аутентификацию по кейборд-интерактивному методу) - что будет происходить в случае таких левых попыток подключения? все такие попытки брутфорса будут отклоняться изначально, и в записи системных логов не попадут?.. или будут те же самые записи в messages о неудачном соединении. пароли пользователей на этой машине 17-символьные, алфавитно-цифровые с символами пунктуации, поэтому перебора паролей можно особо не бояться... но хочется пресечь этот левый траффик, чтобы и логи были чисты, и ненужный трафик не нагонялся, и чтобы избежать теоретически-гипотетического взлома системы через какойнить эксплойт sshd. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 Цитата: все такие попытки брутфорса будут отклоняться изначально да. вернее - сервер даже спрашивать ничего не будет ни на счёт хоста, ни пароля юзера. ему бумашку покажи и секретную фразу назови. надо только правильно настроить демон. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 AccessD писал(а) Mon, 16 July 2007 19:33 Цитата: все такие попытки брутфорса будут отклоняться изначально да. вернее - сервер даже спрашивать ничего не будет ни на счёт хоста, ни пароля юзера. ему бумашку покажи и секретную фразу назови. надо только правильно настроить демон. начинаю впадать в паранойю но вот интересная штука.. в sshd_config-е - RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no и тем не менее, sshd упорно продолжает предлагать логинящимся юзерам ввод с клавиатуры логина-пароля. что я делаю не так?... Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 16 июля, 2007 Автор Жалоба Поделиться Опубликовано 16 июля, 2007 разобрался.. Чтобы sshd не предлагал интерактивный ввод пароля надо было отключить PAM - UsePAM no и все, теперь только по ключу пускает и только двух поименованных юзеров AllowUsers uzer1 uzer2 наверное этого достаточно для временного избавления от паранойи и разрастания логов кстати.. насколько в реальности критичен запрет (и соответственно разрешение) логиниться по ссш руту? все кругом рекомендуют однозначно руту не давать возможности заходить по ссш. но не нашел объяснения почему так. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 16 июля, 2007 Жалоба Поделиться Опубликовано 16 июля, 2007 для снижения возможности компрометации системы. лучше зайти под обычным юзером, а потом,если надо, сделать su Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Ineu Опубликовано 17 июля, 2007 Жалоба Поделиться Опубликовано 17 июля, 2007 Честно говоря, никогда этого не понимал. ССШ - не телнет, зашифрованным передается все, поэтому фактически разницы между логином в рута и su в него никакой. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Aceler Опубликовано 17 июля, 2007 Жалоба Поделиться Опубликовано 17 июля, 2007 Разница на самом деле очень простая. Вот вы знаете _логин_ рута? Знаете. У рута логин root. А вы знаете логины пользователей? Чаще всего нет. И попробуйте теперь подобрать пароль,если вы даже логина не знаете. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 17 июля, 2007 Автор Жалоба Поделиться Опубликовано 17 июля, 2007 Aceler писал(а) Tue, 17 July 2007 10:35 Разница на самом деле очень простая. Вот вы знаете _логин_ рута? Знаете. У рута логин root. А вы знаете логины пользователей? Чаще всего нет. И попробуйте теперь подобрать пароль,если вы даже логина не знаете. ну так а если и пароля никакого нет? если авторизация исключительно по открытому ключу? получается что в этом случае без разницы. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 17 июля, 2007 Жалоба Поделиться Опубликовано 17 июля, 2007 (не то написал..) Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
SignFinder Опубликовано 18 июля, 2007 Жалоба Поделиться Опубликовано 18 июля, 2007 для решения проблемы в первом сообщении достаточно перевести sshd на другой порт. Это в любом случае неплохо бы сделать. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 18 июля, 2007 Жалоба Поделиться Опубликовано 18 июля, 2007 так ведь это nmap'ом разоблачится моментально. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Fyodorov.Alexey Опубликовано 19 июля, 2007 Автор Жалоба Поделиться Опубликовано 19 июля, 2007 Перевесил sshd с 22го на 55й порт. Почему на 55й? Просто так, "от балды". И авторизацию сделал только по открытому ключу без ввода пароля, и только для двух прописанных в конфиге пользователей. И всё, на этом всё безобразие закончилось. Логи чистые, никто не ломится. Думается что смысл в перевешивании ссшд на другой порт таки есть, потому как наверняка процесс поиска открытых по дефолту 22х портов у определенной категории граждан автоматизирован. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
AccessD Опубликовано 19 июля, 2007 Жалоба Поделиться Опубликовано 19 июля, 2007 вообще, IMHO, если перевешивать, то на порты выше 1024. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
SignFinder Опубликовано 20 июля, 2007 Жалоба Поделиться Опубликовано 20 июля, 2007 Цитата: так ведь это nmap'ом разоблачится моментально. это при условии, если ктото валит конвретно ваш сервер. А боты просто берут сетку сканят 22 порт и если он слушает, начинают долбить его. Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Byte Опубликовано 23 июля, 2007 Жалоба Поделиться Опубликовано 23 июля, 2007 ага.. или кто-то регулярно XSpider'ом балуется... Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Hans R. Steiner Опубликовано 24 июля, 2007 Жалоба Поделиться Опубликовано 24 июля, 2007 Тогда, думаю что актуально перевесить ссх на несуществующий IP-адрес и на нестандартный порт... гравное, чтобы роут к этому адресу, был через этот сервак Цитата Ссылка на комментарий Поделиться на другие сайты Поделиться
Рекомендуемые сообщения
Присоединяйтесь к обсуждению
Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.