Текущее время: понедельник, 6 мая 2024, 04:27
Пользователи, которые читают эту тему: 1 гость
Новая тема Ответить
#361 Ссылка на пост Добавлено:
Niklauster, дык обычную гибернацию не впилили. Просто фишка в том, что при выключении компа он будет убивать пользовательскую сессию, а ядро и дрова будут записаны на диск. MS обещал прирост скорости загрузки на 30-70%. 70% - это при использовании SSD. 30% - соответственно HDD.

ИМХО очень грамотное и правильное решение. Даже если прирост в скорости будет в 20-30% - это уже достижение Smile
#362 Ссылка на пост Добавлено:
Т.е., как я понял обычного спящего режима с сохранением пользовательской сессии в восьмерке не будет? Если так - то ИМХО сомнительный компромисс. Те, кто пользуется виндой постоянно для серьезных целей либо не выключает комп несколько дней (у моего рабочего компа аптайм пару месяцев, у коллеги - два года), либо тратит эти 30 секунд на приготовление чая, выкуривание сигареты или еще на что-либо подобное. А вот лишить юзера приостановить работаюшие программы - это зря. Ну и реклама, мол загрузка ускорилась на 40% благодаря новому дорогому типу винчестеров - это вообще Маршал Очевидность. Теоретически, если зашить образ винды в какой-нибудь отдельный микроконтроллер - то загрузка будет производится вообще за доли секунды. А если разогнать электроны выше скорости света в большом андронном коллайдере... Заткнулся
#363 Ссылка на пост Добавлено:
Niklauster писал(а):
у коллеги - два года

А обновления, сервис-паки и всякое-такое? Wink
#364 Ссылка на пост Добавлено:
Silvering, у него ХП стоит вместо семерки (вообще-то не по полиси компании), машинка используется в основном в качестве ftp сервера. Обновления в сети админами включены только для win7.
#365 Ссылка на пост Добавлено:
Niklauster, нет, нигде же не было написано про отсутствие обычной гибернации Wink2

А вот обычного выключения питания не будет Smile
#367 Ссылка на пост Добавлено:
https://technet.microsoft.com/en-us/security/bulletin/ms11-083

Корпорация выпустила обновление для закрытия уязвимости, которая позволяет выполнить удаленный код, отправив специально сформированный UDP-пакет на ЗАКРЫТЫЙ сетевой порт. Вот так энтерпрайзный подход, пакеты которые в систему вообще не должны попадать, почему-то в системе подвергались дальнейшей обработке. good
#368 Ссылка на пост Добавлено:
Niklauster, слабаки они, я с тобой полностью согласен.
То ли дело Настоящие Свободные Люди - во второй половине августа слегли kernel.org и linux.com (итог - сайты пролежали больше полутора месяцев, половину исходников третьего ядра профукали), а в середине октября ещё поимели fsf.org и gnu.org. Подозреваю, что на серверах этих организаций стоял Windows Server 2008 R2, который тайные кулхацкеры похакали через уязвимость в обработке UDP.
#369 Ссылка на пост Добавлено:
Оказывается, конкретная специфика ситуации с данной уязвимостью такова: необходимо, чтобы порт, подвергающийся атаке, был специально закрыт на стандартном windows-фаерволе, то бишь было прописано правило вида "На 60 UDP ходить нельзя". Если нету явного запрещающего правила - эта дырка не сработает. Если порт не закрыт вообще - тоже не сработает. Всё это делает данную уязвимость не очень-то и опасной, что, конечно же, не исключает накатывания патчей.
#370 Ссылка на пост Добавлено:
Stressed писал(а):
Если нету явного запрещающего правила - эта дырка не сработает. Если порт не закрыт вообще - тоже не сработает.

в этих двух предложениях разве не написано одно и то же?

Stressed писал(а):
Всё это делает данную уязвимость не очень-то и опасной, что, конечно же, не исключает накатывания патчей.

а по-моему более чем: выполнение произвольного кода в ситуации использования продукта по прямому назначению, не понимаю чего тут приукрашивать...
#371 Ссылка на пост Добавлено:
OceanReBorn писал(а):
в этих двух предложениях разве не написано одно и то же?

