Issue-2017.11.06

Тел. +7 904 707-11-25
E-mail: yudenisov{at}aport2000.ru

Категория «16+»

Мой сайт

[Выпуск 06.11.2017]

[19.12.2017 23:09:10]

Сегодня провёл обновление операционной системы на своём ноутбуке до версии Windows 10 Fall Creator. Сразу после обновления Windows работала нестабильно, до тех пор, пока не закончились все обновления драйверов и систем безопасности. После этого система стала работать стабильно, и мне удалось насладиться всеми её новшествами. Мне понравился новый дизайн тем, заставки и новый инструмент «Люди» в трее.

Те сбои, которые мне пришлось устранять вручную.

  1. Сбился в очередной раз драйвер видеокарты. Нет, разрешение и цветность остались прежними, как и производительность. Но для части приложений перестали отображаться их рабочие области, вместо них – чёрный экран. К счастью, мне помог хак для Windows 7 под названием Colors_reg.zip. Распаковав архив и запустив reg файл, я с лёгкостью вернул правильное отображение элементов и рабочих областей на экране.
  2. Пропали настроенные гаджеты рабочего стола. Это было ожидаемо, и после восстановления программы 8gadgetpack всё вернулось на свои места;
  3. Перестали работать символические ссылки, которые были созданы пользователем в предыдущей версии Windows 10. Из-за этого мне по-глупому пришлось переустановить несколько приложений. К счастью, без последствий.

 

[[17.12.2017]]

[Подключение в Microsoft IIS SMB шары]

Сегодня, наконец, выяснил, как подключить к Microsoft IIS SMB шару на удалённом сервере.

Суть проблемы. Необходимо организовать файловое хранилище данных на одном компьютере, в то время как IIS сервер развёрнут на другом. Виртуальные каталоги на внешних и удалённых дисках Microsoft IIS не разрешает подключать как физические диски, и переход по символическим ссылкам будет запрещён. Единственным способом подключить виртуальный каталог – это указать при его добавлении в IIS его полное UNC имя. Но тут опять возникает проблема. По-умолчанию виртуальные каталоги, как и физические, подключаются под локальной учётной записью IIS_IUSR, идентификатор которой на каждом компьютере свой. В результате при доступе со сквозной проверкой подлинности система опознаёт неизвестный идентификатор, и доступ не разрешается. В результате шара становится недоступной для IIS сервера, хотя Windows SMB имеет доступ к шаре.

Выход из этой ситуации один, и он простейший. Надо при назначении виртуального каталога или шары, после написания основных параметров, нажать на кнопку: «Подключить как…». Откроется диалоговое окно, в котором нужно указать реальные имена пользователя и пароль учётной записи, которая имеет доступ к данному каталогу на сервере, а потом провести тест соединения. Идеально было бы подключить шару с правами локального администратора, но если эта учётная запись заблокирована или у неё нет пароля, можно использовать учётную запись обычного администратора или даже непривилегированную учётную запись, лишь бы у неё был пароль и она имела полный доступ к указанному каталогу. После этого проблемы благополучно уходят на второй план.

 

[[10.11.2017]]

Так и не удалось настроить ownCloud на виртуальной машине Windows Server. По неизвестной мне причине Windows Server продолжает блокировать порты с номерами больше 5999, а в моём случае запретил даже Ports Mapping. Пришлось установить гостевой сервер на ноутбуке, хотя мне этого делать крайне не хотелось.

[Эксплойт для восстановления удалённого доступа к домашнему серверу]

Также сегодня почти полностью готова версия административного эксплойта для восстановления удалённого доступа к домашним серверам. В текущей версии он не может быть использован для взлома сетей, поскольку:

  1. Должен запускаться на компьютере с полномочиями администратора;
  2. Требует открытого доступа к компьютеру через брандмауэр и NAT;

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

Сложность написания эксплойта для предоставления доступа к удалённому компьютеру, на котором общий доступ не был включён изначально, заключается в следующем:

  1. Необходимо пройти защитные механизмы в виде паролей на NAT/маршрутизатор, чтобы правильно сконфигурировать брандмауэр. Причём подбор пароля должен вестись непосредственно из внутренней локальной сети, поскольку по умолчанию удалённое управление маршрутизатором запрещено. Сами понимаете, что троян с полноценной системой брутфорса написать практически невозможно для целей скрытого внедрения;
  2. Необходимо знать пароль локального администратора или администратора домена, поскольку этого требуют многие программы удалённого администрирования. Брутфорс для таких целей возможен удалённо, но автору неизвестны программы брутфорса для службы удалённого RPC, единственно возможного для подключения в Windows без запуска других удалённых служб. Хотя алгоритм примитивный: подбирается пароль на локальном компьютере и с этими данными осуществляется попытка подключения к удалённому компьютеру. Ещё одна проблема в этом случае – на многих домашних компьютерах пароль локального администратора не установлен по умолчанию, а значит установление удалённого соединения с компьютером невозможно.

 

