none
Странный взлом Exchange 2013 ... RRS feed

  • Вопрос

  • Сегодня рано утром начали звонить пользователи - не работает OWA. При этом с мобильных ещё работает.

    Залезаю из дома через VPN и Удалённый рабочий стол на почтовик - при попытке зайти в Административный центр - грузится IE и говорит, что сайт недоступен. При попытке закрыть его вылезает снова. Сбрасываю процесс через Диспетчер задач.

    Дальше-больше - пробую перезагрузить целиком - сервер говорит, что не может найти системный диск (MBR у меня пока) !!! Пришлось грузиться с флэшки WinSrv2008R2 и восстанавливать вчерашний образ целиком !

    Вопрос: что это было и как защититься в будущем ?


    =STAS=

    • Изменено -STAS- 10 июля 2018 г. 12:46
    10 июля 2018 г. 12:45

Ответы

  • По мне дак это точно никакой не взлом. С чего вы взяли, что ваш сервер взломали?

    Наиболее вероятная причина - проблемы с диском. Вы диск проверили? Загрузочную область отдельно пробовали восстанавливать перед накатом всего образа?

    10 июля 2018 г. 13:01
  • Егор, объясните мне, недалёкому человеку, каким образом в RAID можно получить ошибку загрузочного сектора диска ? Если это "ошибка железа" - одного из дисков - идёт рассинхронизация RAID, к примеру, это видно в управляющей утилите RAID - автоматом идёт перестроение. Если RAID гавкнет совсем, тогда вообще ничего не будет - в БИОС состояние RAID = ОК.

    Ответ - только софт. Но из софта только голый Windows Server 2008 R2 и Exchange Server 2013 строго. Больше ничего абсолютно нет.

    КАК ? Я вижу только одно - проникновение в систему. И, скорее всего, через OWA.


    =STAS=

    Последовательность рассуждений не верная.

    Во-первых, рейд не уменьшает до нуля вероятность повреждения данных, он её лишь снижает. 

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

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

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

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

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

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



    20 июля 2018 г. 16:54

Все ответы

  • По мне дак это точно никакой не взлом. С чего вы взяли, что ваш сервер взломали?

    Наиболее вероятная причина - проблемы с диском. Вы диск проверили? Загрузочную область отдельно пробовали восстанавливать перед накатом всего образа?

    10 июля 2018 г. 13:01
  • Системный диск (2 шт) на RSTe RAID в зеркале. Он в порядке. Восстановление загрузочной области с флэшки не дало результата. Я даже больше могу сказать - поначалу, до перезагрузки, попытался восстановить состояние системы из-под Windows его же средствами, поставил галку "Перезагрузить по завершении". После чего он и не нашёл системного диска.

    =STAS=

    • Изменено -STAS- 10 июля 2018 г. 13:36
    10 июля 2018 г. 13:14
  • Егор, объясните мне, недалёкому человеку, каким образом в RAID можно получить ошибку загрузочного сектора диска ? Если это "ошибка железа" - одного из дисков - идёт рассинхронизация RAID, к примеру, это видно в управляющей утилите RAID - автоматом идёт перестроение. Если RAID гавкнет совсем, тогда вообще ничего не будет - в БИОС состояние RAID = ОК.

    Ответ - только софт. Но из софта только голый Windows Server 2008 R2 и Exchange Server 2013 строго. Больше ничего абсолютно нет.

    КАК ? Я вижу только одно - проникновение в систему. И, скорее всего, через OWA.


    =STAS=

    20 июля 2018 г. 15:41
  • Егор, объясните мне, недалёкому человеку, каким образом в RAID можно получить ошибку загрузочного сектора диска ? Если это "ошибка железа" - одного из дисков - идёт рассинхронизация RAID, к примеру, это видно в управляющей утилите RAID - автоматом идёт перестроение. Если RAID гавкнет совсем, тогда вообще ничего не будет - в БИОС состояние RAID = ОК.

    Ответ - только софт. Но из софта только голый Windows Server 2008 R2 и Exchange Server 2013 строго. Больше ничего абсолютно нет.

    КАК ? Я вижу только одно - проникновение в систему. И, скорее всего, через OWA.


    =STAS=

    Последовательность рассуждений не верная.

    Во-первых, рейд не уменьшает до нуля вероятность повреждения данных, он её лишь снижает. 

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

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

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

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

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

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



    20 июля 2018 г. 16:54
  • В итоге на чем все у вас закончилось? 
    23 июля 2018 г. 19:32
  • Очень напомнило историю с файловым сервером по совместительству 1С, произошедшую более десяти лет назад.

    У него упал загрузчик, и утро того дня выдалось веселым. Чтобы не получить по заднице, администратор выдал теорию что "нас взломали через VPN", поскольку больше ничего интересного в голову не пришло. Ну, и аббревиатура страшная и начальству малопонятная, все сразу покивали головами, и сказали, да, конечно. Хотя точно также, гипотеза его была абсолютно оторванной от реальности (не буду повторять на свой лад слова Егора выше, согласен здесь целиком), и из-за того, что внешних врагов искать выгодней и проще, чем внутренних, инцидент быстро забыли.

    24 июля 2018 г. 7:22
  • Да ничем ...

    Перед недельным отпуском купили роутер, поставил его перед почтовиком, закрыл абсолютно все порты, кроме необходимых для работы Exchange. Вроде ненелю отработал нормально - тьфу-тьфу, в воскресенье - то же самое опять. На этот раз ни через RDP, ни даже через TeamViewer зайти не удалось. Локально присутствовать не смог в этот раз. Хотя почтовик пинговался и работал OWA, но Outlook соединиться не мог ни у кого из пользователей). В итоге пустил на перезагрузку через shutdown /m \\mail.domain.local /r /t 0 - долго думал (минут 10), потом всё-таки пинг пропал и тишина. Приехав локально на следующий день в офис, обнаружил опять то же самое - не найден системный диск. Восстановил загрузкой с флэшки и закаткой образа системного диска.

    Возможно (всего лишь предположение), что проблема в связке RSTe драйверов и BIOS. Мать интел, проверил на сайте - всё последнее - и BIOS, и драйвера. Попробую откатить драйвера назад. Может быть, поможет. Уж и не знаю, куда копать ... и поведение-таки странное для ошибки железа ...


    =STAS=

    • Изменено -STAS- 30 июля 2018 г. 14:41
    30 июля 2018 г. 14:40
  • Я такие дешёвые приёмы не использую, работаю честно. Что знаю-знаю, нет - честно говорю, что не знаю причину ... как и в данном случае ...

    =STAS=

    30 июля 2018 г. 14:44
  • Что было с сервером до возникновения проблемы? Что было по нагрузке на ЦП, диски, оперативку? Насколько интенсивно использовался своп?

    Исключить проблемы с железом очень просто - переехать на новое, хотя бы временно.

    30 июля 2018 г. 14:50
  • как раз ничего странного в ошибке железа... вариантов масса - от проблем с батареей на матери, с батареей на контроллере RAID (если она есть на конкретном контроллере) до банально осыпающихся хардов.

    и если случай уже не единичный - железо в тесты по полной программе.

    30 июля 2018 г. 14:53
  • Кстати, вы так и не сказали модели дисков и контроллера...

    А это бы могло помочь в диагностике проблемы.

    30 июля 2018 г. 14:59
  • Да много чего было - всего и не упомнишь. Ну вот как раз драйвера RSTe обновлял, к примеру. BIOS тоже обновлял. HDD менял на SSD, потом SSD менял на SSD большего размера. Свопит мало - 32ГБ оперативки на борту, занята половина примерно. Где ж его взять, новое-то железо.

    =STAS=

    • Изменено -STAS- 30 июля 2018 г. 15:08
    30 июля 2018 г. 15:07
  • Мать: Intel Server Board S1200V3RPS, 2 диска Intel SSDSC2BB240G7 в зеркальном софтовом RAID Intel RSTe, встроенном в BIOS. Проверки RAID там нет - только если система сама поймёт, что у неё что-то не клеится. Есть проверка RAID из-под Windows Server, но у неё всё окей как всегда, никаких признаков.

    Intel RSTe BIOS ver: 4.1.0.1026
    Windows iaStorA drivers: 4.3.0.1198


    =STAS=

    30 июля 2018 г. 15:14
  • Тогда бы на матери слетело и время и настройки ... На контроллере RAID батареи нет - RAID софтовый, встроенный в BIOS на материнской плате.

    =STAS=

    30 июля 2018 г. 15:16
  • На контроллере RAID батареи нет - RAID софтовый, встроенный в BIOS на материнской плате.

    =STAS=

    В этом вероятно и проблема. Со встроенными в материнку рейдами всегда косяки, к тому же у них никаких адекватных средств диагностики. Я уж молчу насколько сильно встроенный контроллер режет производительность
    30 июля 2018 г. 16:28
  • чем такой RAID лучше никакого - проблем меньше и производительность не жрет, плюс потенциальные баги в драйверах и обновлениях... IMHO

    честно говоря не отважился бы такую конфигурацию выставлять в продуктивную среду.

    31 июля 2018 г. 6:51
  • В общем, сегодня попробую откатить драйвера к самым первым, которые вроде работали ок (правда тогда биос ещё не был обновлён). Посмотрим, что получится.

    =STAS=

    31 июля 2018 г. 9:14
  • тоже думал уже в этом ключе ... но как-то совсем без рейда ... кхм ... непривычно ... блин, был же нормальный Matrox RAID на десктопных мамах ... простой, неглючный ... нет, интелу надо было сделать энтерпрайз едишн (RSTe) - и понеслась ...

    =STAS=

    • Изменено -STAS- 31 июля 2018 г. 9:17
    31 июля 2018 г. 9:15
  • если на обязательном RAID свет клином сошелся, кто вам мешает докупить на серверную мать нормальный контроллер и уже на нем собрать зеркало? благо не такие уж большие это деньги...
    31 июля 2018 г. 10:53
  • например ?

    =STAS=

    1 августа 2018 г. 15:57
  • google в помощь. начните с LSI например... на вкус и цвет - фломастеры разные ;)
    2 августа 2018 г. 7:37