Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: security (список заголовков)
12:53 

Google banned.

В Dash'e под Chronostasis'ом.

Собственно, за это ребятам из РосТелеКома надо кое-что отрезать, размножаться такие не должны.
 photo Capture_zpse9afd6e5.png

Поясню, что на картинке. При попытке открыть вложение-картинку из письма в Gmail эта картинка загружается с сайта Googleusercontent.com, все вложения там хранятся. Сейчас же при попытке обратиться к этому сайту по защищенному протоколу (а google уже давно работает только по нему), браузер напарывается на то, что к этому сайту привязан (с какой-то стати) совершенно левый сертификат от РосТелеКома. И, естественно, вопит о том, что "вас пытаются наколоть". Ну а если проигнорировать это предупреждение и сказать "пусти меня туда все равно" - нарвемся на стандартную плашку от РТК, сообщающую, что googleusercontent.com заблокирован, как хранящий недопустимую в нашей стране информацию.
Как я уже говорил, за подсовывание левого сертификата надо кое-что отрывать. Без наркоза...

UPD. По состоянию на 15:25 - блокировка снята. Но факта дебилизма это не отменяет.

@настроение: Enrage!

@темы: Security, Этот безумный мир

11:43 

Trend Micro Office Scan upgrade

В Dash'e под Chronostasis'ом.

Встала задача - обновить наш антивирус. С версии 10.6 на версию 10.6 Service Pack 1. В принципе, это достигается при помощи внутренних средств обновления, но мне захотелось поднять полностью новый сервер и перевести клиентов на него. Потому как работа старого меня не устраивала, даже бекапы базы данных не делались, валились с ошибкой. Впрочем, это не удивительно, сервер этот был последовательно обновлен с 10 до 10.6. Наверняка уже столько хвостов осталось, что ужас. В общем - чистая установка - как всегда, лучший выход.
С самой установкой и настройкой проблем вообще никаких. С переносом клиентов, которые на текущий момент активны - тоже. А вот что делать с теми машинами, которые могут месяцами не включаться? Их ведь просто так не перетащишь, команду не дашь с административной консоли. Что ж, такую задачу решать уже доводилось - придется воспользоваться сценариями запуска компьютеров. В итоге клиент сам после запуска переползет, куда надо.
Основа сценария - маленькая утилитка IpXFer, которая и пинает клиента в нужную сторону. Выполняется на целевом клиенте с соотвествующими ключами от имени администратора или самой машины (если речь о сценарии запуска). Одновременно с этим не мешало бы проверять - а не переехал ли клиент уже на новый сервер. Ведь если он там - повторно перекидывать его туда не надо.
Начнем с проверки. Кучу своих настроек клиент Trend Micro Office Scan хранит вот тут:
HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion
Нас очень сильно интересует параметр Server, в котором и прописывается "место жительства" клиента. Выполнив команду
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server
получаем требуемое.
Теперь полученное нужно проверить - что же там лежит. Ради интереса воспользовался вот таким методом:
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
Сначала мы получаем значение параметра Server, затем в полученном пытаемся найти имя нашего сервера. Если найдем, все в порядке. Если не найдем - получим ошибку в системной переменной %ErrorLevel%. Следующий шаг - проверка этой переменной. Если она равна нулю - не делать ничего, клиент уже на "месте прописки". Если же не равно нулю - значит клиент у нас бродяжничает, и его пора пришпилить на место.
Отдельный вопрос - x64 системы. У них расположение нужного нам ключа реестра немного отличается:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion
Следовательно, нам нужно будет еще проверять, на каком типе систем исполняется скрипт. Ну а потом, после всех проверок, запустить нужную утилитку с кучей параметров.
Целиком весь сценарий будет выглядеть вот так:

echo off
if exist "%systemdrive%\program Files (x86)" (goto x64) else (goto x86)
:x86
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
if NOT %errorlevel% == 0 call \\server\share\ipxfer.exe -s %ServerName% -p %HTTP_Port_Number% -m 1 -c %Client_Port_Number%
goto rest

:x64
reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\TrendMicro\PC-cillinNTCorp\CurrentVersion" /v Server | findstr "%ServerName%"
if NOT %errorlevel% == 0 call \\server\share\ipxfer_x64.exe -s %ServerName% -p %HTTP_Port_Number% -m 1 -c %Client_Port_Number%

:rest

Обработка напильником - стандартная. Вместо %ServerName%, %HTTP_Port_Number%, %Client_Port_Number% подставить нужные значения и положить обе утилитки ipxfer и ipxfer_x64 в какую-либо общую папку, куда могут обратиться компьютеры домена.

P.S> После обновления клиента у него меняется значок. Кто-то из "бдительных" пользователей это заметил и тут же начал трезвонить в IT отдел - "Помогите, у меня на компьютере вирус под названием Trend Micro Office Scan!". Ирония в том, что сотрудник сам не знает, на сколько же он прав...

@темы: Security

10:30 

Remote Control...

В Dash'e под Chronostasis'ом.

Нет, сегодня речь пойдет не о таких вещах, как RDP или LogMeIn. На днях приехала первая из трех заказанных карт удаленного управления серверами Aten IP8000. Обычная PCI плата, которая добавляет функционал iLO (это если в привычных мне терминах HP), а по-русски - возможность управлять сервером на протяжении всего времени его работы, от самого старта по питанию до выключения этого самого питания. Ну и бонусом приятные штуки как Remote Media и ему подобное.
Все бы ничего, но захотелось настроить авторизацию на этой карте через Active Directory, это банально удобнее. Все необходимые настройки для этого есть. Открываем форму, вбиваем все необходимые данные:
 photo IP800_zps66ce820e.png

