Проброс виртуальной машины ESXi в DMZ

Возникла необходимость высунуть машинку хостящуюся на виртуальной ферме VMware ESXi в дикий интернет, с ограничением доступа к локалке. Точнее возникла необходимость дать к ней доступ левым людям из вне с полными правами на рута. В связи с чем поднялся вопрос о том как пробросить одну из виртуальных машин в DMZ.

Надо отметить, что, порыв сообщества на тему атаки на хост ESXi, я не смог найти достаточно инфы об уязвимостях позволяющих получить доступ к ноде или соседям по ноде, поэтому собственно и решил, что оптимальным решением будет убрать хост в DMZ, предоставив к нему доступ из интернета и закрыв локалку. Другое дело что существуют различные варианты атаки на L2 OSI теоретически позволяющие ломануть DMZ на уровне VLAN’а, но это уже совсем другая история, не имеющая отношения к этой. Тем более что и современные средства организации VLAN’ов предоставляют богатый функционал защиты и минимизируют риски от подобных атак. Если кому то интересно покопать на тему атак на VLAN, то дам несколько ключевых букаф:
CAM flooding;
MAC flooding;
VLAN Cross-talk Attacks;
VLAN Hopping;
ARP spoofing;
Spanning-Tree attacks;
VRRP / HRSP tampering

(more…)

Рубрика: IT безопасность, Сети | Ваш отзыв »

Передача больших объемов данных через интернет

За последний годы, объемы данных возросли многократно, и если в 96 году файловый сервер стоявший в здании М9 имел RAID-массив аж на целых 500 мегабайт, что вызывало благоговейный трепет, то сейчас, покупая флешку, даже не рассматриваешь модели менее 8Гб. Соответственно в разы возросли и скорости передачи данных, но с приходом новых поколений пользователей, появляется новая проблема, когда люди начинают недоумевать отчего они не могут переслать 2-3Гб по почте.

Максимум что мне приходило на почту- это была первая версия Дыбалы, которую мне в свое время переслали ребята из РТКОММа и я тогда конечно намучился, получая по почте около 150 мегов. Так что когда 5-6 лет спустя я обнаружил у пользователя в почтовом ящике письмо с вложенным роликом на полгига, которые он пытался отправить по почте, я даже не удивился.

Вообще пользователей стоит приучать к тому, что максимальное вложение письма должно составлять 20-25 мегов, но и даже таких объемов идеально избегать, пользуясь архиваторами и не забывая о том, что почтовые программы (больше всего конечно мелкомягкие) любят дописывать от себя 10-15%. И если твой админ позволяет отправлять 30+ метров почты, то это не значит что на принимающей стороне работает такой же добряк. Вообще большие сообщения это головняк для админа, так как они загружают почтарь который вынужден держать сессию на получение такого письма, да к тому же забивают почту. Поэтому пользователей стоит приучать использовать другие механизмы передачи файлов через интернет. Естественно, что админ может предложить юзверям пользовать общедоступные веб-ресурсы, вроде депозита или рапидшары, но более корректно в моем понимании- это иметь собственный FTP сервер, позволяющий выкладывать и скачивать с него файлы.

Собственно о планировании такой схемы я уже как то писал, но так и не сподобился развернуть все более подробно, так как в тот раз как обычно никому было ничего нужно, а вот буквально на днях оказалось, что надо было вчера, так что видимо в ближайшее время выложу факу настроек ftp-сервера.

А к вышесказанному остается только добавить немного слов по разграничению прав: либо на уровне пользователей, либо на уровне отделов, если пользователей катастрофически много. Но в любом случае на каждую папку надо давать два типа прав: на чтение и на полный доступ, причем полный доступ следует выдавать только проверенным людям, и менять логин на полный доступ хотя бы раз в месяц, поскольку как я уже как то писал- если контора ведет активный файлообмен, то логины довольно быстро сливаются в паблик, ибо вы даете сотруднику, тот дает проверенному клиенту, тот дает дизайнеру или одмину васе, вася дает подружке маше, а поскольку маша дает всем, то через пару недель ваш логин публикуют на каком нить форуме. То есть, если возможно, то логины на запись следует вообще активировать по запросу, поскольку изнутри конторы пользователи работают через smb.

Доступ же к аккаунтам изнутри как раз организуется с полными правами, либо к рутовой папке для гостя, где торчат все акки, либо же персонализировано по логину. Для особо не спокойных можно естественно прикрутить к AD, но в случае разграничения на уровне отделов, видимо придется повозиться.

На счет подключения к веб-серверу- тут все просто- просто прописываем либо субдомены для каждой папки, либо паролим каждую папку и даем адреса вида: наш_сайт/папка1

