athacker

Плюсую предыдущих ораторов. Встряли вы конкретно, и своими силами не управиться, привлекайте серьёзных интеграторов для решения. И готовьте денег, конечно -- на оплату их услуг, на новое оборудование.

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

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

Вот неплохие переводы двух CIS-овских регламентов, начинайте внедрять:

https://habrahabr.ru/company/pentestit/blog/338532/
https://habrahabr.ru/company/pentestit/blog/339206/

Хотя, если у вас сервак один, и расширение не планируется, можете свой 580-ый дисками набить и на них виртуалки размещать.

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

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

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

P/S/: https://www.1c-bitrix.ru/products/cms/security/aud...

Якобы, аудит приложения регулярно выполняет Positive Technologies.

Максимум анонимности в сети -- это не ходить в сеть вообще.

Опишите полностью, чего вы хотите достичь и при каких условиях. А то ваш вопрос мало чем отличается от пресловутого "подземного стука".

Очень даже подходящий инструмент.

Как гласит народная мудрость, "S" в аббревиатуре IoT обозначает "безопасность". Вы видите там "S"? Вот и я нет :-)

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

В данном случае, антивирус у вас лечит последствия -- бинарник с рабочей нагрузкой. А дроппер либо висит в памяти и не оставляет следов, либо проламывается сквозь непропатченную дыру в системе с какой-либо другой машины в сети (или в интернете). Выводите сервак в оффлайн, грузитесь с какого-нибудь liveCD и проверяйте диски, желательно несколькими инструментами -- AVZ, DrWeb CureIT, ещё что-нибудь.

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

Наверное, это потому, что RDP и WinRM -- это малость разные протоколы для разных служб? ;-)

Для изучения "полностью всех сетевых нюансов" вам нужны специализированные железки с их ОС -- Cisco или Juniper.

А так -- вы сможете изучить НЕКОТОРОЕ КОЛИЧЕСТВО сетевых настроек ДЛЯ КОНКРЕТНОЙ ОС, не более того.

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

Энторнеты-то вообще с сервера доступны? ping mxs.mail.ru проходит?

Камрад nexthop 100% прав -- проблема не в терминале, а в кривых руках том, что Thin падает. Курите логи на предмет причин падения.

Для разрешения имён может работать целая цепочка DNS-серверов. Сервера делятся на два типа: "авторитетные" (authoritative) и кэширующие/рекурсивные. Первые -- обслуживают запросы только к тем доменам, владельцами которых являются они сами. Все остальные запросы игнорируют.

Вторые сами никаких доменов не обслуживают, но отвечают на запросы пользователей и опрашивают сервера первого типа до тех пор, пока не получат какой-то ответ (IP-адрес или ответ, что такого домена не существует).

Вот вторых может быть целая цепочка. Начиная с DNS-сервера, встроенного в роутер, затем могут быть DNS-сервера провайдера, которые уже начинают опрос с корневых серверов (которые отвечают за зоны первого уровня типа .ru, .com, и т. п.). В ответ на запрос домена к корневому серверу он отвечает списком адресов тех DNS-серверов, которые что-то знают про зону второго уровня (такие как yandex.ru, google.com, freebsd.org и т. п.). После этого резолвер опрашивает DNS-сервера, отвечающие за соответствующу зону второго уровня. В ответ (чаще всего) получит ответ с IP-адресом или ошибку, если запрошено несуществующее имя. Но могут быть и DNS-сервера 3-го уровня (обслуживающие зоны типа somesite.google.com, anothersite.yandex.ru и т. п.). Тогда резолвер будет делать ещё один запрос, уже к этим DNS-серверам. Ну, и так далее.

А где географически стоят физические сервера -- корневые сервера стоят в крупных датацентрах или на площадках организаций-регуляторов интернета.

DNS-сервера второго уровня -- чаще всего это датацентры сервис-провайдеров, хостеров или компаний, которым данное доменное имя принадлежит.

Если это промышленная СХД, то скорее всего, придётся использовать ту утилиту, которая предоставляется вендором. Кроме того, в любой СХД есть в интерфейсе простенький мониторинг, который покажет в реальном времени все эти параметры. История данных там обычно от 5 минут до максимум 1 часа хранится (по крайней мере, на тех СХД, с которыми я работал).

Если же вы хотите эти данные в свой мониторинг куда-то тянуть, с возможностью задавать триггеры и события на основе триггеров, то в случае промышленных СХД вас ждут боль и унижения, так как по SNMP они эту информацию не отдают. Либо будет какой-то вендорский продукт мониторинга отдавать (но не все это делают), либо с помощью лома и такой-то матери (парсить файлы со статистикой, как это, например, пришлось делать на IBM Storwize v7000), либо снимать загрузку непосредственно с тех потребителей (серверов), которые подключены к СХД и пользуются её дисками. Но в последнем случае, как вы понимаете, не будет общей картины, так как каждый хост получает свою часть ресурсов и генерит разную нагрузку.

В описании фигурирует классический криптоконтейнер. Знаешь пароль -- можешь его смонтировать и получить доступ к файлам. Не знаешь -- гуляешь мимо.

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