Нет. Может быть правило вроде "Закрыть весь UDP", при котором явное запрещающее правило для конкретных портов отсутствует.
OceanReBorn писал(а):
а по-моему более чем: выполнение произвольного кода в ситуации использования продукта по прямому назначению, не понимаю чего тут приукрашивать...

Настроенная по умолчанию система не имеет явно закрытых UDP портов, следовательно, не подвержена уязвимости. Всё, что потом делается одминами - по большей части на их совести (не может ведь MS отвечать за то, что некое криворукое существо вырубит, допустим, фаервол, DEP, обновление и ещё кучу всяких полезных вещей). Это существенно меняет возможность использования уязвимости, но никак не её Severity Rating (который почти при любых Remote уязвимостях ставится максимальным). Тем не менее, патч уже имеется, а кто его не накатил - сам виноват.
#372 Ссылка на пост Добавлено:
Stressed, ну вы, батенька, даете. Нет бы признать уязвимость, так оказывается это не система виновата, что если я закрою порт, то на моем серваке могут резвиться как угодно, это Я виноват, потому что криво настроил. Что-то мне кажется, что если бы подобный баг нашли в ядре линукса, ты бы говорил совершенно противоположные вещи.
Это баг. Причем баг очень критичный для серваков, где как раз могут быть закрыты определенные порты. Хорошо, что его поправили, но неизвестно, сколько его уже использовали.
#373 Ссылка на пост Добавлено:
Dead Boy, я понимаю, что ты ночью писал, но будь повнимательнее, ок?
Dead Boy писал(а):
Нет бы признать уязвимость

Покажи, где я её отрицаю её существование.
Dead Boy писал(а):
это не система виновата

Система ещё как виновата, но моя фраза
Stressed писал(а):
Это существенно меняет возможность использования уязвимости, но никак не её Severity Rating

совсем не об этом. А по поводу ответственности одминов за свои действия с системой - это, по-моему, самое что ни на есть очевидное.
Dead Boy писал(а):
если бы подобный баг нашли в ядре линукса

В линуксе ещё и не такое бывало...
Да, и в дополнение - на машине должен быть поднят какой-нибудь сервис, который ждёт UDP-запросы. Много ты наркоманов видел, которые работающему сервису явно закрывают порты? Проще такие сервисы отключить или перенастроить.
#374 Ссылка на пост Добавлено:
Stressed писал(а):
Да, и в дополнение - на машине должен быть поднят какой-нибудь сервис, который ждёт UDP-запросы. Много ты наркоманов видел, которые работающему сервису явно закрывают порты? Проще такие сервисы отключить или перенастроить.


Во-первых: сервисы сервисам рознь, бывает так, что нужно закрывать например из-за известной уязвимости, для которой еще не выпустили заплатку.
Во-вторых: это нормальная практика для учреждений закрывать все, что можно по максимуму.
#375 Ссылка на пост Добавлено:
Калючы Iрчы, есть групповые политики, в которых можно запретить запуск всех левых сервисов. Далее - если для работы сервиса критично получение инфы по UDP-порту, а ты этот порт блокируешь, то проще тогда сервис убить, ибо всё равно в большинстве случаев он будет бесполезен.
#376 Ссылка на пост Добавлено:
Stressed писал(а):
Калючы Iрчы, есть групповые политики, в которых можно запретить запуск всех левых сервисов. Далее - если для работы сервиса критично получение инфы по UDP-порту, а ты этот порт блокируешь, то проще тогда сервис убить, ибо всё равно в большинстве случаев он будет бесполезен.


См. выше: сервис сервису рознь.
Простая ситуация, нашли в системном сервисе, который нельзя отрубить, уязвимость, которыя выполняется, если на UDP порт послать запрос.
#377 Ссылка на пост Добавлено:
Stressed писал(а):
Настроенная по умолчанию система не имеет явно закрытых UDP портов, следовательно, не подвержена уязвимости.

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

Цитата:
Всё, что потом делается одминами - по большей части на их совести (не может ведь MS отвечать за то, что некое криворукое существо вырубит, допустим, фаервол, DEP, обновление и ещё кучу всяких полезных вещей).

