А лицензии? Лицензии на Win2K12 тоже денег стоят. А без лицензии она работает 1 час и выключается :).
Смысл покупать железо или поднимать виртуалки без лицензионных ОСей?
Даже не прорабатывал этот вопрос, честно говоря :) Пока что прекрасно обходились двумя железными контроллерами. Железо еще не совсем старое — лет 7 всего. ОСь с прежних серваков перенеслась без проблем.
Так что даже не знаю, как виртуалки ставятся. Не интересно было…
Единственный опыт был — поднимали XP на VMWare в другой XP, т.к. OPC-сервера разных производителей на одной машине начинали конфликтовать. Намучались с пробросом сетевых интерфейсов. Что-то больше не хочется.
Мешает Федеральный закон ФЗ-44, по которому план закупок на 2018 год уже сверстан, а внесение в него изменений — еще тот геморрой. С кучей заявок, обоснований и утверждений. Так что, либо включать в план закупок 2019 года, либо нижайше бить челом. Притом не только нам перед директором, а директору перед городскими властями, а тем — перед областными. Чтобы выделили дополнительное финансирование.
В связи с тем, что зловред использует сохраненные пароли локального и доменного админа для доступа к другим компам, встали вопросы:
1. Как средствами GP или другими удалить по сетке учетки доменного админа со всех компов?
Команда NET USER работает только с локальными учетками?
2. Как средствами GP или другими сменить по сетке пароли локальных админов?
Команда NET USER может удалять/добавлять/(де)активировать учетки, но не менять пароли.
У меня не 1000+ машинок, но все равно ноги топтать неохота. Да и пропустить могу кого-то.
У-ф-ф… Напугали… А я думал уже, что кирдык всей ФС, причем неремонтируемый даже при загрузке с диска MS DaRT. И Hard Reset не в помощь…
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
На SQL-сервере общих ресурсов нет кроме системных: ADMIN$, IPC$, C$ и т.д. Администратор домена может к ним подключиться.
На сервере геоинформационной системы есть расшаренные папки. Чтобы админ ГИС мог заливать привязанные к объектам фото, схемы, пятисотки. С XP с правами этого админа в них заходит.
На сервере терминалов (про который сканер говорит, что он безопасен) тоже есть шары — на локальные файловые БД. С правами соответствующих админов на них с XP заходит.
Т.е., заходит с XP на все расшаренные ресурсы, но один сервер помечается сканером как безопасный, а второй — как с неопределяемой уязвимостью.
Но это не единственные сервера с Win2K12 R2. Про другие сканер, тем не менее пишет не такую строчку, а вполне обычную:
[-] 192.168.xxx.yyy (Windows Server 2012 R2 Standard 9600) stays in safety
Ну это после установки всех последних обновлений. Как было до этого — не знаю. Потому что сразу при начале эпидемии кинулся устанавливать их и перегружать сервера.
Спасибо за сканер — оч-ч-чень полезное изобретение… За полдня обежал всю контору и еще по RAdmin кучу компов обновил. Где XP стояла (автоматом она не не находит обновлений — только вручную устанавливать), где обновления по каким-то причинам глючили, где доступ в Инет был заблочен, но время от времени обновления хоть вручную ставить надо. Без сканера наверняка бы много пропустил.
Только вот на двух серверах тоже выдает такую строчку:
can't determine whether 192.168.xxx.yyy is vulnerable or not
На одном файерволл включен, на другом — нет. На одном MS SQL сервер, на другом сервер геоинформационной системы. Общее — Win2K12 Server R2 Standard Edition. Но эта ОСь есть и на других машинах, как и включенные файерволлы.
1. БД персоналий создавалась полуавтоматически на основании списка актеров/режиссеров и прочих действующих лиц к фильму. Этот список представлял собой обычную текстовую строку, разделенную запятыми.
При добавлении фильма строка парсилась скриптом. Если имя уже присутствовало в БД, то создавалась связь между страничкой фильма и страничкой персоны. Если имени в БД еще не было, то страничка персоны (пустая) сначала создавалась.
Если имя в строке-списке было написано с ошибкой, то под него создавалась новая страница. Если ошибка была вовремя обнаружена и исправлена, то связь пересоздавалась, но ошибочная страница оставалась.
Если же ошибка не была исправлена, то получалось у одной персоны несколько страниц с разным написанием имени и с разным набором фильмов.
2. Дата рождения/смерти, место рождения и другие данные заполнялись теми же энтузиастами по мере возможностей и желания. Если страниц одного актера было несколько, то на одной могли быть эти данные, а на другой — биография и т.д. Причем, заполненных страниц было гораздо меньше, чем незаполненных.
3. Однофамильцы, действительно, есть. И достаточно много. Так что еще стояла задача их поиска и разделения их на разные страницы. Но это немного другая задача. Автоматически она не решается — только ручным анализом фильмографий и сравнением с другими БД, например с IMDb.
Только вот дело в том, что пока однофамильцы не разделены, у них всего одна страничка на всех. А если разделены, то каждому присвоен уникальный номер, например «Дэвид Прайс (II)». Поэтому их не могло быть «много» по определению. Либо на всех одна страница, либо их имена различаются уникальным номером.
А вот разных страниц одной персоны могло быть 2-3, а то и 4. Например, могло быть 4 страницы с такими именами:
Так Сакагути
Так Сакагучи
Сакагучи Так
Сакагути Так
А правильное из этого списка — только одно.
Вот и стояла задача обнаружить все имена, подозрительно схожие между собой. Чтобы провести ручной анализ их схожести, исправить и удалить лишние.
Во-первых, БД «худела», избавляясь от мусора. Поиск выдавал одну страницу, а не несколько, отличающихся только разным порядком слов.
Во-вторых, из нее удалялись имена с ошибочным написанием.
В-третьих, такие страницы объединялись — объединялись фильмографии.
Так что, практический смысл был вполне определенный.
Во всяком случае, среди найденных пар с релевантностью 1.0 было более 80% страниц двойников с разным порядком слов или с разными знаками препинания. Например, в одном прозвище написано в простых кавычках, а в другом — в двойных. Остальные принадлежали разделенным тезкам/однофамильцам.
Среди пар с меньшей релевантностью тезок не будет совсем, но будет достаточно много просто схожих имен разных персон. Вот поэтому и нужен ручной анализ, чтобы определить, что «Трейси Кэй» и «Трэйси Кэй Вульф» — это одна и та же актриса. Просто в разных фильмах она по разному в титрах указана. А так же в некоторых фигурировала под именем «Трэйси Вульф», но ничего общего с актрисой Трэйси Вульф, которая играла дочь чернокожего напарника в «Смертельном оружии» не имеет.
Согласен с Analitik_Telecom в плане того, что не в длине заголовка счастье…
Заголовок, список хабов и анонс статьи (то, что до ката) — это основные средства привлечь внимание целевой аудитории.
И если автор статьи относится к этим средствам вдумчиво и серьезно, то он сумеет так распределить между ними нужную информацию, что каждая из этих частей будет достаточно лаконична, но информативна. А такой подход уже сам по себе будет привлекать читателя, а не только количество букв в них.
Что касается фрагментов кода в длинных статьях, то тут ситуация противоречивая:
С одной стороны, если автор делится кодом, значит он считает, что тема настолько интересна, что код может пригодиться кому-то еще. И зачастую, это именно так и обстоит. Т.е. это не длина вызывает интерес, а оправданный расчет на заинтересованность заставляет внедрять в статью код.
С другой стороны, аккуратные авторы длинный код прячут в спойлеры. И более показательно было бы провести оценку интереса в зависимости от длины текста без спрятанных фрагментов.
Мне кажется, что этот показатель был бы более адекватным текущей ситуации.
Смысл покупать железо или поднимать виртуалки без лицензионных ОСей?
Даже не прорабатывал этот вопрос, честно говоря :) Пока что прекрасно обходились двумя железными контроллерами. Железо еще не совсем старое — лет 7 всего. ОСь с прежних серваков перенеслась без проблем.
Так что даже не знаю, как виртуалки ставятся. Не интересно было…
Единственный опыт был — поднимали XP на VMWare в другой XP, т.к. OPC-сервера разных производителей на одной машине начинали конфликтовать. Намучались с пробросом сетевых интерфейсов. Что-то больше не хочется.
А если скриптом задать новый с солью, зависящей, например, от сетевого имени компа или даты установки ОСи, то они будут разные на каждом компе.
Спасибо нашему правительству!!!
Когда вирус будет бродить по сети — будет поздно метаться :D Но пароль доменного админа сменил сразу.
А что насчет смены пароля локального админа по сети?
1. Как средствами GP или другими удалить по сетке учетки доменного админа со всех компов?
Команда NET USER работает только с локальными учетками?
2. Как средствами GP или другими сменить по сетке пароли локальных админов?
Команда NET USER может удалять/добавлять/(де)активировать учетки, но не менять пароли.
У меня не 1000+ машинок, но все равно ноги топтать неохота. Да и пропустить могу кого-то.
Или они с учетками доменных админов на них попадают?
А пароли он откуда для них берет? Каким-то образом подбирает?
Каким образом зловред проник в сеть с установленным файерволлом и обновлениями?
Как я понимаю, доступ по SMB извне был закрыт. Уязвимость пропатчена… Т.е. механизм внедрения WannaCry не прокатывал.
Так как тогда?
И еще: есть где детектор уязвимости? Для WannaCry ребята сваяли такой. В комментариях к https://habrahabr.ru/company/cisco/blog/328598/#first_unread есть ссылки.
А для Пети/Миши есть что-то наподобие?
Что за группа «йо»? Тем более, что и «й» и «о» уже входят в другие группы.
https://www.theverge.com/2017/5/26/15696704/microsoft-windows-7-windows-8-pc-crash-bug-ntfs
На 4PDA есть перевод:
http://4pda.ru/2017/05/29/342735/
Но все равно, если есть возможность внедрить это обращение в html любого сайта, то удовольствия мало. Особенно для терминальных серверов. Особенно работающих с локальными файл-серверными БД.
"… если выполнить перезагрузку, то система повиснет на ней".
Т.е. после таких экспериментов система перестает загружаться от слова «совсем»?
Чем в таком случае лечить? Диагностика ФС из набора MS DaRT помогает? Или какие сторонние средства?
На сервере геоинформационной системы есть расшаренные папки. Чтобы админ ГИС мог заливать привязанные к объектам фото, схемы, пятисотки. С XP с правами этого админа в них заходит.
На сервере терминалов (про который сканер говорит, что он безопасен) тоже есть шары — на локальные файловые БД. С правами соответствующих админов на них с XP заходит.
Т.е., заходит с XP на все расшаренные ресурсы, но один сервер помечается сканером как безопасный, а второй — как с неопределяемой уязвимостью.
[-] 192.168.xxx.yyy (Windows Server 2012 R2 Standard 9600) stays in safety
Ну это после установки всех последних обновлений. Как было до этого — не знаю. Потому что сразу при начале эпидемии кинулся устанавливать их и перегружать сервера.
P.S. Файерволл на них включен. В чем разница?
Только вот на двух серверах тоже выдает такую строчку:
can't determine whether 192.168.xxx.yyy is vulnerable or not
На одном файерволл включен, на другом — нет. На одном MS SQL сервер, на другом сервер геоинформационной системы. Общее — Win2K12 Server R2 Standard Edition. Но эта ОСь есть и на других машинах, как и включенные файерволлы.
Вобщем, чем они такие особенные — не понятно.
1. БД персоналий создавалась полуавтоматически на основании списка актеров/режиссеров и прочих действующих лиц к фильму. Этот список представлял собой обычную текстовую строку, разделенную запятыми.
При добавлении фильма строка парсилась скриптом. Если имя уже присутствовало в БД, то создавалась связь между страничкой фильма и страничкой персоны. Если имени в БД еще не было, то страничка персоны (пустая) сначала создавалась.
Если имя в строке-списке было написано с ошибкой, то под него создавалась новая страница. Если ошибка была вовремя обнаружена и исправлена, то связь пересоздавалась, но ошибочная страница оставалась.
Если же ошибка не была исправлена, то получалось у одной персоны несколько страниц с разным написанием имени и с разным набором фильмов.
2. Дата рождения/смерти, место рождения и другие данные заполнялись теми же энтузиастами по мере возможностей и желания. Если страниц одного актера было несколько, то на одной могли быть эти данные, а на другой — биография и т.д. Причем, заполненных страниц было гораздо меньше, чем незаполненных.
3. Однофамильцы, действительно, есть. И достаточно много. Так что еще стояла задача их поиска и разделения их на разные страницы. Но это немного другая задача. Автоматически она не решается — только ручным анализом фильмографий и сравнением с другими БД, например с IMDb.
Только вот дело в том, что пока однофамильцы не разделены, у них всего одна страничка на всех. А если разделены, то каждому присвоен уникальный номер, например «Дэвид Прайс (II)». Поэтому их не могло быть «много» по определению. Либо на всех одна страница, либо их имена различаются уникальным номером.
А вот разных страниц одной персоны могло быть 2-3, а то и 4. Например, могло быть 4 страницы с такими именами:
А правильное из этого списка — только одно.
Вот и стояла задача обнаружить все имена, подозрительно схожие между собой. Чтобы провести ручной анализ их схожести, исправить и удалить лишние.
Во-первых, БД «худела», избавляясь от мусора. Поиск выдавал одну страницу, а не несколько, отличающихся только разным порядком слов.
Во-вторых, из нее удалялись имена с ошибочным написанием.
В-третьих, такие страницы объединялись — объединялись фильмографии.
Так что, практический смысл был вполне определенный.
Во всяком случае, среди найденных пар с релевантностью 1.0 было более 80% страниц двойников с разным порядком слов или с разными знаками препинания. Например, в одном прозвище написано в простых кавычках, а в другом — в двойных. Остальные принадлежали разделенным тезкам/однофамильцам.
Среди пар с меньшей релевантностью тезок не будет совсем, но будет достаточно много просто схожих имен разных персон. Вот поэтому и нужен ручной анализ, чтобы определить, что «Трейси Кэй» и «Трэйси Кэй Вульф» — это одна и та же актриса. Просто в разных фильмах она по разному в титрах указана. А так же в некоторых фигурировала под именем «Трэйси Вульф», но ничего общего с актрисой Трэйси Вульф, которая играла дочь чернокожего напарника в «Смертельном оружии» не имеет.
Заголовок, список хабов и анонс статьи (то, что до ката) — это основные средства привлечь внимание целевой аудитории.
И если автор статьи относится к этим средствам вдумчиво и серьезно, то он сумеет так распределить между ними нужную информацию, что каждая из этих частей будет достаточно лаконична, но информативна. А такой подход уже сам по себе будет привлекать читателя, а не только количество букв в них.
Что касается фрагментов кода в длинных статьях, то тут ситуация противоречивая:
С одной стороны, если автор делится кодом, значит он считает, что тема настолько интересна, что код может пригодиться кому-то еще. И зачастую, это именно так и обстоит. Т.е. это не длина вызывает интерес, а оправданный расчет на заинтересованность заставляет внедрять в статью код.
С другой стороны, аккуратные авторы длинный код прячут в спойлеры. И более показательно было бы провести оценку интереса в зависимости от длины текста без спрятанных фрагментов.
Мне кажется, что этот показатель был бы более адекватным текущей ситуации.