Отличие от этого скрина в том, что галку Enable Authorization я тогда поставил.
Сохраняем настройки, даем рестарт карты... и понимаем, что LDAP-авторизация не заработала. Перепроверяем настройки еще раз - понимаем, что все внесено верно, но не работает. Штудируем мануал и видим, что в мануале раздел LDAP вообще никак не освещен. Что за...
Гугл, запрос. Ответом стала шокирующая информация из инструкции к другому KVM той же компании - для того, чтобы работала авторизация через MS AD, нужно расширить схему AD! Засада, потому что таких прав у меня нет, да и для чего такие сложности, вообще неясно.
Еще более вдумчивое изучение того же справочного файла сказало: отставить панику, сейчас все сделаем. И действительно, все сделали. Теперь по шагам:
1. Выбор между LDAP или LDAPS. Тут все очевидно - что используется, то и нужно выбирать, причем LDAPS предпочтительнее. Негоже пересылать информацию об учетных записях в открытом виде (привет старому доброму PsExec).
2. LDAP Server IP, Port. Тоже все понятно, где LDAP развернут - тот IP адрес и подставляем. Порты в подавляющем большинстве случаев используются стандартные.
3. Timeout. Как долго наша карточка будет ждать ответа от LDAP. Тоже ничего особенного.
4. LDAP Administrator DN. Имя административной учетной записи, от которой будут происходить операции в AD. До сих пор не могу в толк взять, для чего здесь нужно именно административную запись вводить. Ведь карта в самой AD ничего не меняет, а читать из каталога позволено всем. Но делать нечего, вводим учетку в формате:
CN=username,OU=users,DC=example,DC=com
5. LDAP Administrator Password. Все просто - пароль указанной административной учетки.
6. Search DN. Вот здесь уже интереснее. Это имя контейнера, в котором, а также во всех его подконтейнерах, учетные записи будут иметь право логина на нашу карточку.
7. IP8000 Admin Group. Параметр, связанный с предыдущим. Члены указанной группы из AD будут обладать правами администратора и на карточке. Все остальные - только базовыми, об этом чуть ниже.
И остается та самая галочка Enable Authorization. Именно она определяет логику работы карточки с AD. Итак:
1. Параметр включен. Для определения того, кто может зайти, кто не может, а кто является администратором, карточка будет искать среди атрибутов учетных записей два особенных, которые и создаются во время расширения схемы AD.
2. Параметр выключен. На карточку смогут зайти все пользователи, чьи учетные записи находятся в OU, указанном в пункте 6, и будут обладать урезанными правами. Пользователи же, чьи учетные записи находятся в группе, указанной в пункте 7, смогут делать с карточкой что угодно. Изменения схемы в этом случае не требуется.
Таким образом, параметр Enable Authorization я отключил, после чего авторизация через LDAP заработала так, как требовалось.
И отдельно о правах пользователей. Ради теста зашел под специальной технической учеткой, созданной для различного рода проверок, с ограниченными правами на карточке. Каким же было мое удивление, когда я увидел, что такой учетке доступен раздел Power Management и кнопки выключения сервера и его жесткой перезагрузки. Эта засада будет подстерегать тех, у кого административные учетные записи лежат в структуре AD в том же OU, что и обычные учетки сотрудников. Обходится этот момент просто - нужно создать отдельную OU, перенести туда нужные учетки, и именно эту OU прописать в настройках LDAP-авторизации карты. После этого обычным учетным записям зайти на нее просто не удастся, они будут отфильтрованы, а административные учетки будут обладать всеми необходимыми правами.

@темы: Security, Этот безумный мир

11:42 

SkyDrive #2

В Dash'e под Chronostasis'ом.

В продолжение предыдущего разбора полетов с Небесным Диском.
Причину рухнувшей синхронизации найти все же удалось. Оказалось, что синхронизация отказывает тогда, когда SkyDrive пытается закачать файл, созданный прямо в веб-интерфейсе, или залитый в облако через него же. И валится синхронизация, когда клиент находится за файрволлом. Поскольку используется TMG, пришлось, вооружившись гуглом, копаться в нем. Ответ найден - всему виной Malware Inspection, если быть совсем точным - параметр "Force content requests (remove HTTP Range header)". Подробно - здесь: Клац!
Отключение этого параметра восстанавливает синхронизацию тут же.

@темы: Security

14:44 

SkyDrive

В Dash'e под Chronostasis'ом.

