Как защитить SSH от взлома
SSH – безопасный протокол для передачи данных (команд, файлов, видеосигнала и т.д.) между компьютерами.
По умолчанию он включен на VPS и выделенных серверах большинства хостинг-провайдеров, так как с его помощью возможно легко и безопасно управлять удаленной машиной. К слову, на сервисе Велл-Веб можно недорого арендовать сервер VPS. Так как SSH поднят на всех VPS, Чтобы при использовании Secure Shell не возникло проблем, необходима правильная защита SSH.
Отключаем доступ от рута
В первую очередь рекомендуется деактивировать возможность удаленного подключения к машине под учетной записью суперпользователя (root). Для этого нужно найти файл sshd_config, который обычно (но не всегда) находится в каталоге /etc/ssh/, и открыть его.
В нем потребуется отыскать пункт PermitRootLogin и заменить его значение на «no», то есть должна получиться такая запись:
PermitRootLogin noЕстественно, это не предотвратит взлом, но все же несколько его затруднит.
Чтобы свести к минимуму возможность взлома, рекомендуется вместо авторизации по логину и паролю использовать авторизацию при помощи ключей. Это можно сделать несколькими способами. Подобное, к слову, еще и неплохая SSH защита от брутфорса.
Смена порта по умолчанию
Так как взлом сервера по SSH обычно происходит через перебор паролей (брутфорс), то рационально будет изменить стандартный 22-й порт на какой-нибудь другой. Сделать это очень легко. В первую очередь нужно открыть уже упомянутый файл sshd_config, и добавить там одну строчку:
Port номер_портаЗапись будет выглядеть, например, следующим образом:
Изучи PHP не выходя из дома
Онлайн уроки с проверкой домашних заданий!
Начать бесплатноPort 3048Это позволит значительно уменьшить количество желающих несанкционированно проникнуть на сервер. Перед изменением номера порта обязательно следует убедиться, что это не навредит работе других приложений. Также нужно выбрать тот порт, который еще не используется, чтобы программы не конфликтовали из-за него.
Ограничение доступа по IP
Еще один способ защиты, который практически до нуля снизит вероятность несанкционированного подключения – это установка ограничений на авторизацию. SSH можно настроить таким способом, чтобы авторизоваться на сервере можно было только с удаленных машин с определенными IP-адресами. Для этого в файле sshd_config в строке AllowUser к имени каждого пользователя нужно дописать @номер_IP. Запись может иметь, например, такой вид:
AllowUsers [email protected], [email protected]Перед тем, как использовать этот способ, рекомендуется убедиться, что не возникнет ситуаций, при которых может потребоваться зайти на сервер с машины, IP-адрес которой не предусмотрен конфигурацией.
Безопасный пароль
Ну и конечно же стоит использовать стойкий к перебору пароль. Длинный и с как можно более разнообразными символами, желательно с кракозябрами. Это must have.
Заключение
Все эти способы позволят защитить доступ к вашему серверу по SSH. Также советую прочесть статью о том, как выбрать VPS сервер.
webshake.ru
Четыре шага в защите SSH
Secure Shell можно найти повсюду. С момента
выпуска в 1995 году, SSH получил широкое
распространение как мощный протокол
удаленного доступа для Linux.
Однако, как известно, большая сила —
большая ответственность. Неправильно
сконфигурированный SSH демон может быть
больше угрозой, нежели помощью. В этой
статье мы рассмотрим пять шагов по усилению
безопасности SSH.
1. Отключаем root логин.
Самый простой шаг. Очевидно, что
существует мало причин разрешения захода
root через SSH. Отключить же такой доступ
довольно просто и это позволит усилить
безопасность.
Найдем /etc/ssh/sshd_config (возможно он находиться
в другом каталоге, это зависит от
дистрибутива). В нем определим место
PermitRootLogin и заменим значение на «no»:
PermitRootLogin no
Конечно, это не помешает никому вломиться
в систему под обычным юзером, однако лишней
преградой на пути возобладания системой
все же послужит.
2. Запрещаем интерактивный логон.
Следующий очевидный шаг — сделать
авторизацию не на основе вводимых
несколько раз писали о системе ключевого
доступа в SSH, вы можете прочитать о создании
и использовании ключей в наших статьях:
Защита SSH №1
Защита SSH №2
Ключи в OpenSSH
Прочитав все выше написанное и реализовав
на практике, мы в результате получим ключи
для авторизации на сервере. Убедившись, что
все работает, можно запретить
интерактивный ввод:
PasswordAuthentication no
ChallengeResponseAuthentication no
3. Черный список DenyHosts
Используя этот Python-скрипт администратор
может автоматические вносить хосты при
неудачном логине в черный список, баня их
europa ~ # emerge -pv denyhosts
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] app-admin/denyhosts-2.5 0 kB
Total size of downloads: 0 kB
europa ~ # emerge denyhosts
Документации по программе не очень много (если
чего — есть, например FAQ),
однако все опции конфигурирования
нормально описаны в конфигурационном файле.
europa $ nano -w /etc/denyhosts.conf
Не думаю, что конфигурирование DenyHosts
вызовет особые проблемы — достаточно
внимательно прочитать конфиг.
После конфигурирования можно запустить
демоном:
rc-update add denyhosts default
Через cron, скажем каждые 10 минут:
python /usr/bin/denyhosts -c /etc/denyhosts.conf
Вся радость DenyHost не только в блокировании
хостов, пытающихся пробиться к вашему SSH
серверу, но и в том, что можно
синхронизировать свой «черный список»
с серверами DenyHost. Таким образом создается
коллективный список хостов, содержащий
всех нападающих. Он предотвратит нападение
в самом корне.
4. Изменяем номер порта.
Большинство попыток взлома идет от
автоматических скриптов, сканирующих сеть
количестве случаев они пытаются вломиться
на 22 порт, что только играет нам на руку.
Изменив порт мы автоматически отсечем
большинство попыток несанкционированного
доступа.
В конфиге стоит поменять:
Port 22
Вместо или вместе с изменением порта
можно использовать «стук в порты» (port
knocking). Это еще больше защитит наш SSH сервер. Подробнее
о технологии можешь прочитать в
Декабрьском Хакере: http://www.xakep.ru//magazine/xa/084/032/1.asp.
xakep.ru
Как защитить сервер SSH от перебора паролей (брутфорс)
Даже сильно защищенный, шифрованный протокол SSH можно взломать. Есть множество методов это сделать и еще больше способов защитить сервер от взлома. В данной статье вы узнаете, что такое SSH brute, для чего вам нужен SSH checker и как можно обезопасить свой сервер от подборщиков. Взломать могут все, что угодно: от роутера до вашего домашнего компьютера, на котором запущен виртуальный сервер по SSH протоколу. А все потому, что не все знают, что такое брут.
Зачем хакерам нужен SSH brute и что это
Брут — это наиболее привычный способ взлома аккаунта клиента для захода на сервер. Такой взлом — это всего-навсего перебор паролей, то есть атака на сервер подборщиков, или брутфорс. Такой простой и самый очевидный метод мало кем учитывается во время создания сервера SSH. Многие думают, что на их хост никто не собирается нападать и что они в безопасности. Но приходит время, и сервер начинает глючить, а на компьютере появляются вирусы — похоже, что это взлом!
Хакеры используют брут для того, чтобы завладеть вашим устройством, будь то роутер или компьютер. На ПК они могут либо сбросить вирусы с кучей рекламы, либо проникнуть в вашу файловую систему и украсть какую-либо важную информацию. Взлом роутера по протоколу SSH — это и вовсе выгодное занятие для подброщиков. Используя стандартный перебор паролей (или брутфорс), взломщики получают доступ к роутеру и могут делать через него спамную рассылку на подключенные компьютеры. Либо они могут продавать данные для входа вашим соседям и т. д. Вот зачем им нужен взлом, вот почему брут до сих популярен — люди не умеют защищать свой SSH сервер, так что даже перебор паролей несет для них большую опасность.
Как можно защитить свой сервер
Во-первых, вы можете использовать чекер. Программ для этого хватает: Lazy SSH, SSH checker, SSH Fresh checker и т. д. Чекер работает так: создает еще одного юзера-клиента, и входит на сервер с целью проверить существующих пользователей на валидность. Если пользователь уже не активен и аккаунт давно не проявлял каких-либо действий, вы об этом узнаете и сможете удалить его, чтобы хитрые взломщики через перебор паролей не смогли взломать старый клиент. К примеру, программа Lazy SSH проверяет IP-адреса, используемые юзерами, а также пользователей, зарегистрированных по открытому ключу и паролю. А SSH Fresh checker анализирует прокси, страну, город, почтовый индекс по IP-адресу, помогая тем самым вам вычислить перебор паролей — вы сразу заметите подозрительных пользователей из других континентов.
Чекер лишь поможет вам проанализировать сервер SSH на факт взлома. То есть если брут уже состоялся, то чекер поможет определить взлом, пробоину в сервере, которую оставил брутфорс и вы быстро на это среагируете, удалив подставных пользователей. Но учитывайте, что чекер не сможет предотвратить брут — взлом не остановить, если вы будете просто сканировать аккаунты. Чтобы запретить брутфорс, вам нужно покопаться в настройках SSH протокола для сервера, а не только использовать чекер.
В первую очередь вам стоит избавиться от root-пользователя, запретив для него вход. Если вы этого не сделаете, то хакеры не просто взломают вам хост, но и смогут ввести фатальные изменения на компьютер и другое оборудование.
Таким образом, вы лишь развяжите им руки, если оставите возможность входа для root-пользователя. Так что откажитесь от этой глупой идеи и поставьте индивидуальные уровни доступа для каждого каталога и файла при помощи команды chmod.
С другой стороны, поскольку вы узнали, что существует брут и подбор паролей, то лучше вообще отказаться от пассвордной авторизации. Это устаревший способ, который вовсе не защитит вас, а наоборот — оставит ходы и лазейки для хитрых подборщиков. И если вы хоть на каплю переживаете за свой сервер или роутер, то откажитесь от парольной аутентификации в пользу сверки пользователей по открытому ключу. Хоть такая защита и кажется более слабой, так как при входе на SSH сервер не нужно ничего вводить, но это не так — открытые ключи надежнее паролей.
Если вы привыкли к классическому способу аутентификации, к паролям, тогда вы все же можете их оставить, но при условии, что измените требования к авторизации пользователей. В файле конфигураций на сервере вы сможете указать ограничения для авторизаций, а именно: прописать максимальное число попыток для каждого пользователя ввести верный пароль, указать максимальное число одновременных сеансов авторизации, а также длительность ввода пароля. Учтите, что такой метод может понизить комфорт пользователей во время авторизации — им будет неудобно ожидать, пока определенное число сеансов авторизации пройдет и появится свободное место для них. Кроме того, не все вводят свой пароль с первого раза, потому пользователи будут нервничать и т. д.
Также очень важно указать другой номер порта. Ведь все брутфорс-атаки направлены на одно и то же — серверы со стандартным значение порта, равным 22. Если вы поменяете его, то вероятность взлома уже в несколько раз понизится. Потому зайдите в файл конфигураций и измените Port 22 на любой другой, хоть на 23-й. Этого достаточно, чтобы обезопасить свой сервер!
Похожие статьи
e-webmaster.ru
Взлом ssh и заработок на них. 2 часть – Telegraph
blackawsПривет друзья. Сегодня мы будем учиться пользоваться брутом.
А точнее взламывать первые наши тунельки.
Перед тем, как приступать к 2 части, вам нужно ознакомиться с первой.
1 часть https://t.me/blackaws/95
Надеюсь вы насканили минимум 1000 ip.
Нажимаем на кнопку, как скрине ниже.
Открывается файл с вашими IP, которые вы насканили.
Дальше открываем папку в которую мы в предыдущей статье все разархивировали.
Выбираем архив под вашу систему. х32 или х64
Делаем разархивацию. Отлично, а теперь открываем папку и ищем вот такой файл.
Запустили программу и видим вот такое окно.
Нажимаем Нет.
Начинаем настройку программы.
- Список IP из файла. Нажимаем на эту кнопку и заходим в папку, где у вас сканер находиться Massscan_GUI, а после чего ищем там файл IPs.txt. Выбираем его. В «Список IP:» должны появиться кол-во ваших ip.
- Добывать логины. Нажимаем на эту кнопку и заходим в папку, где у вас находиться этот софт. Ищем там файл лог.пасс.txt. Выбираем файл этот.
- Добывать пароли. Нажимаем на эту кнопку и заходим в папку, где у вас находиться этот софт. Ищем там файл лог.пасс.txt. Выбираем файл этот.
Если все правильно, то у вас везде должны везде быть цифры
Список IP, Логины, Пароли. Не должно быть там 0, как в начале.
У меня на скрине видно, что «Список IP: 234″. Это очень мало IP, минимум нужно 1000 IP, а лучше больше. Где их взять?
В первой части помните мы сканировали? Вот эти ip со скана.
После чего нужно настроить Потоки. Тут очень индивидуально, у всех разные пк. Я минимум поставлю 30, а вы сами поиграйтесь настройками поймете.
Жмем Доп.настройки и делаем вот такие настройки. Проверяйте все галочки.
Жмем Ок.
Отлично, а теперь жмем Запустить.
И видим вот такую картинку, все начало работать.
Теперь ждем пару часов и радуемся результатам.
В следующей части. Мы разберемся, как к ним подключаться, где продавать.
Всем спасибо за внимание. Все удачи друзья и побольше гудов.
telegra.ph
Проблема c настройками SSH после взлома сервера. Как можно изменить поведение сервера и клиента без изменения ssh_config и sshd_config ?
Наш убунту-сервер взломали буквально на следующий день после скандала с уязвимостью Shellshock. Не знаю применили конкретно её или нашли какую-то другую дыру, но к нам c одного румынского IP-адреса проник злоумышленник. Раньше я в душе посмеивался над ихними ботами из ZmEu, которые пытались запустить несуществующий у меня phpMyAdmin, а тут вдруг на мой сервер пошли жалобы на предмет аналогичного брутфорса.
Когда я подключился, хакер еще висел в системе (или недавно перезашел) под пользователем root. Я его кильнул и начал наводить порядки. Незваный гость особо себя не ограничивал — установил и запустил программное обеспечение для узла ботнета (сканеры и IRC-сервер), раскидал свои ключи SSH под пользователями, переписал мне таблицу iptables и постирал логи предыдущих действий. Таким образом я точно не знаю, что он успел наделать кроме самих последних команд перед его килом из системы…
Текущая проблема.
Чужой код и левые SSH-ключики почистил, правила фаервола востановил, почти всех пользователей заблокировал, а оставшимся сменил пароли. Но при последующем использовании сервера обнаружил ряд нестыковок.
Для начала, при попытке по SSH зайти моего сервера на комп из видимой ему локалки, я получил предупреждение о неизвестном хосте. Проверил в ~/.ssh/known_hosts — его запись там была (я больше никуда собственно и не хожу с данного сервера) с указанием шифрования ecdsa-sha2-nistp256. Я подтвердил вход на сервер и получил в файле известных хостов вторую запись с типом шифрования ssh-rsa. Более того, теперь при заходах на локальный компьютер я все время получаю сообщение:
/etc/ssh/ssh_config line 53: Unsupported option «GSSAPIDelegateCredentials»
Т.е. поведение локального ssh-клиента изменилось: и теперь он вместо привычного SHA-2 стал почему-то использовать SHA-1.
Еще. Я в терминале работаю в основном под MC. Вместо привычной псевдографики я теперь вижу рисование крякозябами. Помогла только смена кодировки в putty с UTF-8 на KOI8-R (если делать подключение на вышеупомянутый комп из локалки, то там все в порядке и мне приходится делать обратную смену с KOI8-R на UTF-8 чтобы снова видеть нормальный MC).
Как злоумышленник провернул все эти фокусы? Как я уже упомянул ранее, файлы ssh_config и sshd_config из директории /etc/ssh не изменились. Но даже, если предположить, что с помощью touch даты вернули назад на 2012 год, то в sshd_config все равно явно указано использование протокола 2. И прочие настройки визуально никак не изменены. Поиск по файловой системе показал, что это единственные экземпляры конфигов и других (пользовательских) нет.
Второстепенная проблема но тоже связана с SSH.
Когда пошли тревожные звоночки, я был в гостях. Там же с чужого компа я несколько раз подключался по putty не по ключу, а с явным указанием логина и пароля. Потом при анализе последних измененных в файловой системе я наткнулся на очень неприятный файлик /etc/ppp/.ilog , в котором в текстовом виде был прописан мой логин и пароль в количестве раз, сколько я подключался без ключа. Время модификации файла совпадало со временем моего последнего входа по SSH. Но что самое паскудное — мой последний вход был уже после проведения «лечебных» процедур и последующего ребута сервера. Поэтому возможно что вторая проблема и первая имеют общую причину.
Поскольку я уже упомянул про ребут и оставшиеся проблемы, то хочу сразу отметить, что я уже проверил кронтабы пользователей и содержимое директорий /etc/rcX.d и ничего нового/необычного не обнаружил.
Моя фантазия выдохлась… Прошу подсказок от «знатоков» и более опытных коллег.
toster.ru
Что делать если сервер взломан и подменили ssh сервер?
Бывает 🙂 И у меня было в жизни много раз. Подключаешься к серверу — и тут странное ошибко, мол сигнатура сервера изменилась, ну или со временем обнаруживаешь странности в работе… Что делать? Для начала нужно успокоится, и неспешно все исправить. На всеобъемлемость и объективность не претендую. Сам не раз боролся с такими проблемами, увы, всех дырок до происшествия не залатаешь. Решение проблемы следует разбить на два этапа, которые мы рассмотрим на примере ОС Linux — моей любимице. Для избежания путаницы, сразу оговорюсь что я давно использую Debian, и мой опыт больше связан именно с этой системой, хотя и во всех других дистрибутивах Linux’а отличия от Debian в основном сводятся в прикладном ПО, и в подходах к организацию слаженной работы системы. Короче говоря — хоть я работаю и под дебьяном — во всех других системах все, фактически, точно так же :_)
Этап первый — закрываем несанкционированный доступ
. Первым делом — отрезаем доступ к серверу, дабы злоумышленник не смог внедриться в систему еще глубже. Если есть возможность — отключайте его от сетей — и внутренней и внешней. Еще лучше — грузитесь с CD, тогда Вы будете уверены в работоспособности всех основных системных утилит, которые возможно были заменены на троянские аналоги.
Если возможности отключить выходы наружу нет — закрывайте выход наружу всего, кроме самого необходимого (например веб-сервера). Сделать это проще всего имея под рукой заранее приготовленный скриптик фаервола, который отрежет все, кроме критичных портов — 80, 21 или чего у Вас там. Но не стоит забывать, что многие взломы приходят не через уровень портов и протоколов, а через уровень приложений. Проще говоря — используются уязвимости или ошибки в конкретных версиях ПО — например того же WEB или FTP-сервера. А чаще всего используют ошибки и уязвимости в коде Вашего сайта — дырой могут быть определенные версии интерпретаторов PHP, Perl или просто безграмотно написанный код. К слову к таким дырка ведет и чрезмерная сложность проектов, которые часто встречаются в наши дни. Где никто просто не в состоянии отследить все возможные дырки подходящие злоумышленникам… Такие уязвимости фаерволом не закрыть. Но что-то меня понесло. Вернемся к нашему случаю подмены SSH.
После того как фаерволом Вы обрезеали доступ всем, кроме себя любимого — можно собраться с мыслями. В данный момент злоумышленник скорее всего (но далеко не факт) не имеет доступа к Вашему серверу. И Вы покойно можете почистить его от следов чужого присутствия.
Если Вы заходили на пораженную машину не с консоли а через SSH — почти наверняка Ваши пароли уже известны злоумышленнику. И вполне вероятно что в системе сидит бэкдор, троян, кейлогер или липовый интерпретатор команд (sh, bash или что у Вас там). Начнем с простого. С изучения логов. Если злоумышленник профан, или банально бот — то логи будут на месте, и Вы сможете отследить кто и как заходил в систему. Например можно выполнить команду last для обнаружения левых учетных записей. Есть что-то подозрительное в именах пользователей или других системных событиях? Подозрительные учетки созданы недавно и висят в конце файлов passwd и shadow? Одной проблемой меньше, это отличный след.
Проверьте логи этих учеток, возможно будет видно что делалось в системе. Затем удаляйте. userdel а потом проверьте все ручками.
Далее простенькой командой смотрим изменения в системе за те дни, что прошли с момента взлома системы. Ну например Вы обнаружили что хак был 10 дней назад. Выполняем find / -type f -mtime -10 — это покажет все файлы, которые были изменены за прошедшие 10 дней. Да, на живой машине или продакшн сервере лишнего будет очень много, но проверить нужно все. Особенно обратите внимание на вновь созданные файлы, и на изменения в директориях /etc и *bin/. В первой могли править системные конфиги, а во вторые могли напихать троянов и подменить демоны — в том числе и SSH. Ага — вот и видим что SSH подсунули. Заливаем новый, или точно такой же с бэкапа. Лучше новый (обновленный) — на случай уязвимости в самом SSH-сервере. Рестартуем демон — для всех этих операций лучше иметь непосредственный доступ к консоли. Логинимся в систему. Меняем пароль root и\или все пароли пользователей, особенно те, которые имеют право на sudo.
Если и на других серверах были эти же пользователи и пароли — меняем сразу.
Так же проверяем все конфигурационные файлы, которые были изменены в этот 10-ти дневный период. Удаляем все что могли засунуть нам в систему, и не забудьте проверить файлы старта системы (rc. init. и так далее в зависимости от системы). К вышеперечисленным методам обнаружения — добавьте еще netstat. Эта утилита позволит обнаружить лишние открытые порты. Тут важно с чем-нить системным не перепутать 🙂 иначе будете искать черного кота в черной комнате.
В целом дать более точны рекомендации затруднительно, так как каждый случай уникален, но мой алгоритм не раз показал себя успешно.
Этап второй — ищем и устраняем уязвимость
, с помощью которой скомпрометировали систему. Тут все не так просто. Дыра может быть в чем угодно, и что бы найти ее следы — необходима предварительная настройка безопасности системы. Благо в современные дистрибутивы уже интегрирован целый ряд security-систем. И разновидностей их довольно много, тут уж надо знакомиться с мануалами, how-to’шками или сообществом пользователей и разработчиков. И по этой же причине удобно выбирать популярное ПО. Даже несмотря на то что именно популярность стает причиной большего риска для взлома, ведь популярные дистрибутив, FTP, SSH, WEB, CMS ломать буду намного чаще чем малоизвестные. Но с другой стороны при популярности продукта Вы получаете и некую гарантию того, что уязвимости будут быстро обнародованы и устранены. Одна голова хорошо, а пару миллионов — явно лучше.
Снова к делу. В случае с нашей подменой SSH-сервера, нужно определится кто и как работал. Часто сервера ломают не хакеры, а боты. В таком случае — все очень просто. Как и настоящие злоумышленники боты используют два основных способа проникновения в систему — использование уязвимости конкретного ПО (путем реализации эксплойта), или подбором пароля к тому или иному сервису.
Рекомендации в таких случаях стандартны. В обоих случаях — необходимо ограничить доступ только тем кому он положен. То есть всегда реализовывайте философию «запрещено всем, кому не разрешено». В случае использования дырки в ПО — обновите ПО, или залатайте дырку самостоятельно. Ну а в случае подбора пароля — смените все пароли, найдите человека со слабым паролем (которого забрутфорсили) и дайте ему по рогам. Ну или найти иную утечку паролей. Пользователи часто пишут свои пароли на листиках, дискетках, блокнотах, записывают их в мобильные телефоны или хранят в почте. Такие действия нужно пресекать на корню, ведь давно известно что биоинженеринг — самый простой способ проникнуть в любую «идеально» защищенную систему.
Ну и как бы там ни было — но в случае если Вашу систему обработал не бот а хотя бы более-менее соображающий профессионал, то Вы так легко этого не заметите, и восстановить систему до изначального состояния будет просто невозможно, так как отследить все этапы вторжения порой физически нереально. Система могла быть взломана год назад, и все это время просто ждала команды злоумышленника. А вредоносный код может быть внедрен в ядро, драйвера, или прикладное ПО. Все зависит от целей, которые ставил перед собой злоумышленник и ценность информации, которой Вы обладаете.
Тут совет только один — переносить на другую систему (ну или ставить с нуля), предварительно прибив первопричину подозреваемой уязвимости (дырка в определенной версии какого-то софта, открытые порты, слабые пароли и так далее). В противном случае — Вы никогда не сможете быть больше уверены в целостной работы такой системы. Но не стоит сразу же бросаться за учебники по безопасности своих систем — умные ребята которые могут побороть стандартную ззащиту вряд ли заинтересуются конкретно Вашим сервером.
neveru.com
Взлом Unix: пособие хакера — «Хакер»
Первое,что нужно делать перед
взломом — узнать тип используемой OS. Это можно
сделать несколькими способами.
СПОСОБ 1
Если админ — полный кретин,то при конекте по телнету (23) ты узнаешь и OS,например
RED HAT 6.2
Login:
Значит OS — RED HAT 6.2
СПОСОБ 2
Скачиваешь себе какой-нибудь сканер, где есть функция определения OS. Таких прог туча. Например кульная прога Shadow Scan. В ней есть все необходимые модули для хака. Также есть прога nmap (для *NIX). Тоже очень полезная, имеет множество
фич. Даешь адрес хоста, и все… На этом проги не
останавливаются. Рассмотрим на примере работы
Shadow Scan. Прога находится в модуле SANT. Называется Site Info. Вводишь адрес и получаешь не талько OS, но и Web Server и кучу полезной инфы (ftp server,SSH,HTTP,DNS,PROXY,TELNET,IMAP и
т.д.), которая,кстати,тебе пригодится.
СПОСОБ 3
Социальная инженерия.
Тут все понятно…
Можно пойти разными способами. Можно сделать
звонок, если есть номер, и сказать,типа новая
прога требует указать OS… Также можно послать по
мылу письмо админу, можно представиться кульным Web
Master’ом, ПРОГРАМИСТОМ, КОМПЬЮТЕРНЫМ ЭКСПЕРТОМ.
Можно прикинуться самим админом.
Вариантов много…
СПОСОБ 4
PING
ping IP_жертвы
Определяем по TTL(время жизни)
linux 2.0.x — 64
Win 95 OSR/2 — 32
Nowell Netware — 128
Как ты уже понял-64,32,128-значения TTL.
Дальше экспериментируй сам!:))
СПОСОБ 5
Самый надежный. Зателнетиться на открытые порты
и проверить версии демонов (UNIX) или серверов(Win NT).
Если будет типа IMAP, sendmail, Apache, QPOP то это UNIX. Если
IIS,Microsoft FTP и т.д. то это Win NT.
Итак первое дело
сделано.OS у нас есть. Второе,что ты должен
сделать,это просканить все порты. Это также можно
сделать прогами Shadow Scan и nmap. Особенно обрати
внимание на sendmail, qpop, imap, rlogin, ssh, mount, named, amd, talk.
Теперь беги на свалку эксплоитов:).Эксплоит — это
утилита, реализующия в проге недокументированные или закрытые функции.
Можешь сбегать на rootshell,technotronic и т.д.А также очень советую посетить BUGTRAQ. Ищи
эксплоиты именно для твоей версии. Например, если
на вражеском хосте стоит какой-нибудь sendmail,
9.8.9./9.8.9,
то эксплоит под версию sendmail 3.4.3./3.4.3 не
подействует :)). Версии должны полностью совпадать
(это для *nix, но есть эксплоиты и под NT, хотя в NT
есть более интересные вещи типа null session, SMBShare,
NETBios, но об этом мы поговорим в другой раз). Нашел
эксплоит? Молодец, но чтобы привести эксплоит в
рабочее состояние нужно его скомплить. Не
пугайся. Все достадочно просто. Обычно эксплоиты
написаны на Си, поэтому пользуемся командой
gcc(компилятор). Например ты скачал эксплоит
sux.c. Самый простой вариант компиляции:
# gcc -o sux sux.c
Теперь запускаешь
его командой:
# ./sux имя_жертвы
Также могут
потребоваться дополнительные опции в команде.
При успехе ты получишь шелл и твой UID и GID будет
равен 0(root). Вот ты и суперпользователь:). Но
эксплоиты — это еще не все. Нам еще может помочь NFS.
Посмотри камандой showmount расшаренные ресурсы
атакуемого хоста. Например:
# showmount -e
имя_атакуемого_хоста
Ты видишь,например:
/usr
/var (everyone)
/home (everyone)
Теперь пора монтировать home( (everyone) говорит о том,что каталог доступен любому по NFS). Монтируем:
# mount
имя_атакуемого_хоста:/home /mnt
Где /mnt -имя вашей
папки на компе для монтажа. Теперь можно
создать в папке какого-нибудь пользователя файл
.rhosts с содержанием ‘+ +’. Всё, можешь спокойно
логиниться в сеть с помощью rlogin. И это лишь пример.
В принципе взломать или затроянить систему можно
практически из любой папки.Просто нужно
пораскинуть мозгами.
RPC
Вызов удаленных процедур. Обычно rpc используют для NFS и NIS. Инфу о RCP
сервисах можно получить с помощью команды rpcinfo.
Узнаешь, какие демоны запущены на атакуемом
хосте. Теперь опять возвращайся к поиску
эксплоитов.
И еще. Если ты в локалке с жертвой, то все очень просто. Считай — все пароли у тебя в руках. Самый простой способ — поставь снифер. Он будет обнюхивать все пакеты и вытягивать все пароли. Хотя если в локалке есть что-то типа Kerberous (метод шифрования), то сниферов можно послать. Нужно либо пользоваться локальными эксплоитами либо троянить систему (если есть доступ к конфигурационным и
исполняемым файлам).
ЗАМЕТЕНИЕ СЛЕДОВ
Допустим, ты получил
доступ. Но как остаться незамеченным? Как скрыть
свой взлом?
Спокойно. Все делается довольно просто.
Логи (обычно) хранятся в этих местах:
Solaris
/var/log
/var/cron/log
/var/lp/logs/
/var/saf/_log
/var/adm/log/asppp.log
HP-UX
/usr/adm
IRIX
/usr/adm(IRIX 4.0)
/var/adm(IRIX 5.2)
Sun
/var/adm
/var/log
OSF
/var/adm
BSD
/var/log
/var/account
Но кому охота очищать эти файлы? Админ сразу заметит! Лучше воспользоваться прогой, которая удаляет только твои данные.Она очистит все логи от твоих IP и т.д.
ВРЕМЯ ТРОЯНИТЬ
СИСТЕМУ
Можно добавить
своего пользователя в /etc/passwd, и сделать UID и GID =0.Но пользователь будет светиться в логах! Также root или прога cron (если ей сказано проверять всех usero’в на UID и GID=0) может заметить вас! Лучше пользоваться Rootkit’ом. Он затроянит систему и сделает вам суперпользователя,который не будет светиться в логах! Телнетьтесь на 21 порт в вводите логин rewt, пароль satori (скорее всего).Теперь тебе дадут рута,без записей в логах!!!
И на крайний случай — если тебе не удастся взломать *nix, то не отчаивайся, можно например потыкать Web Server,
троянчики на мыло покидать. Да и много всяких
вещей. Удачи!
xakep.ru