[[09.11.2017]]

[09.11.2017 11:59:17]

[VMWare Workstation Server: настройка доступа к консоли администратора]

[VMWare Workstation Server: настройка доступа к консоли администратора]

Та же проблема с входом наблюдалась и на ноутбуке. Пришлось вновь снести, с помощью geek uninstaller, и вновь поставить VMWare Workstation. Однако на этом дело не закончилось, и потребовались дополнительные шаги, а именно:

  1. После установки необходимо зайти на компьютер с учётной записью локального администратора или администратора домена (если он у Вас установлен). Некоторые важные настройки VMWare можно осуществить только под этой учётной записью.
  2. Запустить программу VMWare Workstation, и вызвать диалоговое окно настроек в меню Edit -> Preferencses…;
  3. В этом диалоговом окне, на вкладке Workplace необходимо изменить:
    • Расположение виртуальных машин по-умочанию: Default location of Virtual Machines. По-умолчанию они расположены в папке C:\Users\Администратор\Documents\Virtual Machines, что не всегда удобно, поскольку доступ к этой папке ограничен для всех пользователей, кроме локального администратора. Измените этот каталог на какой-нибудь другой, с обязательными правами полного доступа для групп «Администраторы» (локальные администраторы), «Администраторы домена» и «СИСТЕМА», остальные по усмотрению;
    • Установите Keep VMs Running after Workstation closed, если вы используете свой компьютер как сервер виртуальных машин. Эта опция означает, что компьютеры останутся работать даже после выхода из программы VMWare Workstation. Гостевые виртуальные машины тогда будут закрываться при выключении компьютера с сохранением внесённых изменений. Не устанавливайте этот параметр, если Вы используете VMWare Workstation только для тестирования операционных систем;
  4. На вкладке Updates снимите все галки, если Вы используете нелицензионную версию VMWare. В этом случае Вы не будете получать сообщения об обновлениях, которые для Вас нежелательны;
  5. На вкладке Devices установите галку Enable Virtual Printers, если хотите, чтобы поддерживалась печать из-под виртуальных машин. Дополнительно Вам на каждую машину потребуется установить поддержку принтера на вкладку «Устройства»;
  6. И, наконец, перейдём к самой важной настройке в этом окне. На вкладке Shared VMs Вам необходимо внести следующие изменения:
    • Нажать на кнопку Disable Sharing, если она у Вас есть;
    • Изменить порт, который слушает процесс VMWareHostd (сервис виртуальных машин). По умолчанию этот порт 443, но он конфликтует с большинством программ на компьютере. Для предотвращения коллизий этот порт нужно изменить, например, на 6443. Потом этот порт нужно будет открыть в брандмауэре;
    • Изменить местоположение Shared VMs Location для общих виртуальных машин. По умолчанию каталог этих виртуальных машин: «C:\Users\Public\Documents\Shared Virtual Machines». Соображения изменения этого каталога – запретить доступ к виртуальным машинам VMWare «кому ни попадя» и перестраховаться на случай переустановки операционных систем. Права доступа к новому каталогу должны быть такими же, как и в пункте 3;
  7. После этого нужно выйти из диалогового окна программы, нажав кнопку Ok, и перейти к настройкам прав доступа Shared VMs;
  8. Для этого надо щёлкнуть левой клавишей мыши на иконке Shared VMs, дождаться окончания подключения, если надо, введя регистрационные данные Windows для текущего пользователя;
  9. После этого нужно щёлкнуть правой клавишей на этой же иконке, и в контекстном меню выбрать пункт Permissions…;
  10. Пользоваться этим пунктом меню просто. Необходимо Кнопкой Add.. добавить нового пользователя или группу Windows для управления виртуальными машинами, далее щёлкнуть на его имени левой клавишей мыши и в правой части выбрать административную роль для пользователя. Назначать роль Administrator надо с осторожностью. Желательно добавить в это окно группу __wmware__ и добавить ей роль Create VM. Таким образом, пользователи этой группы смогут управлять созданием общих виртуальных машин, но не управлять другими пользователями. Ещё одно замечание: редактирование собственных полномочий текущим пользователем запрещено. Поэтому желательно в системе иметь двух администраторов VMWare, на случай блокировки суперпользователя Windows (не дай бог!). После настройки нажмите кнопку Ok;
  11. Затем нужно настроить правила брандмауэра Windows для разрешения доступа про сети к виртуальной машине. Должны быть разрешены следующие программы, сервисы и протоколы:

«C:\Program Files (x86)\VMware\VMware Workstation\vmware-hostd.exe»

«C:\Program Files (x86)\VMware\VMware Workstation\vmware-authd.exe»

«C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe»

«C:\Windows\SysWOW64\vmnat.exe»

«C:\Windows\SysWOW64\vmnetdhcp.exe»

Порт 6443 протокола TCP (или какой Вы там назначили в пункте 6);

  1. После чего можно войти в Windows как обычный пользователь и проверить работу VMWare Workstation. Система и гостевая машины должны работать. Помните, что открытие портов для работы в Интернете возможно только для общих гостевых виртуальных машин!

 

[[08.11.2017]]

[Не работает система запуска общих виртуальных машин VMWare: пути исправления]

До этого я обнаружил, что из Интернета не виден сервер UBUNTU-SRV ни на одном из протоколов, притом, что в локальной сети он прекрасно виден и работает. Проверка брандмауера показала, что он включён, порты сервера не блокируются нигде. Проброс портов также сделан нормально. Но программа portscan показывает, что его внешние порты не открыты. Автор догадался, что блокировка происходит брандмауэром хост-машины, причём сразу всех протоколов для VMWare. Однако добавление этой программы в список исключений брандмауэра ни к чему не привело, порты не открылись. Возможные причины этого:

  1. Указаны не те программы и службы (кроме собственно VMWare, запускается также много разных сопутствующих служб);
  2. У меня в настройках включены две сетевые карты, на адаптеры Bridget и NAT. Из-за этого возможен конфликт правил брандмауэра.

Завтра разберусь с этим, и напишу в блог.

[Не работает система запуска общих виртуальных машин VMWare: пути исправления]

Только что обнаружил, что на сервере «слетела» система запуска гостевых виртуальных машин VMWare. Вначале я грешил на то, что после удаления из сети домена ActiveDirectory у меня изменились права доступа к каталогам сервера. Но я вроде бы изменил права доступа на локальных пользователей для всех каталогов Windows. Но, зайдя в файл настроек авторизации общих виртуальных машин, я обнаружил, что авторизация происходит только от имени членов домена. Удаление настроек программы и переустановка VMWare в режиме восстановления не помогали – всё равно восстанавливалась конфигурация для домена. Оптимальный выход из этой ситуации – полная деинсталляция VMWare при помощи утилиты geek uninstaller. Эта утилиты не просто удаляет программу с диска, но и удаляет её следы, в виде оставшихся записей в реестре и папок с файлами конфигурации. В моём случае программа удалила дополнительно файлы из каталогов %USERPROFILE%\AppData\Local, %USERPROFILE%\AppData\Roaming, а также C:\Users\Public\Documents. Что программа не сделала – это не удалила ВАЖНЫЕ файлы конфигурации в каталоге C:\ProgramData. Это я сделал сам, залогинившись на сервере как локальный администратор. После этого система встала «как новенькая», и даже были исправлены ошибки, которые я связывал с работой операционной системы!

Естественно, перед переустановкой VMWare таким способом необходимо сохранить имеющиеся гостевые виртуальные машины от удаления. По-умолчанию виртуальные машины пользователя расположены в каталоге «%USERPROFILE%\Documents\…», а расшаренные виртуальные машины – в папке «C:\Users\Public\Documents\…». Программа geek uninstaller удаляет эти папки вместе со всем содержимым, так что сохранность виртуальных машин вы должны обеспечить самостоятельно.

 

[[07.11.2017]]

Сегодня переустанавливал Ubuntu Server на виртуальной машине. Потребность в переустановке возникла из-за того, что было неудобно запускать сервер, требующий расшифровки своего дискового пространства. Переустановка прошла быстро и успешно.

Дополнительно операционной системой на сервер были установлены:

  • LAMP;
  • Postmail Server;
  • OpenSSH сервер;
  • PostgreSQL;
  • phpmyadmin;
  • pgmyadmin;
  • Из сторонних репозиториев были загружены и установлены owncloud и webmin.

[PostgreSQL: полная переустановка в Ubuntu после краха]

Очень много проблем мне доставила настройка PostgreSQL, которую я, надо сказать, ещё не закончил. Дело в том, что по умолчанию в конфигурации блокируется доступ извне к PostgreSQL серверу для его суперпользователя postgres. Попытки создать нового пользователя с неограниченными правами терпят крах. Такой же крах вызывает установка доступа для этого пользователя со всех IP адресов. Притом это даже не крах, а пипец – система не запускается с ошибкой «Невозможно найти и инициализировать базу данных», при этом после переустановки пакета проблема не исчезает. Спасает только подача следующих команд:

apt-get --purge uninstall postgresql\*
userdel -r postgres
apt-get --purge install postgresql postgresql-contrib postgresql-doc

Только после них у меня сервер PostgreSQL приходит в исходное состояние, и нормально останавливается и перезапускается. Естественно, набор команд может дополняться, если вы ещё сильнее, чем я, загадили систему.

 

[[06.11.2017]]

[Сертификаты]

Занимался настройкой самоподписанных сертификатов. В результате написал небольшую программу на языке perl, которая помогает генерировать эти сертификаты при помощи инструмента openssl, проводя последовательно все операции от создания корневого сертификата до экспорта полученного сертификата в pks файл. При этом сертификаты можно генерировать с этим файлом конфигурации на любой машине, а не только на той, для которой генерируются сертификаты. Единственно, для генерации семейства сертификатов для каждого корневого сертификата необходимо заводить отдельный каталог со скриптами и настройками. Это неудобство получилось из-за того, что программа пока корректно не переключает имеющиеся файлы и шаблоны настройки openssl, а использует их в одном экземпляре для каталогов семейства.

При написании этой программы мне пришлось учитывать, при разработке файлов конфигурации opnsssl, следующее:

  1. При генерации корневых сертификатов мало предоставить корректную информацию. Если сертификат генерируется для компьютеров, имеющих доменное имя (FDQN), то в поле CN необходимо указывать не имя владельца сертификата, а именно FDQN;
  2. Если сертификат генерируется для домена, то нужно указать вместо FDQN каждого компьютера шаблон домена. Например, вместо FDQN «myserver.yudenisov.ru» указать «*.yudenisov.ru». В этом примере «myserver» – имя сервера в домене, для которого, в том числе, создаётся сертификат, «yudenisov.ru» – доменное имя, зарегистрированное за сетью.
  3. Указанное в FDQN доменное имя не обязательно должно быть зарегистрировано на регистраторе доменных имён. И даже необязательно оно должно быть зарегистрировано в качестве домена Active Directory. Достаточно, чтобы домен был прописан на всех DNS серверах, можно даже локальных и «левых», использующих его. Сертификат применяется по самому факту нахождения данного компьютера по FDQN, а полномочия сервиса, выдавшего FDQN, не проверяются. Поскольку на одну машину можно завести практически неограниченное число FDQN, то для каждого такого домена в нём можно выписать сертификат. Это является ещё одним способом обойти контроль в Интернете путём тотальной сертификации, просто нужно создать новый FDQN и привязать к нему сертификат (необязательно самоподписанный, если Вы сумеете обмануть сервис сертификации). По идее, таким образом можно подделать банковские транзакции, но этого делать я никому не советую!
  4. При генерации корневых сертификатов необходимо в качестве назначения сертификата указать в назначении сертификата «Все», а именно: «server, client, email, object». Это означает, что данный сертификат может использоваться для идентификации сервера и клиента при установлении ssl соединения, в качестве цифровой подписи писем в openPGP, для подписи различных объектов в операционной системе. Сертификаты, генерируемые отдельными программами или экосистемой Windows, поддерживают только один тип назначения, из-за чего возможна коллизия при установке соединения. Поэтому совет – все сертификаты генерировать только в моей программе или её модификациях.
  5. При создании же обычных сертификатов в качестве его назначения, наоборот, необходимо указывать только одно из его назначений. Некоторые программы блокируют сертификаты со слишком широкими полномочиями. Но для генерации таких сертификатов необходимо вручную изменить файлы конфигурации, сгенерированные программой. Она ещё не умеет сохранять настройки для всех сертификатов;
  6. Сгенерированные сертификаты в Windows необходимо экспортировать:
    • корневые сертификаты – в места «Доверенные корневые центры сертификации» и «Доверенные издатели корневых сертификатов»;
    • самоподписанные сертификаты – в место «Личные сертификаты»;
  7. Экспортировать сертификаты в Windows необходимо в формате pfx/psk, чтобы они содержали и открытый, и закрытый ключи. При импорте сертификатов для сторонних приложений необходимо указывать по отдельности открытый «*.cer» и закрытый «*.key» ключи;
  8. В принципе, в Интернете есть сервисы, которые бесплатно заверяют самоподписанные сертификаты, чтобы к ним было доверие из Интернета, на 3 месяца. Но автор ещё не пользовался такими сервисами.

Эксперименты с сертификатами автор обязательно продолжит.

Posted in IT

Добавить комментарий