athacker

Может, достаточно будет джумлу обновить? :-) Виртуальные сервера стоят от 100 рублей в месяц, переезжайте на VPS и там будете ставить тот софт и тех версий, какие посчитаете нужным.

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

Отсюда, в частности, следует, что на рабочих станциях документов быть не должно. Никаких. Ни при каких условиях. Вся рабочая информация -- только на серверах. И бэкапятся только сервера. Рабочие станции -- это расходники, сломалась -- выкинул и новую поставил. Потом из трёх сломаных рабочих станций можно в свободное время собрать одну, например, но ценных данных там быть не должно. Кто хранит документа на локальном диске -- того вывести в чисто поле, поставить лицом к стенке и пустить пулю в лоб, чтобы на всю жизнь запомнил к директору на ковёр, с объяснительной на тему "почему подвергает риску данные компании".

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

Не очень понял, почему вам RDP не очень помогает. Может, вы его готовите неправильно?

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

Доступ в интернет -- в идеале только по паспорту через прокси. С обязательным ведением логов -- кто, куда и зачем. Сквид умеет в доменную аутентификацию, поэтому даже пароль при доступе через прокси вводить не придётся. Ну, понастраивать придётся, конечно, сначала.

Звучит как бред :-)

Зачем виндовому файрволу какой-то "агент", когда настройками файрвола можно через групповые политики рулить? И что за "команды" должны поступать от "системы защиты"?

"Политика безопасности" -- это слегка не в компетенциях файрвола находится, поэтому как он может фиксировать её нарушения -- тайна сие есть, покрытая неизвестным мраком.

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

Ну так и отдайте гипервизорам прямо по iSCSI этот LUN. Они, как правило, сами разбираются. ESXi, Hyper-V, KVM сами понимают, что если iSCSI storage, то они на этом луне не одни, и работают соответственно.

Либо, если вам нужно ещё и сами файлы виртуалок зачем-то глазками просматривать -- раздайте датастор по NFS.

Да, это правильный подход. Создать учётку локального администратора в процессе установки, потом зайти под ним и создать локального пользователя, а под ним уже делать все остальные действия (включая установку софта). Когда вы залогинены обычным юзером, то при необходимости воспользоваться админскими правами UAC у вас запросит повышение привилегий и админский пароль. Я так делаю уже очень давно, и в повседневной жизни (когда всё уже установлено/настроено) мне админские права на компе требуются дай бог раз в месяц. Так что работаю локальным юзером, а если что -- UAC спросит админский пароль.

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

Логика правильная. Номера вланов значения не имеют, но выделять однотипные устройства в отдельные сети -- это правильно и хорошо. Связность между вланами обеспечивается также, как и между отдельными физическими сетями -- с помощью маршрутизатора. Почитайте, что такое VLAN trunking, и ознакомьтесь, как это реализуется на микротиках, и настраивайте маршрутизацию на нём.

Сегментация сети -- это не просто правила хорошего тона, это необходимость, особенно в свете развития малвари/вирусов и прочих угроз ИБ. Принтеры/телефоны -- легко уязвимые устройства, поэтому их нужно изолировать. Плоская сеть, где все компы организации находятся в одном влане/сетевом сегменте приведёт к тому, что любой залётный NotPetya распространится по всей сети в считанные минуты. И будет как здесь. Или мамкины хакеры какие-нибудь начнут ковырять компы соседнего отдела по сети. Так что сгементация и настроенные правила хождения трафика между подсетями -- это must have в современных условиях.

В случае с gmirror -- нет, расширить RAID не удастся. Нет такого функционала. Только бэкап всех данных, потом разбивка массива в RAID10, потом возврат всех данных из бэкапа.

Можно перейти на ZFS, там можно расширять ZMIRROR, добавляя зеркала.

Нет, неправильно.

Часть законов, которыми пытаются регулировать интернет в последнее время -- это бред и дурь, конечно. Например, закон Яровой -- это полный трэш. Он нереализуем технически.

А вот закон, который ограничивает иностранных участников во владении магистральными точками обмена трафика на территории РФ, или закон, который призван обеспечить маршрутизацию локального трафика только через сети РФ -- с точки зрения управления рисками вполне оправданы, в текущей политической обстановке. И речь даже не только про изоляцию, а ещё и про то возможность контроля трансграничного трафика. Ландшафт угроз сейчас такой, что это технически сложная, но необходимая мера. И в той или иной степени, этим занимаются все государства, в меру наличия технических/финансовых стредств для этого. Контроль не на предмет "лайков и репостов", а на предмет реальных угроз для критической информационной инфраструктуры (см. 187-ФЗ).

