Вручную или с некоторой автоматизацией (программа, скрипт). Допустим, просканировать каким-то сканером портов: сеть, подсети, хосты на предмет открытых портов (сервисов). Например, тем же Nmap. Что в рекламе не нуждается. Проверить доступность сервисов: доступны они изнутри и(или) из вне? Проверить настройки сервисов. Проверить актуальность версий сервисов.
Ломают же как? Если не ошибаюсь в чем-то, то, примерно, так:
1) Находят какой-нибудь хост (подсеть) из целевой сети по отдельному IP-адресу (диапазону адресов).
Если хост должен быть недоступен из, к примеру, внешней сети - закрыт за межсетевым экраном, то, понятно, что он не должен отвечать на эхо-запрос (ping). Помимо межсетевого экрана, подсеть может быть разграничена маской подсети. То есть, допустим, из одной подсети мы не сможем попасть (соединиться) к другой. Т. к. у них последняя цифра адреса (IPv4) отличается. Это две, логически разных, разделенных подсети. Они не общаются вот так вот просто. Если только где-то, на сетевом оборудовании (концентратор, коммутатор, маршрутизатор), не будет определена маршрутизация между этими подсетями. Которые присоединены физически к разным портам данного оборудования. Т. к., логически, это могут быть подсети разных отделов компании, надобности во взаимодействии между которыми может не быть совсем. И в целях безопасности, и еще каких-то целях (исключения любопытства сотрудников - например) они разделены. Бухгалтерия и инженерный отдел - например. Тут, конечно, схема сети или топология нужна. Со всеми адресами, подсетями. В голове сложно это представлять: все возможные связи, коммуникации.
2) Сканируют открытые порты на хосте.
Если это, к примеру, веб-сервер, то у него должен быть открыт только этот порт (доступен сервис). 80-й вроде или какой там, сейчас не вспомню. Понятное дело, что что-то постороннее - уже подозрение. Лишние сервисы нужно остановить, либо закрыть к ним доступ межсетевым экраном данного хоста.
3) Пытаются удаленно подключиться к сервису.
Естественно сервис просто так не пускает всех подряд. Вероятно, есть какое-то шифрование. Ну или запрос пароля. Это в норме.
Можно допустить работу, ради удобства, без пароля (к примеру, FTP отдела архива) в какой-то своей, локальной подсети, где достаточно безопасно. Нет посторонних подключений, всякого разного трафика. Но если сервис смотрит наружу, является доступным из глобальной сети (Инет), то тут, ясно дело, меры предосторожности строже.
Помимо пароля и шифрования, настройками самого сервиса, вероятно, можно задать диапазон адресов, подключение с которых не будет сброшено сервисом. Это дополнительное, полезное ограничение.
4) Пытаются получить управление, используя уязвимость (эксплоит), в данном сервисе.
Сервис должен быть обновлен до последней версии. Чтобы в нем отсутствовали различные баги и возможность получения несанкционированного доступа к хосту.
Ваша задача: пройти тем же путем и удостовериться что данных проблем нет.
Это, конечно, все долго, лениво и так далее. Ну а что, работа такая. Ведь всякие навороченные сканеры уязвимостей или услуги - вероятно стоят немало.
Можно, конечно, чего-то не учесть, не разобраться с каким-то аспектом. Но, все же, это снижает общую уязвимость и снижает вероятность потенциального взлома.
Вот как я это вижу. Так, с ходу.
Кстати, вероятно вы в курсе, а может быть и нет. Есть такие системы как IDS (система обнаружения вторжений). Которые, при обнаружении некой подозрительной активности, отправляют сигнал. Возможно, также, сразу, автоматически блокируют адрес-источник потенциальной атаки. Например, при обнаружении действия того самого сканера портов. Пример системы: Snort.
Сканер - здесь просто инструмент. Вот в чьих руках: админа или хакера он окажется и с какой целью - другой вопрос. И да, этим же сканером можно и проверить самому работоспособность IDS.
Средний
Простой