Во время запуска этого сервиса было много шума. Что ж, место там есть, пора и попробовать его в деле.
Итак, два компьютера, на обоих установлен клиент, версия - последняя. Структура проста: папка Документы, папка Разное. В папке документов лежит все то, что нужно сохранить как бекап. Папка Разное предназначена для обмена данными между двумя компьютерами (лень мне флешку таскать, лень). Папка документов должна синхронизироваться с домашним компьютером. Папка Разное - с домашним и рабочим.
Задача не такая уж и сложная, учитывая, что SkyDrive вслед за Дропбоксом функцию выборочной синхронизации уже представил и внедрил. Настраиваем параметры, видим что на домашнем компьютере синхронизация идет как и полагается. На рабочем же... а вот тут жестокое разочарование - синхронизации НЕТ ВООБЩЕ. Клиент навечно зависает в состоянии Processing changes. При этом папку Разное он видит, даже создает ее на жестком диске рабочего ПК. Ужасно, просто ужасно.
Делаем финт ушами - даем полную синхронизацию всего, что есть в облаке, с рабочим ПК. Затем, когда синхронизация пройдет успешно, поставить выборочный режим. По уверениям Microsoft в этом случае клиент сотрет с компьютера все, что не относится к выбранным для синхронизации файлам и папкам, после чего будет спокойно кушать только выбранное. Сказано - сделано. После включения выборки все "лишние" файлы были послушно удалены с компьютера, но после этого... да, вы правы, синхронизация опять накрывается. Перезапуск клиента эффекта не дает. Включение полной синхронизации процесс обмена файлами восстанавливает тут же. Браво, Microsoft!
Причем "браво" - дважды. И второй раз - за то, как вы вообще прописали логику работы этого приложения. Никогда не думал, что MS сами напишут просто ярчайший пример "дикого софта". Итак:
1. Клиент ставится прямо в профиль пользователя (изменить это НЕЛЬЗЯ)
2. Папка временных файлов создается прямо в корне диска, на котором будет лежать пользовательская папка SkyDrive. Она будет скрытой, называется SkyDriveTemp.
И все это - с вытекающими проблемами, если на компьютере действует жесткое ограничение прав на запись в каталоги вместе с Software Restriction Policy.
За эти два пункта хочется пристально, очень пристально посмотреть в глаза тому человеку, который все это придумал.

@музыка: One More Time - Here comes the ghost

@темы: Security, Этот безумный мир

20:38 

TMG 2010 vs Java. War continues...

В Dash'e под Chronostasis'ом.

Фаза 2. Тестовая группа расширена до сотни человек. И что, вы думаете, что все прошло гладко? Да как бы не так.
Есть у нас подразделение, работающее с веб-сайтом, попортившим уже немало крови. Знающие да поймут меня: audatex. Вот честно, дай мне волю, искоренял бы ересь под названием Java всеми доступными мне методами. Впрочем, я отвлекся от темы.
Суть в следующем. Конфигурация браузера: использовать скрипт автоматической настройки маршрутизации. Интернет работает, страницы открываются, все авторизуется как надо. А вот как только дело касается запуска Java-апплета, процесс втыкается намертво. Java просто не может пробиться через файрволл. Ради теста переключаем пользователя на предыдущую конфигурацию и на старый прокси. А там настройка такова: прямо в браузере поставлена галка "Использовать прокси-сервер" и прописаны необходимые параметры. Честно, этот метод я не люблю, и в TMG 2010 я от него уйду (отсюда и скрипт автоматической настройки). Через старую прокси все работает. Закономерный вопрос выражается в трех символах: WTF?
Ковыряем интернет, находим вот такую любопытную статью:
support.microsoft.com/kb/925881 - An ISA server or Forefront Threat Management Gateway server requests credentials when client computers in the same domain use Internet Explorer to access Web sites that contain Java programs.
В частности, заинтересовало описание второго метода решения проблемы. О сетевых настройках внутри самой JVM как-то не подумалось, а зря. Что ж, идем на проблемное рабочее место и начинаем играться с параметрами JVM. Результат неутешителен. Попытка использовать ее настройки по-умолчанию (Use browser settings) провалена, как и описано выше. Попытка прописать новый прокси прямо в JVM - снова неудача. Попытка подставить тот же адрес сценария автонастройки - дальше продолжать? Остается последний вариант - Direct connection. Я точно знаю, что он сработает, но в то же время использовать его я не могу. Потому что в этом случае запрос пойдет на старую прокси. Что ж делать?
Остается только одно, установить на машину TMG/ISA client, чтобы он заворачивал, причем гарантировано, все запросы на новую прокси. Сказано - сделано, клиент поставлен, настроен, JVM сказано - ломиться напрямую, мимо прокси. Настройки браузера приведены к виду указанному ранее - через сценарий автонастройки. Все заработало.
Ну а теперь, как говорилось в известной передаче - внимание, вопрос? Нафига козе баян? То есть зачем в JVM такое богатство настроек прокси, если реально работают только два варианта, а один из них еще и с серьезными ограничениями?
Нет, никогда мне не подружиться ни с Java в общем, ни с разработчиками на этой платформе.

@музыка: Davol - Lucky day

@темы: Security, Этот безумный мир

09:57 

TMG 2010. It's a war.

В Dash'e под Chronostasis'ом.

Вот и добрались мои руки до этого "замечательного" продукта - Treat Management Gateway 2010. Все та же линейка ISA-образный файрволлов, которые я от всей души ненавижу, и с которыми волею судьбы приходится работать. Весьма своеобразные это файры, должен сказать. В копилке уже два случая, за которые очень хотелось бы пристально посмотреть в глаза разработчикам. Итак, начали.
1. Во всей документации сказано, что ISA/TMG - файры, обрабатывающие правила исключительно по их следованию в списке - от первого до последнего. Еще во времена ISA 2004 у меня появились большие сомнения в том, что это верно. TMG 2010 и его функция имитации трафика с логами этого процесса только подтвердили эти догадки:
условия теста - есть правило, разрешающее доступ всем на группу сайтов yammer.com. Ну и последним, естественно, идет правило, запрещающее все и всем, правило по-умолчанию.
Имитация трафика - пакет по протоколу http на сайт yammer.com. Имя пользователя несущественно, доступ в разрешающем правиле - для всех.
результат теста
Покупайте наших слонов. Первым делом проверено правило тотального запрета, и ясен красен, что тестовый пакет ему удовлетворяет. Хорошо хоть, что тут же показывается ремарка, что, мол, есть тут у нас какой-то список правил, так уж и быть, проверим и его...

