• ↓
  • ↑
  • ⇑
 
Записи с темой: 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

15:34 

Ключи...

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

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже: GetKeys.vbs

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

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

@темы: Security, Scripting, PowerShell

14:29 

Windows 2008 Server RODC

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

RODC - Контроллер домена в режиме "Только для чтения". Новый режим работы КД, появившийся в Windows 2008. Предназначен для установки в филиалы, где нет достаточного уровня безопасности хоста контроллера (читай, самого компьютера). Этот режим выгоден тем, что не хранит на себе пароли пользователей, за исключением специально выбранных - как правило, работников того самого филиала. Чем выгодно? В самом паскудном сценарии - краже хоста (и такое бывает), нужно будет сбросить пароли только тех учетных записей, пароли которых кэшированы на этом контроллере, а не всего домена. Удобно? Удобно.
Еще одно преимущество работы контроллера в таком режиме кроется в самом его названии - Только для чтения. Это значит, что никакие операции над структурой домена с этого контроллера невозможны, он способен только читать информацию, но не изменять ее. Случайное удаление каталогов, атрибутов в этом случае исключается. Опять же - удобно? Да.
Однако, как и довольно часто, при установке такого контроллера есть свои нюансы. Про режим работы леса в целом и отдельных его доменов я говорить не буду. Это расписано в документации по RODC достаточно подробно.
Первый и главный момент - в домене уже должен быть полный КД уровня Windows 2008 Server. Полный - это значит способный записывать информацию в Active Directory. RODC в процессе своей работы будет общаться именно с таким контроллером, на КД предыдущих версий он даже не посмотрит. Если устанавливается новый домен на базе Windows 2008 Server - это требование будет выполнено автоматически. В случае же перехода с КД Windows 2003 Server этот момент нужно учитывать.
Второй момент - перед установкой RODC ко всему лесу нужно применить команду adprep /rodcprep. Эта команда расширяет текущую структуру каталога, добавляя в нее элементы, обеспечивающие репликацию данных с обычного контроллера на RODC. Если этого не выполнить, в процессе установки будет выдана ошибка следующего содержания:
You will not be able to install a read-only DC in this domain because "adprep /rodcprep" was not yet run.

Информативность текста ошибки стопроцентная. Что делать - ясно без подсказок.
И вот тут-то кроется главный подводный камень, рассчитанный на тех, кто переходит с домена 2003 на домен 2008. Для того, чтобы установить RODC в смешанной среде (где есть и КД 2003, и КД 2008), просто выполнить adprep /rodcprep недостаточно. После ее выполнения вы будете снова натыкаться на приведенную ошибку. В документации по RODC описания подобной проблемы мне найти не удалось, решение откопалось на одном из блогов - Клац!
Интерес на этой странице представляет следующий комментарий:
Just adding a Windows Server 2008 DC to the domain doesn’t mean that you can install RODC in it too – actually you can and that’s when you will experience problems. You have to make sure that the Windows Server 2008 DC is configured (and is really functioning) as a GC and the PDC master role has been transferred to it.
Если это перевести на русский язык, то получаем следующее: простой установки КД 2008 в текущую среду недостаточно. Для получения возможности установки RODC в текущий домен на контроллер домена под управлением Windows 2008 Server нужно передать роль Глобального Каталога (GC) и роль эмулятора первичного контроллера домена (PDC Emulator). Только в этом случае установщик RODC опознает текущий домен, как удовлетворяющий всем требованиям, и согласится на установку RODC.
Как всегда - все дело в волшебных пузырьках одной волшебной галочке. Но нужно знать, где ее искать. Надеюсь, кому-то эта информация позволит сэкономить свое время на поиск решения проблемы.

@музыка: Sleepthief - World Gone Crazy

@темы: Security

23:19 

PsExec

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

Программа PsExec является частью пакета PSTools, разработанного компанией SysInternals. Представляет собой утилитку, которая способна запускать произвольные процессы на удаленной системе, чем и полюбилась системным администраторам. Ее удобство может превзойти разве что ssh протокол. Но есть и несколько подводных камней, одним из которых является вот такая ошибка:

Error establishing communication with PsExec service on XXX:
All pipe instances are busy.


Меня эти слова преследовали полтора года. Самое удивительное, что утилита процесс на удаленной машине запускает, но результат выполнения получить не может. А чаще всего именно результат и важен. Ковыряние интернета и гугля выдало одну из возможных причин: блокирование данной программы антивирусными средствами. В целях проверки истинности предположения антивирус на целевом компьютере был снесен, после чего была выполнена чуть ли не классическая команда:
psexec \\xxxx ipconfig

Результатом стали все те же строки об ошибке. Что за дьявольщина? Затем вспомнилось, что многие антивирусы считают практически весь набор PsTools зараженным вирусом вида Remote Admin. Вирусов там нет, но сами программы как раз и являются средствами удаленного администрирования. Дальше взгляд упал на красную букву K в системном трее на исходном компьютере, после чего файл psexec.exe был внесен в список доверенных. Ошибка исчезла.

Полтора года со мной был касперский. Полтора года он меня защищал от всякой напасти. Надо сказать, хорошо защищал )

@музыка: Runestone - The Well of Secrets

@темы: Security

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

главная