Другой вопрос, что реализация может быть кривая, ну и как любой инструмент, этот закон может быть использован и во зло. Равно как и молотком -- можно по башке кого-нибудь приложить. Но вообще-то это инструмент для строительства.

Даже закон, дающий РКН право блокировать ресурсы -- тоже скорее полезен, нежели вреден. Потому что 99.999% списка блокировок -- это сайты с продажей наркоты, притоны, бордели и онлайн-казино. Политики там -- тысячные доли процента. Да, реализация блокировок хромает на обе ноги. Да, методика внесения в списки и особенно удаления из списков -- хромает ещё сильнее. Но в целом -- инструмент нужен, просто нужно было хорошенько продумать все механизмы и методику, прежде чем запускать всё в дело. У нас, к сожалению, часто начинают с принятия закона и запуска его в действие, а потом -- "авось как-нибудь оно само всё обустроится".

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

1) Контроль пиринга. Часто провайдеры не в состоянии договориться о прямом обмене трафиком между своими абонентами. И тогда реально получается, что трафик из одного офиса Москвы в другой ходит через AMS-IX, например. Чаще всего причиной недостижимости договорённости является жадность :-)

2) Создать автономну DNS-инфраструктуру. Сейчас проблема частично решена, т. к. на территории РФ есть корневые NS-сервера.

3) Иметь свои удостоверяющие центры для реализации PKI. Сейчас в России можно создать PKI, но никто из вендоров ПО не будет его добавлять в списки доверенных. Но можно в законе предусмотреть такое требование. И тогда, опираясь на этот закон, можно будет прессовать вендоров, мотивируя это тем, что "хотите вести бизнес в России -- будьте добры расширить список доверенных УЦ". Ну а со временем этот УЦ попадёт во все такого рода списки, в том числе и зарубежом. В текущей же ситуации, если каким-то образом будет нарушен доступ к серверам зарубежных УЦ (Comodo, Let's Encrypt, DigiCert. Thawte), то проблем у информационных систем внутри РФ возникнет немало, т. к. куча сервисов просто перестанут работать из-за невозможности проверить валидность сертификатов.

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

Потеря в какой конкретно производительности? CPU? Дисков? работы с RAM? Работы сетью?

Какой профиль нагрузки?

Ну и опять-таки, если чистую винду поставить возможности всё равно нет, то какая разница? :-)

В информационной безопасности множество направлений. Выбор курсов сильно зависит от того, чем конкретно вы хотите заниматься. Аудит/пентест -- это одно, инженер ИБ -- другое, архитектор/infosec manager -- третье.

1) фольгированная витая пара -- только между этажами. С обязательным заземлением, иначе толку от неё не будет. В остальном можно разводить обычной UTP без экранирования;

2) Коммутаторы должны быть на каждом этаже. Не хватает 16 портов -- ставьте 24-портовые. Не хватает 24-портовых -- ставьте по 48. Но реально жить будет проще, если у вас коммутаторы доступа будут стоять на каждом этаже. Потому что тогда вам можно будет купить менее ёмкие коммутаторы агрегации и поставить их в серверной. Менее ёмкие -- потому что туда не все на свете компы будут сведены, а только коммутаторы доступа. Подключение каждого коммутатора доступа к агрегации -- двумя линками, в ether-channel, для резервирования;

3) Citrix XenServer... Ну такое... Посмотрите на картинку и найдите там XenServer:


4) "SSD в рейд-массивах не дает преимуществ" -- шта? О_о Собирать SSD в RAID10 -- несколько расточительно. Хотя, конечно, если у вас бюджеты не ограничены... Я бы собирал массив так -- как можно бОльшее количество дисков небольшого объёма, которые бы уже собирал в RAID6 или RAID60 (в зависимости от количества дисков и потребных объёмов). Вот шпиндельные диски -- их имеет смысл в RAID10 собирать, т. к. больно медленные. Но подход тот же самый -- диски меньшего объёма, но в большем количестве. В последние годы я постоянно наблюдаю ситуации -- есть до фига объёмов, но не хватает производительности. Обратное -- производительность есть, но мало объёмов, пока не попадалось. Отсюда рекомендация брать диски поменьше, но количеством побольше. Хотя всё зависит от задач, конечно. И от бюджетов.

Да, и "RAID-массив в стойку" не поставить. Поставить можно железку. Какую-то. Промышленную СХД, например. Или самосборное хранилище (считай, обычный сервер, с линукс или FreeBSD на борту, настроенный на отдачу объёмов по какому-то storage-протоколу). Или корзину DAS. Или NAS. Перечислены в порядке предпочтения. Опять-таки, всё зависит от бюджета.

5) ИБП нужно брать с запасом не 50%, а 100% или даже 200%. Потому что когда вы докинете ещё серверов, то ваши 50% будут съедены моментом. Или когда у вас нагрузка поднимется, то тоже начнёте упираться в потолок мощности ИБП. А то, что нагрузка будет расти и сервера придётся добавлять -- это к бабке не ходи. Поэтому брать нужно с большим запасом, не менее 100%. Как вариант -- брать ИБП, к которым можно подключать внешние блоки батарей. Но мощность ИБП всё равно должен иметь с запасом не менее 100%.

6) Датчики влажности, температуры без регистрации и SMS и возможность отправки SMS-сообщений лучше реализовать с помощью устройств типа UniPing server v3/SMS. Датчиков там отдельно можно докупить всеразличных, вплоть до инфракрасных управлялок для кондиционеров в серверной.

7) RAID-ы в виртуалках -- это бред, конечно же. Достаточно обеспечить отказоусточивое дисковое хранилище. Лучше всего с отказоустойчивостью дела обстоят у промышленных СХД, конечно же. HPE MSA, Dell MF -- вот это вот всё.

8) Правила распределения сервисов по виртуалкам очень простое -- один выстрел -- один труп сервис -- одна машина. Т. е. под почтовый сервер -- одна виртуалка. Под DNS -- ещё машина. Даже две. Под контроллеры доменов -- две виртуалки (минимум). Под DHCP -- ещё машина.

XXX) Если заказчик хочет, чтобы всё работало хорошо -- то лучше, конечно, пригласить профессионалов. Потому как судя по вашим вопросам, вы пока ещё таковым не являетесь. Если же он готов терпеть и пожинать плоды экспериментов в течение довольно долгого времени -- тогда конечно.

XXX+1) Да, и про резервное копирование не забудьте. Чем бэкапить, и куда складывать. Hint: складывать на ту же хранилку, на которой виртуалки работают -- моветон и чревато печальными последствиями.

Ну у вас не СХД, а DAS.

В теории должно работать, но нужно смотреть HCL от хранилки, поддерживается ли этот контроллер. Если есть возможность попробовать -- надо пробовать, т. к. даже если контроллера нет в HCL, это не значит, что связка не будет работать.

Что касается дисков -- то тут тоже только смелый эксперимент. Т. к. в СХД обычные диски не работают -- обычно хранилки проверяют прошивки дисков и бракуют диски, которые не прошиты вендором. Т. к. именно в СХД работали бы диски только маркированные вендором. Как будет в случае с DAS -- ХЗ, только натурные испытания.

Как первую unix-like систему -- да, имеет смысл осваивать фряху. Там порядка куда как больше, чем в линуксе, с его разнообразием костылей дистрибутивов и подходов к построению ОС. Как сказал один умный товарищ -- "BSD-шник сможет освоить с линукс без проблем, а вот линуксоид с BSD -- вряд ли".

В целом, несмотря на меньшую популярность, на фряхе довольно много инсталляций. Многие интернет-провайдеры используют (ну, кроме большой четвёрки), да и в крупных конторах она тоже есть. Самосборные storage-системы строятся на фряхе часто, т. к. связка ZFS + ctld -- это прям агонь.

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

Софта под фряху меньше -- ну, отчасти да. Ceph, например, на фре вы не запустите. Но это довольно специфический такой софт, а всё остальное общеупотребимое -- вполне есть и отлично работает. Любые общеупотребимые сетевые сервисы на фре поднимаются без проблем. DNS/DHCP/почта/web/базы данных-- вот это вот всё.

С астериском под BSD не помню никаких проблем, всё работало.

IPsec под FreeBSD работает, у меня туннель уже пару лет между фряхой и микротиком постоянно поднят.

Про то, что команда разработки FreeBSD сокращается -- это неправда.

Начать с разъяснительной работы, что хранение документов на локальных дисках рабочих станций -- есть зло и большой риск для документа, т. к. железо рабочих станций по определению ненадёжно, а документы, хранящиеся на рабочей станции трудно бэкапить. Заручиться поддержкой руководства в последующих действиях

Затем берём сотрудников по очереди, уточняем, где на их компе лежат рабочие документы, переносим их на сервер и отрубаем службу Server на рабочей станции, для исключения возможности делиться документами по сети напрямую между рабочими станциями.

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