2. Обработка адресов в URL Sets. Если меня читают те, кто еще застал в своей жизни символы-маски со времен DOS - меня поймут. Как вы думаете, если в правиле задано следующее - разрешать всем доступ на сайты, удовлетворяющее маске *yammer*, пропустит ли TMG 2010 пользователя вот по такому пути: http : // yammer . com / sitename (без пробелов, естественно)? Как ни странно, ответом будет однозначное НЕТ. В то же время, если в правиле изменить маску на *yammer.com - файр станет пускать на все сайты группы yammer.com и все их подразделы, что и требовалось.
Эх, старпер я, как есть старпер. До сих пор мыслю категориями DOS, но ведь и работали они до сих пор...

@музыка: Diane Arkenstone - The sacred forest

@темы: Security, Этот безумный мир

20:22 

SRP #2 - Deal with shortcuts

В Dash'e под Chronostasis'ом.

Итак, скелет этой политики все же сделан. После ковыряния гугла и technet'a найдено решение, как блокировать запуск *.lnk из всех каталогов, кроме необходимых. Причем метод должен работать для любой установки ОС, независимо от диска, версии, языка.
Сутб проста - расположение особых пользовательских каталогов зашито в системном реестре, откуда мы можем их получить и подставить в параметры политики. Таких путей лично я насчитал 10. Рабочий стол, Мои документы, Программы, меню Пуск, и Автозапуск. Пять на пользователя и эти же пять для профиля All Users. Именно их и надо по условиям задачи подставить в исключения. Что ж, раскрываем список Additional Rules и указываем нижеприведенные 10 строк в режиме Unrestricted.

%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Programs%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Start Menu%*.lnk
%HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Startup%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Desktop%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Documents%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Programs%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Start Menu%*.lnk
%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Common Startup%*.lnk

Осталась самая малость: собрать все остальные пути исключения для "дикого" софта, провести тестирование на фокус-группе. В случае успеха в области действия политики можно смело проставить Domain Users, и забыть о таких поганцах, как Skype, QIP, Google Chrome и иже с ними. Кто в курсе, меня поймет.

Track of the Day (TotD): Davol - Jhalinka
Time range: 1:57 - 2:17

Прослушать или скачать Davol Jhalinka бесплатно на Простоплеер

@музыка: Davol - Jhalinka

@темы: Security

20:03 

Trend Micro Office Scan Client 10.5 part 2

В Dash'e под Chronostasis'ом.

Окончание истории, начатой тут. Как я и предполагал, процесс удаления файлов растянулся надолго. Аж на двое суток неторопливого выпиливания орды мелких, очень мелких файлов. MFT от такого поворота дел просто в ужасе была, поскольку вся эта мелочь явно хранилась прямо в ней. Статистика это подтверждает: на диске рабочей станции на 70 с небольшим тысяч файлов MFT заняла около 70 мегабайт, а вот на многострадальном файловике на те же 69 тысяч она уже разрослась аж до 4 Гб! Ясно, сильнейшая фрагментация после удаления всего мусора, с этим еще придется повозиться, но главное, работа антивируса, все же починено.

@музыка: E.S.Posthumus - Anumati

@темы: Security, Viruses and Spam

22:55 

Trend Micro Office Scan Client 10.5

В Dash'e под Chronostasis'ом.

По непонятной причине стоящий на файлопомойке клиент корпоративного антивируса отцепился от управляющей консоли. Offline режим, и все тут. Принял решение его переустановить, хотя и помню об замечательной утилитке IpXfer, которая и нужна для переподключения клиента к другому серверу. Или тому же самому, как раз вот в таком случае.
Сказано, сделано, команда на удаление отдана. В процессе видно, что удаление происходит с ооочень большим скрипом, удаление служб продолжалось минут 15, на стадии удаления файлов система воткнулась еще на 40 минут. Все симптомы зависания. Делать нечего, распечатывается специальный документ, и пошагово проходим процедуру ручной очистки системы. В конце этого списка значится - reboot. Ясное дело, что боевой файловый сервер перезагрузить в течение рабочего дня никто не даст, значит, откладываем это дело до вечера, команду на рестарт можно отдать и из дому.
Перезагрузили. С радостным лицом поставили клиент заново и... поняли, что что-то пошло не совсем так, как надо.
"Все вышло не так, как ты планировал, Итэн..." (с) M:I:2
Вместо трех нужных служб в системе зарегистрированы только две. Более того, служба сканирования в реальном времени запускаться отказывается в принципе, ссылаясь на то, что ей нечего делать(!). И вспоминаем, что до повторной установки нужно было все же вынести старые каталоги антивируса. Дурная голова ногам рукам покоя не дает. Ладно, снова сносим антивирус, и ожидаемо получаем затык на стадии удаления файлов. Что ж, взглянем на этот процесс под микроскопом, то есть Process Monitor'ом, по критерию:
Process Name is NTRMV.EXE
Результат следующий - данный процесс вовсю елозит по папке C:\Program Files\Trend Micro\Office Scan Client\Hlog, открывает файл, пишет в него, закрывает.
Что ж это за логи такие? Залезаем в папку проводником и получаем зависший проводник. Снять процесс, попробовать пролезть другим шеллом. Получаем то же самое. Ладно, расчитай мне размер этой папки. Explorer.exe уходит в подсчеты, отгребает на себя гигабайт оперативной памяти, но результат удручает - найдено 0 объектов. К слову сказать, ни TC, ни cmd в этом плане тоже не отличились. Что же делать? Это логи, они находятся в папке, которая полностью предполагается к сносу. Их надо снести. Прпробуем метод, который меня еще не подводил:
cmd
cd c:\program files\trend micro\officescan client
del /f/s/q hlog\*.*
После минутного раздумья шел все же начал удалять все то, что там было. Тогда я еще не знал, сколько там всего.
Через минут 20 этого терзания диска я остановил процесс и попробовал снова зайти туда проводником. Увиденное повергло меня в шок. Проводник все же смог показать часть этого каталога: 300000 объектов, каждый размером меньше килобайта. И это - еще не весь каталог. Ну что же, повторный запуск удаления всего и вся через командную строку и ждать результатов. Это надолго...
P.S. Поймал себя на мысли, что это уже не первые боевые действия с данным антивирусом. Связка Trend Micro и Symantec Backup Exec уже показала себя во всей красе.

