Сценарий: 172.16.1.0/24 - WAN сеть, 192.168.X/24 - “белая” DMZ сеть, 192.168.100+X - “серая” LAN сеть
root@gate:~# sh net_gate.sh root@gate:~# cat /etc/network/interfaces
... auto eth2 iface eth2 inet static address 192.168.100+X.1 netmask 255.255.255.0
root@gate:~# init 6
root@server:~# sh net_server.sh root@server:~# init 6
gate# apt update server# apt update
# cat /etc/hosts
127.0.0.1 localhost 192.168.100+X.10 lan.corpX.un lan
# cat /etc/resolv.conf
search corpX.un nameserver 172.16.1.254
# cat /etc/hostname
lan.corpX.un
# cat /etc/network/interfaces
auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.100+X.10 netmask 255.255.255.0 gateway 192.168.100+X.1
# init 6
lan# apt update
Уже развернут у провайдера
Будет развернут на системе server
Разворачиваем на системе gate в сети LAN
gate# sh conf/dhcp.sh
Будет развернут на системе lan
Достаточно Локализация временной зоны
Сценарий: внешний корпоративный сайт на server
Сценарий: сканирование портов сервисов системы server, находим web сервер
Сценарий: определяем “вручную” нет ли уязвимости directory traversal
gate.isp.un$ curl --path-as-is http://server.corpX.un/../../../etc/passwd gate.isp.un$ fetch -o - http://server.corpX.un/../../../etc/passwd gate.isp.un$ telnet server.corpX.un 80
GET /../../../etc/passwd HTTP/1.1 GET /../../../etc/shadow HTTP/1.1 GET /../../../etc/master.passwd HTTP/1.1
Сценарий: автоматизированный поиск уязвимостей
Сценарий: перехват учетных данных при обновлении пользователем user1 веб информации на server по протоколу ftp
Сценарий: находим модифицированное ПО (можно изменить код web сервера)
server# cd / server# wget http://gate.isp.un/unix/xor_ddos_linux_trojan.tgz server# tar -xvzf xor_ddos_linux_trojan.tgz
Сценарий: фиксируем обращения к файлам базы данных учетных записей со стороны процессов с EUID=user1. Можно тестировать из shell или запустить www сервер на server с правами user1
Сценарий: Запуск www сервера с правами пользователя user1 не позволит получить через него доступ к /etc/shadow (linux) или /etc/master.passwd (freebsd)
Сценарий: с помощью POSIX ACL запрещаем пользователю user1 читать файл /etc/passwd
Сценарий: ограничения, накладываемые политиками на www сервер на server не позволят получить через него доступ к любым файлам, кроме разрешенных даже в случае запуска его с правами root
Сценарий: запуск www сервера на server в chroot позволит получить через него доступ только к файлам, которые мы скопировали в chroot окружение
Сценарий: переносим www хостинг в контейнер
iptables -F FORWARD iptables -P FORWARD ACCEPT
Демонстрирует преподаватель
Сценарий: разворачиваем на server, MTA для домена corpX.un, IMAP без SSL. Учетные записи почтовых пользователей не должны иметь shell, предоставляющий командную строку
Сценарий: заменяем банеры сервисов SMTP, IMAP, FTP, HTTP, CIFS, SSH
gate# curl -I http://www.corpX.un/
Демонстрирует преподаватель
Сценарий: замена сервиса HTTP на HTTPS на www
Сценарий:
Задание: использование пользовательских сертификатов для аутентификации и авторизации
lan# cp -v user* /disk2/samba/ lan# cp /var/www/html/ca* /disk2/samba/ lan# chown -v games /disk2/samba/*
Сценарий: использование пользовательских сертификатов на server для электронной подписи (PEM :)
Сценарий: использование пользовательских сертификатов для доступа по https на www
Сценарий: использование пользовательских сертификатов для доступа по imaps на server
Сценарий: разрешаем SSH подключение к www только из LAN
Сценарий: Honeypot на gate
Сценарий: блокируем атаки SSH сервиса на gate
Сценарий: размещаем данные на шифрованном разделе для lan сервиса SAMBA (сетевой диск с двойным дном:)
Сценарий: защита LAN от посторонних сервисов DHCP
Сценарий: защита http сервиса на server от bruteforce
Сценарий: фиксируем атаки из WAN, проверять с host системы
Сценарий: блокируем атаки из WAN, проверять с host системы
Сценарий: подключаемся с “домашнего” компьютера по RDP к компьютеру в LAN сети предприятия через “рабочую” linux систему, с которой есть доступ в LAN
Реализация: Отключаем на host системе VirtualBox Host-Only Network адаптер и, используя доступность сети LAN с server, осуществляем доступ по RDP к системе client1 через учетную запись user1 системы server
Сценарий: подключаемся с “домашнего” компьютера по RDP или SSH к компьютеру в LAN сети предприятия, через “внешнюю” linux систему, к которой “заранее” установлено SSH соединение из LAN
Реализация: отключаем доступность сети LAN “отовсюду”, считаем server - “внешним” ресурсом (например VPS), осуществляем доступ по RDP к client1 или SSH к lan через туннель в SSH соединении к server, установленном с client1 или lan
Сценарий: требуется предоставить авторизованный доступ пользователей, работающих на ноутбуках и ездящих в командировки, к любым сервисам в сети LAN компании, например - CIFS
lan# scp /etc/ssl/openssl.cnf gate:/etc/ssl/ lan# scp /var/www/html/ca.crt gate: lan# scp /var/www/html/ca.crl gate:
Сценарий: требуется объединить сети филиалов