Рубрика: Сайты и их проблемы, Сети | Ваш отзыв »

Критическая уязвимость RDP от Microsoft

Коли уж я сел на своего излюбленного конька, то не могу не отписаться про новую дырку в Microsoft RDP, в которую мелкомягких тыкнули носом, так что они на прошлой неделе включили в плановые обновления заплатку к этой уязвимости. Надо отметить, что уязвимости подвержены все системы, начиная с XP и Server 2003 и дальше вверх. Уязвимость позволяет, отсылая специально сконфигурированные пакеты RDP, выполнить на удаленной системе произвольный код с правами System.

Но самое веселое во всем этом, что данная уязвимость была найдена итальянским безопастником Луиджи Ориемма аж в мае 2011 года, и данные о ней были переданы в Microsoft, которые разродились срочным патчем только после того, как данные об этой дырке просочились в инет.

Но еще более забавно, что уже 15 марта на китайских сайтах уже появился эксплоит использующий данную уязвимость и по заголовкам внутри кода, имеется предположение, что ноги данного эксплоита растут из Microsoft MSRC – лаборатории мелкомягких, как раз по отлову подобных дырок.

Так что если у вас таки торчат какие то серваки в инет, то привет от майкрософта- патчите срочняком по данной ссылке с офф.сайта. Хотя конечно памятуя о работе мелкомягких по срочному устранению кртических уязвимостей- как бы эта заплатка не наделала еще больших дырок.

Рубрика: IT безопасность, Windows, Сети | Ваш отзыв »

Ограничения стека протокола TCP/IP в Windows

Здесь нет никакого открытия, так что инфа из серии “спасибо кэп”, но до сих пор приходится сталкиваться с вопросами, почему в хрюше ака Windows XP перестает работать интернет или бродилка, при большом числе одновременных закачек ftp, или тем более работе торрент клиента.

Дело в том, что у Windows XP SP2 имеются ограничение на число одновременных сессий tcp (а точнее сессий согласования TCP half-open), установленное в режим 10. Сделано это было мелкомягкими умышленно, для ограничения распространения червяков и дос-атак, которые с выходом Windows XP расцвели буйным цветом, и в первоначальной версии Windows XP этого ограничение отсутствовало, но мелкомягкие посчитали, по своей обычной традиции, что нет смысла бороться за живучесть системы, и проще зарезать число конкурирующих сессий.  Причем в XP это реализовано на уровне системного файла TCPIP.SYS, который необходимо патчить с помощью программы: EventID 4226 Patcher Version 2.23d которая увеличит это число до 50.

Для того чтобы увеличить до максимума число возможных сессий в виндовой сетке, следует сделать следующее: запустить глобальные политики CTRL+R -> gpedit.msc ->Конфигурация компьютера -> Конфигурация Windows -> Параметры безопасности -> Локальные политики -> Параметры безопасности -> Интерактивный вход в систему -> выставляем его в 0 (отключение ограничения)

или же внести правки в следующий ключ реестра:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount
изменив значение CachedLogonsCount на 50 или 0

В Vista SP2 и Windows 7 это ограничение уже было убрано из драйвера протокола, но в системе имеется ограничение на использование сетки для шаринга и печати, установленное в 20 соединений. Проверить это можно, вбив в dos-promt  (CTRL+R -> cmd) команду net config server, которая выведет максимальное число пользователей.

А также максимальное число входящих подключений к IIS, которое можно настроить через ключ реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpNumConnections (тип: DWORD, задав его от 5000 до 65536)

Рубрика: Windows, Сети | Отзывов: 2 »

FTP для маленькой такой компании

Сегодня пришлось поехать к клиенту как раз по поводу многострадального шарика с видяхами, и пока суть да дело- нарисовался планчик для локального ftp-сервера, который необходимо поставить в конторе. Рисовать не охота, да и Visio я себе так и не поставил, поэтому опишу на пальцах куда рыть.

Собственно принципиальная схема работы следующая: FTP-сервер работающий под ProFTPd с хранением учеток в базе MySQL. К нему есессно подрублен контроль файлов и clamav. Сам сервак находится в DMZ за фаерволом, где на него подключены собственно порты 20, 21 и все выше 1024, для отработки пассива. Также ставим apache и открываем 80 порт на фаерволе, так как некоторым тупым бургам понадобится скачивать из локалок, а по своему опыту работы я неоднократно сталкивался с ситуацией когда у таких “васяток” банально нет чела который им мог бы объяснить как переключить ftp-клиента в пассивный режим, а факи которые им шлешь на почту, почему то не вспомогают. Вот для таких граждан необходимо также иметь web-сервер на котором завести некоторое количество папочек, запароленных на основе .htaccess.