@музыка: KOTO - Die Klapperschlange

@темы: Security, Viruses and Spam, Этот безумный мир

16:23 

File System Audit

В Dash'e под Chronostasis'ом.

Наверняка каждый системный администратор сталкивался с задачей - вынуть да положить руководству на стол информацию о том, кто стер какой-либо очень нужный файл с сетевого хранилища. Почти все знают, как включить аудит событий файловой системы. Если кто-то не знает, очень рекомендую ознакомиться вот с этой статьей: How do I enable auditing on certain files/directories? - это очень просто и быстро.
После включения аудита в логе безопасности файлового сервера станут появляться события о работе с файловой системой. Вот как, например, выглядит запись о запросе на удаление какого-либо файла:


В этом сообщении видно все, что нам нужно для отчета. Единственная проблема заключается в том, что в логе безопасности сообщений будет огромное количество. И среди всего этого вороха данных нам нужно будет как-то отыскать нужную информацию. Известно, что все логи сервера - это файлы, значит, нужно каким-то образом в автоматическом режиме прочитать файл лога, вытащить оттуда записи согласно определенным критериям, и этот комплект записей выложить на стол руководству. Осталось лишь найти инструмент, которым можно этого добиться. Он есть, называется LogParser, взять можно вот здесь: LogParser @ Microsoft.com.
Инструмент этот относится к разряду CLI-утилит - вся работа осуществляется при помощи командной строки. В разборе того, что и куда вводить, чтобы прочитать нужные данные, мне очень сильно помогла вот эта страница: Log Parser - The "Swiss Army Knife" for Intrusion Investigators and Computer Forensics Examiners. По прочтению и пониманию материала был сформирован следующий ярлык вызова утилиты:


А в качестве содержимого файла запроса DeleteEvents.sql используется следующее:

Да, это самый обычный SQL запрос. Допустим, меня очень сильно интересовало, какой нехороший человек стер мой любимый файлик, называвшийся "тест.txt". Вводим запрос, нажимаем Enter, и в ответ получаем красивую табличку вот такого вида:

Откуда видим, что нахала, стершего файл, зовут user01, принадлежит он к домену TEST. И файл был стерт сегодня. Что ж, задача выполнена, мерзавец найден. Дальше уже пусть руководство разбирается, что с user01 делать и какие санкции к нему применять.

P.S. Все вышеописанное справедливо для Windows 2008 Server. В версии 2003 формат записей в логе безопасности был иным, поэтому файл sql запроса скорее всего нужно будет серьезно менять.
P.P.S. Небольшая хохма на десерт. Существуют платные решения из сферы аудита, одно из таких я сегодня захотел попробовать: sсript Logic File System Audit. Как всегда при запросе пробной версии нужно заполнить простыню. Ок, давайте, посмотрим, что и куда писать надо. Вот кусок этой простыни:

Ничего более подходящего, чем Вооруженные силы Европы я там не нашел. А что, хорошая страна ведь ;)

P.P.P.S. Окинул запись взглядом анонимного пользователя - ГРАФИЧЕСКИЕ СМАЙЛЫ! УБЕЙТЕ СЕБЯ О СТЕНУ В КРОВАВЫЕ ОШМЕТКИ!!!

@музыка: KOTO - Die Klapperschlange

@темы: Security

22:09 

PCI DSS

В Dash'e под Chronostasis'ом.

Original @ ServerFault.com.
Перевод истории на Хабрахабре.
Читать всем, даже если вы не имеете никакого отношения к аудиту платежных систем и процессинговых центров. Это феерия.

@темы: Security, Этот безумный мир

19:25 

GFI EndPoint Security 4.3 Transition

В Dash'e под Chronostasis'ом.

Решил посмотреть, как будет себя вести при обновлении программный комплекс GFI EndPoint Security. Вполне возможно, что придется это сделать, обновившись с 3-й на четвертую версию. В принципе, все достаточно гладко, за исключением пары-тройки моментов:
1. При обновлении 4-я версия не терпит присутствия на сервере своей старшей сестры, требует ее снести. Следовательно, бекап конфигурации должен быть. На всякий случай (впрочем, он должен быть в любом случае).
2. Для установки обязательно наличие .NET Framework версии 2.
3. Самое занятное: после установки основная служба отказалась стартовать. В окне установщика висит сообщение о том, что установщик эту службу пытается запустить, в оснастке служб она значится, как неработающая. Пробуем "помочь" установщику, запустив службу руками. Минута ожидания, и ОС выводит свое стандартное сообщение о том, что служба стартовала, но затем благополучно завершила работу, так как "ей нечего делать". Помнится, когда я с таким сообщением впервые столкнулся, оно меня очень сильно позабавило, вот тут ее пример описан: www.gotdotnet.ru/blogs/GRP/2838/
Ладно, веселье весельем, а запустить ее нужно. Лезем в базу знаний компании GFI и находим там следующее:
GFI EventsManager service does not start - Клац!
The GFI EventsManager executables are digitally signed by default. When trying to start the service, the application must download the Certificate Revocation List to authenticate. If the download fails due to network connectivity or security reasons the service will fail to start by timing out.