Несомненно, за все деяния над рабочей станцией отвечает админ. Только если админ добросовестно выполнил свои обязанности - в данном случае прикрыл некоторые UDP-порты (все закрывать - это нонсенс, UDP нужен для работы того же DNS-сервиса) до выхода заплатки, а сервер подвергся взлому через данную дыру, вина за это лежать должна не на админе. Или в обязанности сисадмина входит ковыряние с отладчиком во всех средствах безопасности операционной системы? А абстрактное понятие Severity Rating очень мало говорит об уязвимости, количество уязвимых машин/актуальное число существующих эксплойтов было бы куда информативнее.

Stressed писал(а):
Много ты наркоманов видел, которые работающему сервису явно закрывают порты?

Спешу удивить, такое явление, как закрытие сетевых портов, используемых работающим сервисом, не такое уж и безумное занятие, каким оно может показаться. Вполне логичная схема защиты - открытие портов для работающего приложения, при условии наступления определенного события. К примеру http://en.wikipedia.org/wiki/Port_knocking
#378 Ссылка на пост Добавлено:
Niklauster писал(а):
Настроенная по умолчанию система не имеет явно закрытых портов, а следовательно подвержена более широкому кругу атак/эксплойтов, не находишь?

Совершенно верно, только если мы говорим про опасность какой-либо уязвимости, то не можем предусмотреть всех вариантов настроек и установленного софта. Поэтому чаще всего для абстрактного обсуждения обычно берётся система с дефолтными настройками.
Niklauster писал(а):
А абстрактное понятие Severity Rating очень мало говорит об уязвимости, количество уязвимых машин/актуальное число существующих эксплойтов было бы куда информативнее.

Severity Rating, грубо говоря, сообщает о том, насколько эта уязвимость опасна в принципе, то есть с учётом самых запущенных и грустных сценариев.
Niklauster писал(а):
количество уязвимых машин/актуальное число существующих эксплойтов было бы куда информативнее

Судя по тому, что уязвимость была privately reported (т.е. кто-то один знал, грубо говоря, и сказал MS), такое количество вполне себе может стремиться к нулю.
Niklauster писал(а):
Вполне логичная схема защиты - открытие портов для работающего приложения, при условии наступления определенного события.

Это да. В таком случае, такая система защиты может с некоторой вероятностью скомпрометировать систему, как и в случае со статично закрытым портом.
#379 Ссылка на пост Добавлено:
Stressed писал(а):
Покажи, где я её отрицаю её существование.

по логике озвученной выше - любая уязвимость на которую выпустили заплатку - пустячок. Ну да можно «свалить винду через C:\con\con» что как бы намекает на качество продукта, но если выпущен патч, то это вдруг резко возвращает уровень крутости и качественности продукту. Такая твоя логика.
Вся анекдотичность ситуации в том, что чем более строгие настройки применяются для защиты - тем менее безопасной становится эта система. Действуя "по науке" - делаешь себе во вред. Это так же как, если после увеличения уровня строгости проверки антивируса - он стал находить меньше вирусов, а ты ещё к этому добавляешь, что не хватает только отключить DEP и всё остальное что бы сделать систему совсем беззащитной. Как знать может и DEP стоит отключить, что бы поднять реальную безопасность системы, раз тут прямая логика обеспечения безопасности не работает.
#380 Ссылка на пост Добавлено:
OceanReBorn, из первого абзаца я вижу, что ты по большому счёту не понял смысл всего вышесказанного. Я считаю, что достаточно понятно всё объяснил, поэтому повторять специально для тебя не буду, уж не обессудь.
Второй абзац - чистейшей воды твои фантазии. Предполагать, что из-за одной весьма специфичной уязвимости надо откручивать в системе гайки в дальнейшем, а ещё лучше DEP отключить - это и есть самый настоящий анекдот. Может, я слишком серьёзно пытаюсь его воспринимать - ну так у нас тут не "Продолжаем смеяться!", а нечто более другое.
Форум / Техника, интернет / Microsoft. No comments!
Загрузка...
Быстрый вход: