MS
Сколько ставил кумулятивы 2013/2016 - никогда ничего не ломалось. Что-то не так наверно делал 😁
Наверное
Size: a a a
2020 March 01
SB
А вот когда ставил обновки на Винду раз в полтора года - в двух из трёх случаев что-то не то вылазило
VG
Сколько ставил кумулятивы 2013/2016 - никогда ничего не ломалось. Что-то не так наверно делал 😁
Неудачники мы с тобой. Всем спок ночи)
NS
Удалённое выполнение кода на серверах MS Exchange. Патч от этой уязвимости только вышел, а обновлять exchange сервера не всегда все торопятся по ряду причин...
Уязвимость может быть эксплуатирована специальным письмом, в частности уязвимость обнаружена в компоненте управления Exchange (ECP)
PoC + видеодемонстрация:
https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
Уязвимость может быть эксплуатирована специальным письмом, в частности уязвимость обнаружена в компоненте управления Exchange (ECP)
PoC + видеодемонстрация:
https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
NS
SB
Боян. Уже пару недель как патч выпущен
NS
Ну тогда хорошо
NS
Доброй ночи, господа
2020 March 02
EV
Удалённое выполнение кода на серверах MS Exchange. Патч от этой уязвимости только вышел, а обновлять exchange сервера не всегда все торопятся по ряду причин...
Уязвимость может быть эксплуатирована специальным письмом, в частности уязвимость обнаружена в компоненте управления Exchange (ECP)
PoC + видеодемонстрация:
https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
Уязвимость может быть эксплуатирована специальным письмом, в частности уязвимость обнаружена в компоненте управления Exchange (ECP)
PoC + видеодемонстрация:
https://www.zerodayinitiative.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys
Почему пишут про некий email, если эксплуатация строго через cas сервисы??
II
Почему пишут про некий email, если эксплуатация строго через cas сервисы??
Там две уязвимости в феврале закрыли, одна рсе через письмо, а через евс эскалация привелегий
R
Боян. Уже пару недель как патч выпущен
а какой патч ?
EV
Там две уязвимости в феврале закрыли, одна рсе через письмо, а через евс эскалация привелегий
А через письмо-то как? Совершенно непонятно, но почитаю.
J
А теперь представляем, что все так делают и делаем выводы 😞
вроде как убрать публикацию ecp поможет делу, не? по крайней мере до апдейта запланированного убрал) благо в 19 не страшно
EV
Сетап по кейсу.
Дано:
Сайт А, большой.
Прописан совершенно корректный cas array объект, назовем ARRAY1
fqdn поле внутреннее, вида cas01.domain.local, направлено на 2 CAS сервера.
все работает, rpc/tcp держит хорошо
Еще есть объект cas array, оставшийся давно от другого сайта
fqdn поле совпадает с внешним, mail.domain.com, назовем ARRAY2
внутри резолвится в балансер, который передает на те же 2 корректных CAS сервера сайта А
но балансер не умеет хорошо держать RPC/TCP нагрузку
Проблема:
в результате непредумышленных действий все немного сломалось
в спешке прописали в поле SITE для ARRAY2 сайт А (обнулив поле сайт в ARRAY1 конечно же) и добавили ARRAY2 для баз сайта А
из неудобств в процессе не было проблем с пересозданием профилей
просто аутлуки долго висели в статусе 'невозможно открыть папки набора данных', стандартно все.
Вопрос:
как гарантированно корректно вернуть для баз сайта А cas array указывающий на имя cas01.domain.local,?
Вижу как минимум два решения:
- первое (с виду плохое), сделать обратно.
обнулить сайт в ARRAY2, вписать его в ARRAY1 как было, шустро прописать вручную базам ARRAY1
- второе, с виду более адекватное - просто поменять в текущем рабочем конфиге
поле fqdn в ARRAY2, направив его на cas01.domain.local, как и было до кейса.
не придется ли вручную менять для баз? так как непонятно, по какому полю реально идет привязка
name (не изменится), fqdn (изменится)
Дано:
Сайт А, большой.
Прописан совершенно корректный cas array объект, назовем ARRAY1
fqdn поле внутреннее, вида cas01.domain.local, направлено на 2 CAS сервера.
все работает, rpc/tcp держит хорошо
Еще есть объект cas array, оставшийся давно от другого сайта
fqdn поле совпадает с внешним, mail.domain.com, назовем ARRAY2
внутри резолвится в балансер, который передает на те же 2 корректных CAS сервера сайта А
но балансер не умеет хорошо держать RPC/TCP нагрузку
Проблема:
в результате непредумышленных действий все немного сломалось
в спешке прописали в поле SITE для ARRAY2 сайт А (обнулив поле сайт в ARRAY1 конечно же) и добавили ARRAY2 для баз сайта А
из неудобств в процессе не было проблем с пересозданием профилей
просто аутлуки долго висели в статусе 'невозможно открыть папки набора данных', стандартно все.
Вопрос:
как гарантированно корректно вернуть для баз сайта А cas array указывающий на имя cas01.domain.local,?
Вижу как минимум два решения:
- первое (с виду плохое), сделать обратно.
обнулить сайт в ARRAY2, вписать его в ARRAY1 как было, шустро прописать вручную базам ARRAY1
- второе, с виду более адекватное - просто поменять в текущем рабочем конфиге
поле fqdn в ARRAY2, направив его на cas01.domain.local, как и было до кейса.
не придется ли вручную менять для баз? так как непонятно, по какому полю реально идет привязка
name (не изменится), fqdn (изменится)
Кому интересны кишочки легаси, то вот немного проанализировали.
А причина вкратце была такая.
1. Список массивов
A
B
C
..
X
Y
Z
2. Был удален сайт AD /без серверов /без клиентов /без всего,
но указанный например для массива C
3. Как оказалось, архитектура Exchange в данном случае
просто прекращает работать для ВСЕХ массивов после С
т.е. поймали мы самый большой сайт, в остальных я думаю аналогично.
Даже get-casarray * завершится в консоли ошибкой Watson как раз после массива С.
4. Второпях вернули для проблемного сайта не тот массив, к тому же направленный на балансер, не умеющий в rpc/tcp
Вот и все пока...
А причина вкратце была такая.
1. Список массивов
A
B
C
..
X
Y
Z
2. Был удален сайт AD /без серверов /без клиентов /без всего,
но указанный например для массива C
3. Как оказалось, архитектура Exchange в данном случае
просто прекращает работать для ВСЕХ массивов после С
т.е. поймали мы самый большой сайт, в остальных я думаю аналогично.
Даже get-casarray * завершится в консоли ошибкой Watson как раз после массива С.
4. Второпях вернули для проблемного сайта не тот массив, к тому же направленный на балансер, не умеющий в rpc/tcp
Вот и все пока...
SB
Так в итоге проблему то закрыли?
EV
Да, вернули массив который был до инцидента, все ок.
SB
Да, вернули массив который был до инцидента, все ок.
Ты их уже уговорил на миграцию на 2016?
АФ
Кому интересны кишочки легаси, то вот немного проанализировали.
А причина вкратце была такая.
1. Список массивов
A
B
C
..
X
Y
Z
2. Был удален сайт AD /без серверов /без клиентов /без всего,
но указанный например для массива C
3. Как оказалось, архитектура Exchange в данном случае
просто прекращает работать для ВСЕХ массивов после С
т.е. поймали мы самый большой сайт, в остальных я думаю аналогично.
Даже get-casarray * завершится в консоли ошибкой Watson как раз после массива С.
4. Второпях вернули для проблемного сайта не тот массив, к тому же направленный на балансер, не умеющий в rpc/tcp
Вот и все пока...
А причина вкратце была такая.
1. Список массивов
A
B
C
..
X
Y
Z
2. Был удален сайт AD /без серверов /без клиентов /без всего,
но указанный например для массива C
3. Как оказалось, архитектура Exchange в данном случае
просто прекращает работать для ВСЕХ массивов после С
т.е. поймали мы самый большой сайт, в остальных я думаю аналогично.
Даже get-casarray * завершится в консоли ошибкой Watson как раз после массива С.
4. Второпях вернули для проблемного сайта не тот массив, к тому же направленный на балансер, не умеющий в rpc/tcp
Вот и все пока...
👍