Это уже интереснее. Выходит, что для старта службы программы EventsManager необходим доступ в Сеть. Да, на моем сервере доступа не было (ибо зачем?). И хоть EventsManager - это не EndPoint Security, решил проверить, сработает ли рекомендация для моего случая. После обеспечения доступа во всемирную паутину и повторного запуска установки EndPoint Security служба успешно стартовала, и GFI EndPoint Security 4.3 благополучно завершил установку.
Апгрейд клиентов же просто тривиален.

@музыка: Ryan Farish - Opus (2011)

@темы: Security

23:16 

Exchange 2003 OWA и кириллические учетные данные.

В Dash'e под Chronostasis'ом.

Весьма любопытный случай.
Один из сотрудников жалуется на то, что из дома не может попасть на свой почтовый ящик - система просто не принимает его учетные данные. Провожу тест у себя, сбрасывая пароль на стандартный для таких случаев - все отлично срабатывает. Ну не иначе где-то ошибся человек.
Раз, второй, третий... Умом понимаю, что что-то не так. Ну не может человек настолько упорно набирать пароль неправильно. Тем не менее, проблема заглохла, больше звонков длительное время не поступало.
Недавно эта неприятность снова голову подняла, но уже с другим сотрудником. Этот поступил умнее, пришел в отдел лично. Лично набрал свой пароль на консоли администратора - не пускает. Прямо тут же меняем ему пароль на стандартный - все проходит на ура. Сотрудник меняет пароль на свой собственный - и тут же получает отлуп. Как так?! Посмеялись, потом начали размышлять, что и к чему. В глаза бросился тот факт, что тестовый пароль на английском языке, а сотрудник свой набирал на русском. И задавал его на русском. То есть мы пришли к тому, что OWA по какой-то ей ведомой причине не принимает национальные символы в пароле. Ладно, рекомендовали сотруднику использовать англоязычный пароль, а для себя пометили задачку в выполнению, но не как горящую.
Сегодня все же дошли руки до поднятия ручного Exchange 2003 SP2. Настраиваю OWA, меняю у тестового пользователя пароль на кириллический, жму Enter - и я в ящике этого пользователя. Все чудесатее и чудесатее (с).
Форумы молчат. Есть упоминания о том, что имеется проблема в случае кириллических логинов, но здесь другой случай. На яндекс в подобных вопросах уже давно не надеемся, гугл разводит руками. Полчаса вдумчивого сравнения конфигурации... Затем мысль - а что у нас с настройками регионов и кодовых таблиц. На самом деле региональные настройки не так важны, нам деньги не мерять. А вот кодовые таблицы - это уже любопытно. Оказалось, что на боевом сервере в настройках кодировок для non-Unicode приложений стоит английский язык, на тестовом же сервере - русский. Ну что же - смена на русский на боевом, перезагрузка... Долгие 3 минуты ожидания, смена пароля тестового доменного пользователя, заход на OWA... Success!!!
Exchange 2003 SP2 и настройки не-Юникод приложений - такого я представить себе не мог. Теперь представляю.
Еще одна поставленная галочка, еще один случай в копилку. Надеюсь, кому-то эта запись сэкономит немало времени в подобной ситуации.

UPD. Если конфигурация Exchange 2003 включает в себя два сервера, front-end и back-end, менять кодовую таблицу нужно на front-end-сервере.

@музыка: Rise Against - Help Is On The Way Shift 2 Remix

@настроение: Shocked

@темы: Security, MS Exchange

22:14 

Android.

В Dash'e под Chronostasis'ом.

Да, я решил "узнать своего врага в лицо". Купил себе на пробу LG-P500, он же Optimus One.
Прошло уже больше года с того памятного мне дня, как я впервые столкнулся с этой платформой. Если уложиться в несколько слов - она обрела человеческое лицо. Как ни странно, теперь работать с телефонами на базе этой системы стало действительно удобно. Быстрые, функциональные, батарею сильно не кушающие...
Но не все так гладко, как может показаться на первый взгляд. И вот почему:
SMS are intermittently sent to wrong and seemingly random contact.
По ссылке очень много иноязычного текста, рекомендуется к ознакомлению всем обладателям андроидовых телефонов.

Сухая выжимка:
Рано или поздно любой андроидовый телефон может отослать сообщение не тому человеку. Вместо нужного адресата он подставит контакт из вашего списка, и сообщение уйдет именно ему. Что за этим может последовать - просто включите вашу фантазию.
Дата первого сообщения в этом баг-трекере - 28 июля 2010 года. Честно говоря, даже Microsoft покуривает в стороне от такой скорости реакции на события такой степени важности.

Я с этим столкнулся лично. Перерыв кучу материала и проведя несколько тестов пришел к следующему выводу - не отвечать на сообщения, используя область уведомлений. Схема работы этого бага следующая. Вы принимаете сообщение от человека А, читаете его, отвечаете или нет - неважно. Затем вы получаете сообщение от человека Б, при помощи области уведомлений отвечаете на него. Дальше вариантов два: либо сообщение уйдет человеку Б, и все довольны; либо аппарат подставит в качестве адресата того самого бедолагу А, от которого вы получили сообщение ранее, и оба участника получают конфуз.
Баг непостоянен, может проявиться, может нет, но во всех случаях подставлялся именно предыдущий абонент, приславший сообщение, не случайный.

На всякий случай, информация о телефоне:
LG-P500
ver. 2.2
Kernel 2.6.32.9
Build FRF91

На сегодняшний день все, что мы имеем по этому инциденту, это признание компанией Google проблемы и обещание выпуска заплатки в ближайшее время:
www.bbc.co.uk/russian/science/2011/01/110107_go...
Смотрим на дату новости - 8 января.

@темы: Этот безумный мир, Security, Android

23:16 

NLA - Network Layer Authentication

В Dash'e под Chronostasis'ом.

Признаться, когда только вышел SP3 для Windows XP, я не до конца понимал, что же это за опция такая. Полностью ее прелесть осознал только теперь, когда появилась возможность в спокойной обстановке поковырять веб-доступ до опубликованных на сервере терминалов приложений. Суть в следующем. При попытке запустить любое из приложений TS Web App, пользователь вынужден ввести свой логин и пароль, даже несмотря на то, что в системе он авторизова. А как мы помним, Active Directory на том и стоит, что пользователь, прошедший авторизацию уже должен иметь доступ ко всем ресурсам, на которые у него есть права. SSO - Single Sign-On - так зовется этот замечательный механизм. Повторный ввод пароля же обусловлен тем, что RDP клиент, который и используется при работе с TS Web App, SSO в Windows XP не поддерживает.
SP3 поменял расстановку сил, но даже установив этот пакет обновлений, просто так SSO не получить. Для этого нужно как раз включить ту самую опцию - NLA. Именно на сетевом уровне аутентификации Windows и будет передавать учетные данные.
Сам по себе процесс включения NLA довольно прост, нужно лишь изменить два параметра в реестре каждой системы, на которой будет использоваться веб-доступ к терминальным приложениям (а в идеале - для всех рабочих станций с Windows XP SP3). Очень подробно все это описано вот тут: MS Knowledge Base. При помощи групповых политик результат достигается очень быстро и просто.
Однако, не было бы этой записи, будь все так гладко. Убеждаюсь, что рабочие станции удовлетворяют требованиям для включения NLA - сделано (долго ли проверить две тестовые виртуальные машины). Требования там, кстати, следующие:
- наличие RDP-клиента версии 6 и выше (выполняется автоматически при установке SP3)
- наличие клиентских расширений групповых политик (без этого система не получит сведения о модификации реестра). Взять эти расширения можно здесь: MS Download Center.
Пробую запустить любое приложение. И получаю вот такое:

an authenication error has occured code 0x507

В то же время тестовая Windows 7 спокойно заходит на терминал, спокойно может запустить любое из опубликованных приложений. Значит, что-то не так с включением NLA. Пробегаюсь по политике и настройкам терминального сервера. В настройках сервера было указано следующее: Allow connections from computers running any version of Remote Desktop. Рассудив, что в тестовом домене все компьютеры теперь поддерживают NLA, устанавливаю следующее: Allow connections from computers running verision of Remote Desktop with NLA. Подтверждаем изменения.
В политике же ревизия показала следующее - по идее, в параметры Security Packages и SecurityProviders нужно дописать названия соответствующего пакета и библиотеки. Однако, политика старалась дописать в значение еще и то, что там было раньше. Неверно, так как может привести к дублированию информации. Устанавливаю действие "Заменить", а в значения прописываю все то, что там должно быть. Сохраняю изменения, даю команду двум машинкам с XP SP3 на обновление политик, после чего перезагружаю их.
После всех этих операций искомый результат был получен - пользователи компьютеров под управлением Windows XP SP3 получили возможность запускать терминальные приложения в режиме прозрачной аутентификации (привет клиентам Citrix и режиму pass-through ;) ).
Ради интереса снова переключил терминальный сервер в режим разрешения подключений от любых клиентов Remote Desktop - все прекрасно работает.

@музыка: Ryan Farish - Shine

@темы: Security

22:48 

Software Restriction Policy

В Dash'e под Chronostasis'ом.

Три слова, которые могут очень многое. А впридачу к ним - очень познавательная статья об этой самой политике:
The Six Dumbest Ideas in Computer Security
Настоятельно рекомендую к прочтению и осмыслению всем тем, кому по должности приходится следить за порядком в корпоративных компьютерных сетях.

@музыка: Peter Sterling - Forever and a Day

@темы: Security

18:44 

Hardware...

В Dash'e под Chronostasis'ом.

