При использовании ZFS датастора в сценарии хранилища под виртуалки, нужно ещё префетч отключать, так как он профита никакого не даёт, но подгребает под себя IOPSы. Отключение префетча добавляет в синтетических тестах около 20% производительности.
В конце поста вы почему-то говорите про ZIL, и упоминаете «буфер 50 Гб». ZIL тут ни при чём, он используется только в сценарии с синхронной записью. При асинхронной лог не пишется, и ZIL не задействуется. ARC — да, работает всегда. Правда, непонятно, почему вы решили зажать ARC на четверть объёма оперативы. Если у вас это чистая хранилка, то отдайте ему всё, что он сможет забрать.
Далее, судя по параметру --runtime=60 в тестах, вы запускали тесты всего на 60 секунд. Ясное дело, что никакие кэши тут не помогут — они просто прогреться не успевают.
И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.
Статья правильная. Я работал в и малом бизнесе, и на аутсорсе IT, и в крупных конторах (300-800 человек, со своей разработкой). Те, кто утверждает, что «владелец предприятия не должен нянчиться...» и далее по тексту — плохо себе представляют реалии малого бизнеса. Ну или представляют хорошо, но понимают плохо. Это вообще суть бизнеса — владелец должен быть везде. Просто в крупных конторах это обеспечить невозможно, вследствие их размеров, поэтому там полномочия делегируются.
Рассказы про то, что «админ должен админить, а владелец — владеть, направлять и обеспечивать ресурсами» — это из серии «лучше быть богатым и здоровым, чем бедным и больным». В идеальном мире, с идеальными мальными бизнесменами и малыми сисадминами — наверное, так и должно быть. Но в реальном мире — нет, не получится.
И утверждать, что «нормальный админ всегда найдёт подход к руководству» может только человек, который либо этот подход никода не искал, либо ему просто повезло с руководством. Но такое везение тоже повсеместным не назовёшь.
Какие подходы вы предложите к директору организации, которая за услуги по лечению последствий вирусов за полгода потратила больше денег, чем стоит лицензия на антивирус на все машины компании на 5 лет? И даже несмотря на представленные конкретные цифры, директор всё равно продолжал отказывать закупать антивирус.
Для этого не нужен сервер, по такой схеме надёжнее в /dev/null сразу писать :-) А если где-то что-то сохраняется, то по-любому эту информацию можно прочитать. Так что не вариант.
То, что в обиходе называют «топографический кретинизм», обретает чёткие медицинские признаки.
Трудно представить себе такое, будучи в норме, конечно. Вспоминается история из упомянутой выше книги «Человек, который принял жену за шляпу» — у женщины вследствие дисфункции мозга, полностью отключилось чувство равновесия. Путём упорных тренировок она смогла восстановить возможность передвигаться, да что там — даже просто стоять, опираясь целиком на зрение. То есть, вот она стоит, но закрывает глаза — и падает, так как нет ощущения собственного тела в пространстве.
На вопрос, вынесенный в заголовок поста, ответ может быть только один — разумеется, ждать. А также следует ждать утечек информации и всего остального спектра. Да, и поддельных транзакций тоже.
Пока доподлинно неизвестно, интересовались ли хакеры этими дырами за последний год, однако не так давно Reuters сообщал, что двое человек в Европе умерли из-за преждевременной разрядки батарей стимуляторов St. Jude.
На PHDays 7-ом как раз был доклад про возможности DoS путём атаки на источники питания автономных устройств.
Это совсем не больная тема. Просто помимо цены нужно оценивать ещё и риски. Размещая информацию у постороннего провайдера, клиент доверяется ему полностью, и никак не может контролировать процессы обслуживания выделенных клиенту мощностей/объёмов.
А для тех случаев, когда возможность хоть какого-то контроля есть, всё равно нужны админы. Так что работа с облачными и прочими провайдерами такого рода услуг — она всё равно требует соответствующих знаний в общем случае.
Формально в списке блокировки есть все три компонента: URL, hostname, IP. Но по факту пользоваться хостнеймом и IP невозможно, так как большинство урлов тогда просто блокироваться не будут.
Мне не ясен другой вопрос: ЧТО сделали провайдеры, чтобы за все эти 3 года донести до РКН вот это всё?
Я там выше ответил, что делали провайдеры, и какую реакцию это вызывало. Причём моя контора — один из крупнейших независимых (не принадлежащих так или иначе «большой четвёрке») операторов связи в стране. Что уж говорить про десятки и сотни более мелких провайдеров. Какие у них реально возможности есть? Письма писать? Так они пишут. Какие ещё есть реальные рычаги воздействия на РКН?
02. Провайдер будет шевелиться, и получит по башке. Провайдер, в котором я работал, тоже пытался пошевелиться, чтобы РКН синхронизировал базы в списке блокировки и в базе на eais.rkn.gov.ru. В ответ получили: «Будете много умничать, обратим на вас пристальное внимание...»
Я совсем недавно анализировал борьбу сотовых операторов с МВД
Вы правда считаете, что у операторов сотовой связи, и каких-нибудь региональных интернет-провайдеров, у которых 4-5 тысяч абонентов, одинаковые возможности по борьбе с государственными ведомствами?
Проблемы провайдеров с миллионными оборотами не должны быть проблемой малого бизнеса в первую очередь, а в другую — всех остальных.
Провайдер может быть и с миллиардными оборотами, но при этом прибыль у него будет составлять единицы процентов. Каналы связи, оборудование связи, лицензионные требования, зарплаты весьма квалифицированным инженерам — оно, знаете ли, не копейки стоит.
И поэтому это их обязанность сделать всё, как полагается.
В подавляющем большинстве случаев провайдеры и так делают всё, как полагается. Но требования регулятора часто отдают полным идиотизмом.
Знаете, как проверялась блокировка по URL несколько лет назад? Провайдерам раздавали программку. Раз в несколько дней на почту прилетал CSV-файлик с адресами. И эта программка проверяла факт блокировки URL, пуская пинги на хостнеймы. ПИНГАМИ, Карл! Они проверяли доступность УРЛОВ — ПИНГАМИ! И если пинг проходил, то программа в отчёте указывала, что данных URL провайдером не блокируется. И провайдер получал по башке. В итоге мы были просто вынуждены блокировать ICMP на IP-адреса из списков блокировки.
Никаких нормальных технических средств не существует для блокировки HTTPS. Возможны два сценария:
1) Блокировка на базе хостнейма. Т. е. если от РКН прилетит в списке htts://youtube.com/blah-blah-blah, то придётся заблокировать весь youtube. Так как всё, что провайдер увидит в незашифрованном трафике — это ТОЛЬКО ХОСТНЕЙМ. А всё, что следует после хостнейма в URL (т. е. "/blah-blah-blah") — уже идёт по зашифрованному каналу, и заглянуть туда нельзя. Ну, точнее можно, если используется способ №2.
2) Способ №2 заключается в том, что провайдер вынужден расшифровывать трафик клиента, подсовывая сертификат не YouTube, а свой собственный. Получается два зашифрованных канала — от клиента до провайдера (зашифрован, если на пальцах, провайдерским сертификатом), и от провайдера до YouTube — зашифрованный сертификатом YouTube. Проблема тут в том, что провайдерский сертификат — недоверенный с точки зрения браузера клиента, и браузер обязательно ругнётся на это. Это первая часть проблемы.
Следствием второго способа блокировки будет ещё целый ряд аспектов. Допустим, удалось добавить сертификат провайдера всем клиентам в доверенное хранилище. ОК, браузеры перестали ругаться (хотя, на самом деле, чтобы это сделать, нужно тоже целую пачку костылей нагородить). Но после этого провайдер технически сможет заглядывать в зашифрованный трафик клиентов. Например, в трафик на онлайн-банки, в дропбоксы, в авторизацию вконтактиках/фейсбучиках/инстаграмчиках.
Ну то есть, это классическая атака по принципу man-in-the-middle. А одно из назначений HTTPS как раз в том и заключается, чтобы перехват и перлюстрация трафика была невозможна. Так что тут вопрос выбора: либо мы реализуем блокировку, либо у нас остаётся возможность безопасного обмена трафиком с легальными сервисами без возможности его (трафика) перлюстрации.
Мне тоже позиция «нет смысла бороться с государством, но можно бороться с провайдерами» показалось странной. Ну, то есть, не то, чтобы странной, просто это тоже подход из анекдота: «Ищем не там, где потеряли, а тем, где светлее».
Я работал в интернет провайдере, и непосредственно занимался реализацией системы блокировок по списку Роскомнадзора. И ответственно заявляю — косорукие провайдеры, безусловно, есть. Но бОльшая часть проблем с блокировками — целиком и полностью на совести Роскомнадзора и иже с ним.
Примеры:
Есть некоторое количество сайтов, которые прилетают в списке блокировки оператору, но при этом при проверке через eais.rkn.gov.ru эти сайты не видны ни по имени, ни по IP-адресу. Попытки общаться с РКН по этому поводу на тему «как нам объяснять факт блокировки клиентам в таких случаях» привели в конечном итоге к ответу: «Вам прилетает список блокировки — вот по нему и блокируйте. Остальное нас не волнует».
Рекомендации по блокировке. Раньше рекомендации по блокировке (по версии от 2013 года) звучали следующим образом (в части, касающейся резолва хостнеймов в IP-адреса):
Использовать следующую технологию для ограничения доступа к интернет-сайтам:
1) Выделение значения Host из URL;
2) Трансляция с помощью запросов в DNS значения Host в сетевой адрес (трансляцию проводит оператор связи), в случае если Host представлен в виде доменного имени;
А сегодня на сайте Роскомнадзора появляется новость со следующими словами:
Некорректный DNS резолвинг, который осуществляют отдельные операторы связи при блокировке интернет-страниц с противоправной информацией, возникает, когда оператор связи самостоятельно определяет IP-адрес запрещенного интернет-ресурса.
Вы же сами это требовали, в своих рекомендациях от 2013 года, чтобы операторы сами резолвили! А теперь, оказывается, что операторы осуществляют некорректный DNS-резолвинг.
Так что операторы здесь — такая же пострадавшая сторона в большинстве случаев, как и пользователи.
На PHDays VII один из докладчиков сказал, что по ряду признаков эту эпидемию можно считать не следствием уязвимости, а эксплуатацией заложенного в реализацию SMB бэкдора. Равно как и целый ряд предыдущих эпидемий, связанных с уязвимостями SMB. Например, SASSER.
И что в случае WannaCry напрягаться нужно не тем, у кого файлики оказались зашифрованы, а тем, кто якобы не пострадал. В качестве примера привёл факт, что, например, в МИДе не пострадал вообще ни один компьютер.
В эту версию как раз хорошо ложится тот факт, что создатели WannaCry не очень заморачивались сбором денег, и таким образом сам факт появления шифровальщика является просто дымовой завесой для размещения совсем другой рабочей нагрузки совсем в другие места.
В приличных конторах автообновления включены, но только качаются с собственного сервера обновлений. А перед тем, как одобрить обновление для массовой установки, оно может несколько месяцев тестироваться в лабе или на не-критичных серверах. Потому что поймать локера — это грустно, спору нет. Но никак не менее грустно, когда после массовой установки недостаточно хорошо протестированного обновления у вас все виндовые сервера полягут. Поэтому дельта в несколько месяцев между выходом и установкой обновления — это суровая производственная необходимость.
В конце поста вы почему-то говорите про ZIL, и упоминаете «буфер 50 Гб». ZIL тут ни при чём, он используется только в сценарии с синхронной записью. При асинхронной лог не пишется, и ZIL не задействуется. ARC — да, работает всегда. Правда, непонятно, почему вы решили зажать ARC на четверть объёма оперативы. Если у вас это чистая хранилка, то отдайте ему всё, что он сможет забрать.
Далее, судя по параметру --runtime=60 в тестах, вы запускали тесты всего на 60 секунд. Ясное дело, что никакие кэши тут не помогут — они просто прогреться не успевают.
И компрессию на ZFS вы выключили совершенно напрасно. Сжатие снижает число реальных ИОПСов, долетающих до дисков.
Рассказы про то, что «админ должен админить, а владелец — владеть, направлять и обеспечивать ресурсами» — это из серии «лучше быть богатым и здоровым, чем бедным и больным». В идеальном мире, с идеальными мальными бизнесменами и малыми сисадминами — наверное, так и должно быть. Но в реальном мире — нет, не получится.
И утверждать, что «нормальный админ всегда найдёт подход к руководству» может только человек, который либо этот подход никода не искал, либо ему просто повезло с руководством. Но такое везение тоже повсеместным не назовёшь.
Какие подходы вы предложите к директору организации, которая за услуги по лечению последствий вирусов за полгода потратила больше денег, чем стоит лицензия на антивирус на все машины компании на 5 лет? И даже несмотря на представленные конкретные цифры, директор всё равно продолжал отказывать закупать антивирус.
Трудно представить себе такое, будучи в норме, конечно. Вспоминается история из упомянутой выше книги «Человек, который принял жену за шляпу» — у женщины вследствие дисфункции мозга, полностью отключилось чувство равновесия. Путём упорных тренировок она смогла восстановить возможность передвигаться, да что там — даже просто стоять, опираясь целиком на зрение. То есть, вот она стоит, но закрывает глаза — и падает, так как нет ощущения собственного тела в пространстве.
+ теория передачи информации;
+ цифровая обработка сигналов.
Это всё в рамках учёбы по специальности 2201.
На PHDays 7-ом как раз был доклад про возможности DoS путём атаки на источники питания автономных устройств.
А для тех случаев, когда возможность хоть какого-то контроля есть, всё равно нужны админы. Так что работа с облачными и прочими провайдерами такого рода услуг — она всё равно требует соответствующих знаний в общем случае.
Я там выше ответил, что делали провайдеры, и какую реакцию это вызывало. Причём моя контора — один из крупнейших независимых (не принадлежащих так или иначе «большой четвёрке») операторов связи в стране. Что уж говорить про десятки и сотни более мелких провайдеров. Какие у них реально возможности есть? Письма писать? Так они пишут. Какие ещё есть реальные рычаги воздействия на РКН?
Вы правда считаете, что у операторов сотовой связи, и каких-нибудь региональных интернет-провайдеров, у которых 4-5 тысяч абонентов, одинаковые возможности по борьбе с государственными ведомствами?
Провайдер может быть и с миллиардными оборотами, но при этом прибыль у него будет составлять единицы процентов. Каналы связи, оборудование связи, лицензионные требования, зарплаты весьма квалифицированным инженерам — оно, знаете ли, не копейки стоит.
В подавляющем большинстве случаев провайдеры и так делают всё, как полагается. Но требования регулятора часто отдают полным идиотизмом.
Знаете, как проверялась блокировка по URL несколько лет назад? Провайдерам раздавали программку. Раз в несколько дней на почту прилетал CSV-файлик с адресами. И эта программка проверяла факт блокировки URL, пуская пинги на хостнеймы. ПИНГАМИ, Карл! Они проверяли доступность УРЛОВ — ПИНГАМИ! И если пинг проходил, то программа в отчёте указывала, что данных URL провайдером не блокируется. И провайдер получал по башке. В итоге мы были просто вынуждены блокировать ICMP на IP-адреса из списков блокировки.
1) Блокировка на базе хостнейма. Т. е. если от РКН прилетит в списке htts://youtube.com/blah-blah-blah, то придётся заблокировать весь youtube. Так как всё, что провайдер увидит в незашифрованном трафике — это ТОЛЬКО ХОСТНЕЙМ. А всё, что следует после хостнейма в URL (т. е. "/blah-blah-blah") — уже идёт по зашифрованному каналу, и заглянуть туда нельзя. Ну, точнее можно, если используется способ №2.
2) Способ №2 заключается в том, что провайдер вынужден расшифровывать трафик клиента, подсовывая сертификат не YouTube, а свой собственный. Получается два зашифрованных канала — от клиента до провайдера (зашифрован, если на пальцах, провайдерским сертификатом), и от провайдера до YouTube — зашифрованный сертификатом YouTube. Проблема тут в том, что провайдерский сертификат — недоверенный с точки зрения браузера клиента, и браузер обязательно ругнётся на это. Это первая часть проблемы.
Следствием второго способа блокировки будет ещё целый ряд аспектов. Допустим, удалось добавить сертификат провайдера всем клиентам в доверенное хранилище. ОК, браузеры перестали ругаться (хотя, на самом деле, чтобы это сделать, нужно тоже целую пачку костылей нагородить). Но после этого провайдер технически сможет заглядывать в зашифрованный трафик клиентов. Например, в трафик на онлайн-банки, в дропбоксы, в авторизацию вконтактиках/фейсбучиках/инстаграмчиках.
Ну то есть, это классическая атака по принципу man-in-the-middle. А одно из назначений HTTPS как раз в том и заключается, чтобы перехват и перлюстрация трафика была невозможна. Так что тут вопрос выбора: либо мы реализуем блокировку, либо у нас остаётся возможность безопасного обмена трафиком с легальными сервисами без возможности его (трафика) перлюстрации.
Я работал в интернет провайдере, и непосредственно занимался реализацией системы блокировок по списку Роскомнадзора. И ответственно заявляю — косорукие провайдеры, безусловно, есть. Но бОльшая часть проблем с блокировками — целиком и полностью на совести Роскомнадзора и иже с ним.
Примеры:
Есть некоторое количество сайтов, которые прилетают в списке блокировки оператору, но при этом при проверке через eais.rkn.gov.ru эти сайты не видны ни по имени, ни по IP-адресу. Попытки общаться с РКН по этому поводу на тему «как нам объяснять факт блокировки клиентам в таких случаях» привели в конечном итоге к ответу: «Вам прилетает список блокировки — вот по нему и блокируйте. Остальное нас не волнует».
Рекомендации по блокировке. Раньше рекомендации по блокировке (по версии от 2013 года) звучали следующим образом (в части, касающейся резолва хостнеймов в IP-адреса):
А сегодня на сайте Роскомнадзора появляется новость со следующими словами:
Вы же сами это требовали, в своих рекомендациях от 2013 года, чтобы операторы сами резолвили! А теперь, оказывается, что операторы осуществляют некорректный DNS-резолвинг.
Так что операторы здесь — такая же пострадавшая сторона в большинстве случаев, как и пользователи.
И что в случае WannaCry напрягаться нужно не тем, у кого файлики оказались зашифрованы, а тем, кто якобы не пострадал. В качестве примера привёл факт, что, например, в МИДе не пострадал вообще ни один компьютер.
В эту версию как раз хорошо ложится тот факт, что создатели WannaCry не очень заморачивались сбором денег, и таким образом сам факт появления шифровальщика является просто дымовой завесой для размещения совсем другой рабочей нагрузки совсем в другие места.