по iperf — согласен: тестировщик просто на Xen выбрал сетевую карту 100мбитную, а на Hyper-V 1гигабитную. А мог вообще заюзать последнее поколение ВМ и выбрать 10гбитные сетевые карты — которые сейчас норма для работы вирутальной сети в приделах одного хоста.
я скорее поверю трудящемуся видео, чем «красивой рекламе» =). Но это мое мнение, и это нормально что у кого то оно не такое как у меня. А если хотите «точные» тесты — замеряйте их сами, и тогда и спора не будет.
я понимаю что google в Росии был забанен, и Youtube не работал, но все же — включите любую vpn\proxy и погуглите: www.youtube.com/watch?v=-sp7Li9q3Ao — например за 2016 год видео. Вопрос сравнения бенчмарков поднимался сотню раз, и не один раз в режиме видео-доклата и все что я видел говорило об одном: где то лучше VMware, сразу за ним Xen, потом местами немного проседая но уверенно ищел KVM, и в самом конце плелся Hyper-V.
Hyper-V вырывался: 1. тем что если нужно пролицензировать кучу ОС Windows — то его минусы в производительности окупаются экономией на лицензировании. 2. Интеграция с системными службами на тех же Windows OS. 3. у него хорошо работает iSCSI из коробки без вообще каких либо танцев с бубном, драйверами и тд — что хорошо когда у тебя гипервизор обращается к VHD которая лежит на сетевой хранилке, которую можно тоже держать на Windows.
Производитель гипервизор а Xen к принципе на 15% выше во всем чем Hyper-V. Ну а во вторых: Xen вообще были пионеры в vGPU — они первые кто начал как-то работать с GPU в гипервизоре, а Nvidia пилит свои дрова одинаково хорошо для все производителей: VMware, Xen, Windows, минус ток что они проприетарные).
я знаю как работают нынешние api, и я не о том что трафик могут перехватить — я о том варианте когда вот предположим у вас найдут уязвимость в вашем сайте, сайт стоит на машине с certbot валидирующий по dns, смогут загрузить php shell и увидят конфиг certbot с ключами от dns api =) тут вы поймете где вы ошиблись, тут нужно трезво понимать что сам вебсервер не должен быть настроен на валидацию сертификатов, нужен отдельный proxy который будет валидировать dns, и делать https offloading — тогда хоть ключи от api даже при взломе сайта останутся в надежном месте. Через ключи api они будут делать с вашим dns все что заходят. По поводу
т.к. это всё таки Let's Encrypt, его вряд ли будут использовать те, кто действительно обеспокоен безопасностью своей организации
я с вами в корне не согласен: люди которые не обеспокоены своей безопасность — это те 50% обычного http трафика которые еще не юзают LetsEncrypt и для них нецелесообразно или дорого покупать сертификаты. Я вообще не вижу смысла покупать SSL сертификаты платить за «подтверждение» того что я это я, когда я и так без оплаты могу доказать что я это я. Единственный смысл приобретения сертификатов когда дело заходит не про обычные сертификаты: в случае если вам нужны сертификаты для подписи софта, или с расширенными параметрами такие как у платежных систем, банков и крупных организаций — которые кроме лейблов несут кучу юридической фичи типа «гарантий», «страховок» и прочего.
Все таки я считаю что верификация через через http безопаснее, так могут и контроль над DNS украсть — этот метод был разработан для дата центров которые предоставляют там всякие cPanel и тд, им он и вправду подходит, а если у вас у самих есть доступ к установке пакетов и их настройке — лучше это делать через http но если кто то настойчиво хочет вот эще hook только для dns.he.net: github.com/angel333/certbot-he-hook
Я уже написал по поводу бесплатного и платного, пример: Let's Encrypt, не все в мире однозначно. А по поводу внешнего IPv4 ~ за 2$ вы себе сможете взять нормальную статику у большинства провайдеров. =) И у вас и IPv4 будет как у человека, и IPv6 /64 or /48, ладненько, каждому свое
Вы думаете если вы будете кому то платить то они меньше будут собирать данные? Поверьте мне, как и с качеством услуг: цена это не показатель качества. Вы от Lets Encrypt тоже отказываетесь? — Они же на халяву сертификаты подписывают. А HE.net даёт на халяву потому что как и LE у них куча спонсоров которые заплатили за тебя.
P.S. — больше что Вова за вами никто следить не будет, а вы вон какие налоги платите каждый месяц
все равно ваш покупной сервер подключен будет к IPv6 с 70% вероятностью через HE.net >_< или гонять 90% трафика IPv6 через HE.net. Но теперь кроме HE.net вас будут отслеживать при желании еще й ISP вашего дата центра =), так что это все бессмысленно. Мало того у меня например есть статистика того как работает HE.net, и они предоставляют стабильные услуги (скорость и латенси пропускной полосы, и отсутствие downtim'ов), удобные функции для тех кто юзает их услуги: решение проблем тех клиентов у кого динамический IP, клиент сам может настраивать реверс лукап записи (PTR) в админ панели или через API. Есть интеграция с их DNS серверами. Таким ДЦ с VPC за 1$ не похвастается, а HE.net дают это все уже настроенное, проверенное и бесплатно, да й еще й нормально дают выбор к какому серверу вести туннель, расстояние к которому можно проверить перед тем как выбирать в качестве своего туннеля банальным ping запросом, и еще й имею свой iperf3 сервер для тестирования полосы.
Вот серьезно а чем tunnelbroker.net не угодили? Не вижу ничего негативного в использовании их как точки выхода IPv6.
А по поводу IPv6-to-IPv6 Network Prefix Translation то сам юзал, да костыль но рабочий.
Кейс: 2 WAN'a от разных ISP настроенных на failover, сделать BGP не могу потому что IPv6 не мои, а tunnelbroker.net, да и даже если бы они были моими это дорого и нецелесообразно в моем случае. Тут NPt пришелся как раз кстати.
для любого публичного довереного сертификата нужен домен, и что? Lets Encrypt это идеальное решение.
А по поводу домена: хз как в РФ, но на Украине есть pp.ua — бесплатный домен который нужно продлять раз в год через подтверждение через телеграм.
Дня обычных юзеров это возможно это удобное решение, и спорить не буду так как не пользовался. Но лично для меня: у меня глубокое недоверие к продуктам Yandex и Mail.ru. Раньше они себя очень плохо зарекомендовали, вот пример: ссылка. В changelog WebBrowserPassView:
Version 1.70: WebBrowserPassView now automatically detect the passwords of Yandex Web browser. Скорее всего это относится к той версии что еще с менеджером паролей от Chromium. А тестировать я не буду потому как все равно менеджер паролей в браузере мне не подходит по ряду причин:
1. он менее надежный: KeePass имеет историю паролей, и если что я могу вернуть случайно измененный пароль назад за два клика мышки. Так же KeePass хранится в Dropbox в котором есть версионирование, а плагин KeeAnywhere для работы с Dropbox сохраняет базу в Dropbox и еще хранит настраиваемое количество копий локально в нужном мне месте — а это дает мне гарантию того что если я потеряю доступ к Dropbox я не потеряю саму базу — ее 10 копий у меня на ПК, и если я забуду новый мастер пароль через даже десять дней или месяц, но буду помнить предыдущий я могу востановить более старую версию базы с резервной копии на ПК или Dropbox;
2. менее безопасный: я прочитал статью от Yandex и все равно AES-256-GSM это вам не ChaCha20. Да и если как то взломают учетку Yandex ваши пароли от туда могут просто удалить из-за злости того что не смогли с ними ничего сделать, хотя 2FA может тут спасти. С Dropbox есть 2FA да и если случится чудо и кто то как то его уведет будет еще локальная версия. Плюс с KeePass я уверен в том что пока база открыта пароли не могут быть прочитаны кем попало с оперативной памяти даже программой с правами администратора — украсть их можно только через DLL инъекцию и нативную функцию экспорта паролей, если база захлопнута с ней вообще ничего не сделать, и эти настройки я делаю сам. А как работает браузер Yandex не понятно, как долго он хранит базу паролей открытой и как работает защита от перехвата в оперативной памяти и тд.
3. и что самое главное он не универсальный: в отличии от менеджера паролей в браузере KeePass может хранить любые пароли: в поле URL может быть совсем пусто и это будет пароль не от веб-приложения, или быть указана ссылка на rdp:// или ssh:// etc.., а в настройках ассоциации указана программа для запуска с параметрами передачи логина\пароля и других кастомных полей, плюс можно хранить дополнительные атрибуты в паролях: файлы (например приватные сертификаты PGP\ OpenSSH ключи и тд, или конфигурации для тех же OpeVPN), или другие кастомные поля защищенные в памяти (для одноразовых паролей 2FA или для ключи API для доступа к каким либо сервисам).
Ваши подсчеты в корне не верны — вы даже в расчет не берете количество символов. Я в паролях где это возможно сейчас даже ASCII символы юзаю.
Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
Общеизвестный факт, не вижу чего паниковать, и не знаю ни одного браузера или почтового клиента который надежно хранит пароли от сохраненных в нем учетных записей. Сюда летят и Chrome (и все детища Chromium: Opera и тд) и Firefox и IE и клиенты Outlook, Thunderbird и тд. Банально берем Google и пишем кодовое слово: nirsoft. Запуском 2вух утилит получаем все пароли из вышеперечисленного софта:
WebBrowserPassView
Mail PassView
Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
суть в том что это не для админов серверов сообщение, а для пользователей браузеров за которыми через HSTS могут следить недоброжелательные хостеры веб-приложений пытающиеся «деанонимизировать» пользователей.
А против такой атаки на "идентификацию" не спасет плагин из серии HTTPS Everywhere? Я просто не совсем понял те хосты что не HSTS грузяться с сайта, у них получается и https версии нет, если да то плагин не поможет. Но с другой стороны чистишь полностью браузер и кеш HSTS тоже слетает. И "скрытый" идентификатор идёт лесомhttps://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp?hl=ru
Hyper-V вырывался: 1. тем что если нужно пролицензировать кучу ОС Windows — то его минусы в производительности окупаются экономией на лицензировании. 2. Интеграция с системными службами на тех же Windows OS. 3. у него хорошо работает iSCSI из коробки без вообще каких либо танцев с бубном, драйверами и тд — что хорошо когда у тебя гипервизор обращается к VHD которая лежит на сетевой хранилке, которую можно тоже держать на Windows.
Производитель гипервизор а Xen к принципе на 15% выше во всем чем Hyper-V. Ну а во вторых: Xen вообще были пионеры в vGPU — они первые кто начал как-то работать с GPU в гипервизоре, а Nvidia пилит свои дрова одинаково хорошо для все производителей: VMware, Xen, Windows, минус ток что они проприетарные).
Вы думаете если вы будете кому то платить то они меньше будут собирать данные? Поверьте мне, как и с качеством услуг: цена это не показатель качества. Вы от Lets Encrypt тоже отказываетесь? — Они же на халяву сертификаты подписывают. А HE.net даёт на халяву потому что как и LE у них куча спонсоров которые заплатили за тебя.
P.S. — больше что Вова за вами никто следить не будет, а вы вон какие налоги платите каждый месяц
А по поводу IPv6-to-IPv6 Network Prefix Translation то сам юзал, да костыль но рабочий.
Кейс: 2 WAN'a от разных ISP настроенных на failover, сделать BGP не могу потому что IPv6 не мои, а tunnelbroker.net, да и даже если бы они были моими это дорого и нецелесообразно в моем случае. Тут NPt пришелся как раз кстати.
А по поводу домена: хз как в РФ, но на Украине есть pp.ua — бесплатный домен который нужно продлять раз в год через подтверждение через телеграм.
Version 1.70: WebBrowserPassView now automatically detect the passwords of Yandex Web browser. Скорее всего это относится к той версии что еще с менеджером паролей от Chromium. А тестировать я не буду потому как все равно менеджер паролей в браузере мне не подходит по ряду причин:
1. он менее надежный: KeePass имеет историю паролей, и если что я могу вернуть случайно измененный пароль назад за два клика мышки. Так же KeePass хранится в Dropbox в котором есть версионирование, а плагин KeeAnywhere для работы с Dropbox сохраняет базу в Dropbox и еще хранит настраиваемое количество копий локально в нужном мне месте — а это дает мне гарантию того что если я потеряю доступ к Dropbox я не потеряю саму базу — ее 10 копий у меня на ПК, и если я забуду новый мастер пароль через даже десять дней или месяц, но буду помнить предыдущий я могу востановить более старую версию базы с резервной копии на ПК или Dropbox;
2. менее безопасный: я прочитал статью от Yandex и все равно AES-256-GSM это вам не ChaCha20. Да и если как то взломают учетку Yandex ваши пароли от туда могут просто удалить из-за злости того что не смогли с ними ничего сделать, хотя 2FA может тут спасти. С Dropbox есть 2FA да и если случится чудо и кто то как то его уведет будет еще локальная версия. Плюс с KeePass я уверен в том что пока база открыта пароли не могут быть прочитаны кем попало с оперативной памяти даже программой с правами администратора — украсть их можно только через DLL инъекцию и нативную функцию экспорта паролей, если база захлопнута с ней вообще ничего не сделать, и эти настройки я делаю сам. А как работает браузер Yandex не понятно, как долго он хранит базу паролей открытой и как работает защита от перехвата в оперативной памяти и тд.
3. и что самое главное он не универсальный: в отличии от менеджера паролей в браузере KeePass может хранить любые пароли: в поле URL может быть совсем пусто и это будет пароль не от веб-приложения, или быть указана ссылка на rdp:// или ssh:// etc.., а в настройках ассоциации указана программа для запуска с параметрами передачи логина\пароля и других кастомных полей, плюс можно хранить дополнительные атрибуты в паролях: файлы (например приватные сертификаты PGP\ OpenSSH ключи и тд, или конфигурации для тех же OpeVPN), или другие кастомные поля защищенные в памяти (для одноразовых паролей 2FA или для ключи API для доступа к каким либо сервисам).
Извиняюсь, прочитал LastPass, а подумал о KeePass.
Плюс вы не учитываете тот факт что в KeePass не один метод шифрования для всех БД. Почитайте про ChaCha20 и Argon и вы поймете что вы не правы. Вы сами хозяин своей БД и сами выбираете насколько много итераций на ней выставить.
WebBrowserPassView
Mail PassView
Ну в этой ситуации мы… просто наше это самое… мы уже… здесь наши полномочия все… окончены. Так что если вы такой же параноик как я: юзайте уникальные пароли на каждый сайт\сервис, используйте двухфакторку где это нужно если это возможно.
P.S. Сам пользуюсь KeePass хоть и знаю что и с него можно своровать пароли но куда сложнее: только если он находится в разблокированном состоянии через инъекцию библиотеки в процесс и вызова функции экспорта паролей в csv например — исходники на github проект KeeFarce. Но так как это инъекция, а не банальное считывание файла с %USERNAME%\AppData (так считываются пароли с бд браузеров) то такое поведение может хотя бы антивирус словить по эвристике и по сигнатурам если он есть.
А против такой атаки на "идентификацию" не спасет плагин из серии HTTPS Everywhere? Я просто не совсем понял те хосты что не HSTS грузяться с сайта, у них получается и https версии нет, если да то плагин не поможет. Но с другой стороны чистишь полностью браузер и кеш HSTS тоже слетает. И "скрытый" идентификатор идёт лесомhttps://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp?hl=ru