Прошедший понедельник стоил мне пары седых волос, не иначе.
Если пытаться обрисовать ситуацию двумя словами - хрень нереальная, других определений не находится, потому что такого на моей памяти не случалось никогда.
Вполне невинная процедура - вывод из домена сервера, предназначенного к полной переустановке операционной системы (плановый апгрейд до windows 2008), операция, проведенная за всю жизнь уже очень большое количество раз, ошибиться в которой можно только в одном случае - выведя из домена не тот сервер.
Выглядело все это следующим образом. Спуститься в серверную, на KVM переключиться на нужный сервер, отдать все необходимые команды для вывода из домена, перезагрузить его. А пока перезагружается, подключить почему-то неиспользуемый порт iLO (какая расточительность, однако).
Где-то в середине процесса в серверную поступает звонок из админской и вопрос - "что у нас за апокалипсис?".
В самой серверной все неизменно, только теперь уже бывший контроллер домена пущен в рестарт после вывода из домена. После этого сообщают, что по сети недоступны первый DC, почтовый сервер, шлюз. Смотрю на передние панели указанных хостов и понимаю, что двое из них - контроллер и шлюз, уже спят. Переключаюсь на почтовик, и вижу, что он в состоянии выключения операционной системы. Что за ересь?! В довершение всего этого дела намертво повисает KVM, лишая нас консольного доступа к серверам.
Ладно. DC у нас в домене не один и не два. Проживем. Шлюз - уже критичнее, почта - совсем критично. Запускаю шлюз, запускаю почтовик, запускаю DC. Первый и третий поднимаются довольно быстро. Почтовик же задумался. Дожидаюсь вывода на экран стандартного приглашения на ввод логина и пароля, и в трубку: "Проверяй, почтовик поднялся". Ответ убил - коннекта от Outlook до Exchange не наблюдается, но пинги есть. Плохи дела. Ctrl+Alt+Delete, и у меня волосы встают дыбом - Exchange выпал из домена.
Что за этим может последовать, лучше и не думать. Провести ночь в серверной борясь с конфигами, со структурой в AD, не хотелось абсолютно. Абсолютно не понимая, почему такое могло произойти, захожу под локальным админом, лезу в логи. Параллельно открываю консоли контроллера и шлюза. Офигеваю от того, что шлюз тоже вне домена. А в логах видно, что и шлюз, и почтовик выпали из домена в результате штатной операции, выполненной... мной же! Я в ауте... В голове всплывает один из давным-давно прочитанных документов о повторном присоединении рабочей станции к домену под существующим именем. Вот и появилась возможность проверить эти сведения на практике, хотя я и предположить не мог, что проверять это все буду на Exchange, для которого членство в домене - это альфа и омега.
ADUC, Find Computer, Reset Account. После чего на почтовике выполняется штатная операция присоединения к домену и рестарт. Долгие пять минут ожидания, вопрос в трубку "ну как?" и ответ: "У Егорыча почта поднялась!".
Все выдохнули. С этого момента Outlook'и медленно, но верно начали находить сервер и штатно работать с почтой. По аналогичному сценарию добавляем в домен шлюз, после чего работа сервисов нормализуется. А у нас теперь великий геморрой - найти причину этого бардака.
Логи контроллера, логи почтовика, логи шлюза, гугл. И при помощи этого всего нашли причину. Ей оказалась та самая несчастная KVM, через которую я и выводил из домена нужный сервер. Эта, с позволения сказать, железка, в результате какого-то одной ей ведомого сбоя ретранслировала все, что я вводил с консоли на нужный сервер, еще на три порта. А потом вылетала напрочь. Судя по логам всех участвующих в представлении серверов, на все 4 машины в одно и то же время были посланы одни и те же команды, в одно и то же время. У меня все же не 4 пары рук и не 4 головы, чтобы подобное вытворить. Даже комментарий к операции перезагрузки был на всех 4 машинах одним и тем же - "12". Контроллеру домена повезло, его из домена так просто не вышибить, потому он просто перезагрузился и заработал в обычном режиме. А вот почта и шлюз оказались уязвимы.
Что ж, по крайней мере, теперь точно известно, что случайный вывод Exchange-сервера из домена (дико звучит, но все же) не является фатальным. Заодно стало понятно, почему при выводе рабочей станции из домена не удаляется ее учетная запись из базы данных, и как эту учетную запись можно использовать.
Но все же иногда эти знания даются слишком дорогой ценой...

@музыка: Stone Age - Sellet

@темы: Security, Этот безумный мир

17:29 

Windows System Logs

В Dash'e под Chronostasis'ом.

Недавно мне уже доводилось писать о том, что пропуск лог-файлов при полном бекапе сервера под Windows 2003 Server имеет место быть. Сегодня дошли руки произвести эксперимент по полному резервированию и восстановлению уже Windows 2008 Server. Здесь все куда лучше - логи сохранились в бекапе и при восстановлении системы оказались на своем законном месте. Это радует.

@музыка: Ronald Jenkees - Guitar Sound

@темы: Security

23:50 

Chain of Earth -> Stone Shock.

В Dash'e под Chronostasis'ом.

Да, да, именно шок.
Преамбула - поставлена задача: найти, кто сидел за конкретным компьютером в определенный промежуток при условии, что сотрудники могут пересаживаться. Казалось бы, что сложного, открываем журнал Security и смотрим логи. Проблема в том, что требуемый промежуток - это уже довольно дальнее прошлое, в текущих логах уже давным давно стертое. Ладно, есть бекапы. Открываем их, лезем в заветную папку %windir%\system32\config, ищем там secevents.evt... и понимаем, что в полном бекапе контроллера домена этого лога нет. Как нет и любого другого из системного журнала событий. Вдумчивое ковыряние гугла подтверждает мысль - ntbackup даже при полном резервном копировании не сохраняет логи. Это касается Windows 2003 Server, платформу 2008 на это еще не тестировали (есть повод создать новую виртуальную машину и поиздеваться над ней).
Что ж, задачу удалось решить, но несколько иным и довольно кривым методом, но осадок остался. Одновременно с этим встал вопрос - что делать с бекапом логов. В итоге был найден и доработан напильником вот такой скрипт:
Backup Security Events.vbs

Далее - Планировщик задач и задача по созданию резервной копии журнала на регулярной основе.

@музыка: Alice in Videoland - Ladykiller

@темы: Security, Scripting

Записная книжка

главная