Как защитить Сервер Mac (“Возможная попытка взлома” в журналах)
'5' означает, что ясный пароль был преобразован в тип пароля Cisco 5. Пароль типа 5 является базирующимся алгоритмом MD5 (но я не могу сказать Вам, как вычислить его, извините). Тип 7, который используется, когда Вы делаете, "включает пароль", хорошо знают обратимый алгоритм. "сервисное шифрование пароля" просто гарантирует, что пароль не будет сохранен в ясном (тип 0)
Смотрите на http://en.wikipedia.org/wiki/Crypt_ (Unix) #MD5-based_scheme и удача :)
Править: Можно также посмотреть http://www.h4x3d.com/md5-and-crypt-password-generator/, http://www.koders.com/c/fid530E8983791E1CB2AB90EAA69A68789FA2A83A6D.aspx и http://www.cryptgenerator.de/
Хорошая альтернатива перемещению Вашего порта SSH должна использовать что-то как Blockhosts. Это - сценарий Python, который сканирует Ваши файлы журнала (обычно /var/log/auth.log) для этих видов вещей и помещает динамические записи в/etc/hosts.allow для блокирования людей, делающих сканирование грубой силы. Я использую его успешно на моем SSH и установках vsftpd для помещения в черный список людей после 5 неправильных паролей подряд.
-
1Я hadn' t натыкался на это прежде. I' ll определенно отмечают это как утилиту, которую я должен изучить. – sclarson 5 November 2009 в 23:41
Как уже говорилось это - только автоматизированное сканирование, это пробует присоединение словаря против известного (взломщику, конечно) вид цели.
Как шумный метод сокращения можно изменить порт SSHD на сервере, можно достигнуть этой цели в очень простом способе следовать инструкциям, которые я дал другому вопросу на SF.
Примечание: Этот подход не имеет никакого отношения к реальной безопасности (поскольку все знают, что безопасность через мрак не является безопасностью вообще), но может помочь в, держат деточек сценария отдельно, и Ваш системный журнал поблагодарит Вас :)
Править:
Альтернативная реализация подхода помещения в черный список может быть достигнута с помощью оперативных общедоступных Черных списков Грубой силы SSH, таких как sshbl.org.
Альтернатива для локального подхода BL является вместо этого хорошим BFD (Обнаружение Грубой силы)
Ограничение Вашего метода аутентификации для открытого ключа является большим запуском. Используя сканер журнала Denyhosts или Blockhosts (поскольку Graeme сказал) помогут защитить от повторных попыток от того же адреса. Denyhosts имеет дополнительную общую базу данных, которая позволяет Вам адреса блока, которые видели другие люди.
Наряду с ограничением метода аутентификации, лучшее решение, которое я нашел, состоит в том, чтобы переместить SSH в другой порт. Сканирования, кажется, фокусируются на порте 22. После отодвигания от того порта попытки на каждом из моих серверов спал до ноля.
-
1
Если у Вас есть ssh, включенный, который заставит Вашу машину быть похожей на интересную цель, поскольку это наиболее вероятно сервер и поэтому стоит взломать с точки зрения хакера.
Можно сделать безопасность с помощью мрака и переместить ssh порт. Можно сделать это на машине с этой подсказкой http://www.macosxhints.com/article.php?story=20050707140439980, который действительно работает над 10,5 также. Я не сделал этого на 10,6, но я не знаю ни о какой причине, почему это не работало бы там также.
Вы могли также сделать это на брандмауэре для перевода внешнего запроса на другой порт для передачи 22 на этой машине. Это - просто другой метод безопасности с помощью мрака.
Можно отключить ssh с внешней стороны и использовать VPN только для входа. С точки зрения безопасности это - самый сильный выбор.
В любом случае убедитесь, что у Вас есть сильный пароль. Если у Вас будет сильный пароль, то они не войдут, но оставленный на порте по умолчанию существует потенциал для мини-атаки "отказ в обслуживании" подавляющим машина с запросами аутентификации или по крайней мере определенная потеря производительности.
Вы заметите, что они в значительной степени просто пробуют все виды логинов в алфавитном порядке. Другой уровень безопасности состоит в том, чтобы иметь нестандартное имя для входа в систему. Можно держать пари, что они собираются судить администратора и корень, например.
Мне также нравится отключать более старый, менее безопасный ssh1 протокол: http://www.macosxhints.com/article.php?story=2005021023215253
-
1В ответ на искры отвечают выше: безопасность с помощью мрака совершенно допустима в дополнение к хорошим методам. Перемещение порта полностью положило конец этой проблеме о моей домашней машине. Ограничение брандмауэра к определенному дюйм/с не может быть выполнимым для OP, если он требует способности установить чрезвычайную удаленную связь откуда-либо (как их телефон) или не имеет бюджета или наклона настроить VPN. – ridogi 5 November 2009 в 21:45
-
2обратите внимание, что, изменяя ssh порт в пути, данном статьей, Вы цитируете, очень очень хитрый путь. См. мой ответ для объяснения. – drAlberT 5 November 2009 в 21:55
-
3Это быстро - только необходимо отредактировать 2 файла. Я haven' t сталкиваются с единственной проблемой от выполнения этого. – ridogi 5 November 2009 в 22:07
-
4/etc/services система и стандартный файл. Это показывает " стандартные порты, связанные со стандартом services" так изменение порта данного сервиса могло повредить приложение, которое будет полагаться на эпохальный файл, добавляющий название службы поддержки к одному файлу, упоминая, что те, которые стандартным, ужасны также. Почему не изменяют один, правильный , файл вместо этого?;) – drAlberT 5 November 2009 в 22:24
-
5I' ll дают Вашему решению выстрел как I' m заинтересовал изучать это. Решение в ссылке я отправил doesn' t изменяют ssh порт в том файле, он просто перечисляет новый пользовательский порт, к которому затем направлен sshd через тот же файл, который Вы изменяете. С каким сценарием Ваше решение имеет дело лучше, чем то из ссылки, которую я отправил? Обновление ОС, которое изменяет/etc/services? – ridogi 5 November 2009 в 23:28
У Вас есть порт 22 выставленных к миру. Можно или использовать функции брандмауэра OSX, встроенные для сужения дюйм/с, который может получить доступ машине, или можно поместить своего рода межсетевое устройство / сервер перед сетью и потребовать, чтобы люди соединились с тем (обычно через VPN) прежде, чем соединиться с сервером (серверами).
Я лично не потрудился бы изменять порт SSH. Безопасность с помощью мрака является мифом. Сканеры портов могут легко узнать, какой сервис работает на нестандартном порте и делает среды нестандартными, может вызвать проблемы с поставщиками или более раздражающе добавить еще больше вещей удостовериться, что все недавно нанятые люди знают, чтобы сделать. Это просто добавляет, что больше вещей зарегистрировать и удостовериться стандартизировано.
-
1Не говоря уже о, большинство сетей компании I' ve замеченный блок большинство исходящих портов для пользователей за исключением нескольких общих как 22, 80 и 443. При переключении на другой порт (если Вы не выбрали 80 или 443 ;) мог бы лишить возможности соединяться из многих ограниченных сетей в мире... – Oskar Duveborn 6 November 2009 в 14:58
Не волнуйтесь об этом. Это - автоматизированное сканирование, Вы просто выиграли бросок монеты на этот раз.