Остальные пакеты это samba сервер, через который внутренние клиенты раскидывают файлы по папкам, с аутентификацией на уровне пользователей. Тут собственно можно сделать два варианта: либо разрешить прохождение smb пакетов из сетки через фаервол, либо засунуть сервак вторым интерфейсом в локалку, но это не особо хорошая идея, ибо хотя шансов что нам сломают ftp крайне мало, но все равно это получается лишний вход. В принципе можно его вывести вторым шнутом во внутренний DMZ, куда уже фильтровать пакетики от внутренних сетей. Такой ход более гиморный, но зато и наиболее спокойный.

Каждому юзверю, или отделу создается папка- желательно конечно с квотированием, иначе ftp-сервер превращается в неконтролируемую файлопойку похуже файл-сервера. В этой связи есть смысл подрубить еженедельную отправку на почту статистики вывода:
df -ah
du -ch -d 1 /ftphome

Теперь по защите всего это хозяйства, как я и сказал: на фаерволе делаем маппинг по портам, или же безусловную трансляцию, закрывая все порты ниже 1024 порта, кроме 20, 21 и 80 вовне, а внутрь от сервера пропускаем все или же только smb протоколы.

После чего все это дело настраиваем и радуемся жизни.

Рубрика: FreeBSD, Сети | Ваш отзыв »

Организация беспроводного моста на больших расстояниях

Пригласили меня тут на некую железнодорожную станцию, на которой находится офис и удаленная от него площадка разгрузки вагонов. На площадке находится видео-наблюдение, которое транслируется в офис. Расстояние между ними где то метров 600-700, и со слов клиента сообщение идет через инет.

Приехал в офис и стал ломать голову каким образом все коннектится, ибо естественно ни в какой интернет пакеты не уходят, а ломятся на внутреннюю адресацию. В итоге оказалось, после длительных лазаний под столами и трейсов пакетов, что все замучено через так называемый wi-fi мост, с которым я морочился на уровне совмещения рутеров Linksys. Тоже самое поднимается на беспроводных точках доступа от D-link, но тут все было завернуто через оборудование Ubiquiti Networks- американского производителя беспроводного оборудования для 4G и WiMax.

(more…)

Рубрика: Сети | Ваш отзыв »

Забавный глюк работы связки named и ssh

Столкнулся тут с довольно забавным глюком связки ssh + named, в процессе прикручивания сервера доменных имен на работающем фаерволе. Брандмауэр был настроен уже какое то время назад, практически по мануалу который я напостил недавно, и вот на днях возникла необходимость сделать его еще и сервером доменных имен.

Хотя это конечно не безопасно, особенно исходя из концепции параноидальности на сетевом экране, тем более что не далее как в этом феврале была найдена уязвимость BIND 9 ветки, приводившая к DoS севера имен, при трансфере зоны или динамическом обновлении, но тем не менее пропатчив BIND и открыв его только вовнутрь сетки, решил что пользовать можно.

И вот в процессе настройки, когда вроде бы named резолвился для localhost но почему то не хотел стартовать на внутреннем интерфейсе, я решил раскомментировать строку в named.conf содержащую следующее выражение:
query-source address * port 53;

после чего решил добавить страку разрешающую обращение к фаерволу из внутренней сетки по 53 порту, и перегрузил сервак. После чего ssh у сервера интеллигентно отпал. Точнее сервер крутился и при обращении к нему выдавал запрос имени пользователя, но после его ввода, вместо ожидаемого в ответ запроса пароля, просто отключал пользователя. Поскольку сервер был удаленный, я звякнул тамошнему админу, и попытался его руками все вернуть обратно, но замена новых правил фаервола на новые- ничего не дала. Так что пришлось пилить в контору.

Изначально я полагал, что допустил в синтаксисе правил какую то ошибку, из-за которой правила не догружались до конца, но оказалось что таблица правил фаервола была загружена полностью. Да и ssh висел на порту, а вот named почему то отсутствовал. Попытка его стартануть не увенчалась успехом, так что я полез в логи, где обнаружил что прописал в named.conf фалы для зоны “.” дважды, точнее я то прописал один раз, не заметив, что они уже были обозначены. Что и приводило к падению демона named. Но что еще более поразительно- это же и приводило к нестабильной работе сервера ssh, отрубавшего логин к серверу.

Судя по всему, в случае падения демона named, резолвить имена подключений не получалось, так как в /etc/resolv.conf стоял только 127.0.0.1, и по этой самой причине соединение и рубилось на корню.

Так что на всякий случай добавил в /etc/ssh/sshd_config строчку отрубающую резолв имен: UseDNS no , хотя, в принципе, можно было бы и добавить дополнительных DNS серверов в resolv.conf

Рубрика: Сети | Ваш отзыв »