Почему двухфакторная аутентификация не ухудшает безопасность?

Но техподдержка же не на честные глаза смотрит и не на уверенный тембр голоса, у них четкие правила. А во многих случаях (в крупных сервисах) вообще восстановление автоматическое, без участия человека.

Если телефон так надежен - зачем тогда пароль? Он только ухудшает безопасность.

Является ли файловая система - документоориентированной СУБД?

Где можно посмотреть определение, что такое "сетевой сервер второго рода"? Простое гугление не дало пока результата.

Является ли файловая система - документоориентированной СУБД?

Я сам могу сказать, что Нет. И даже могу, что Да.

Какие ваши доказательства?

Как сделать безопасное исполнение пользовательского кода (lambda, function as a service)?

поясните пожалуйста? Я про Firecracker не слышал раньше. На взгляд - выглядит, как то что надо. Это будет шустрее докера?

Где сисадмину хранить информацию?

Выбрал для себя вариант с gitlab wiki (но, наверное, и github wiki тоже подойдет)

Плюсы:
- приватный, доступ только у меня
- универсально, wiki markdown подходит почти для всего (хотя и для всего не очень удобно). Любое готово ПО будет с какими-то ограничениями и может быть какую-то часть там хранить не получится. А wiki все стерпит
- очень высокая надежность. Даже если грохнется гитлаб - копия есть у меня, обновляется одной командой и быстро. Даже если грохнется у меня - есть копия на гитлабе.

Как открыть www.dhl.ru curl'ом?

Да, спасибо! Работает. Интересно, что в вашем примере Accept* хидеры: Accept и Accept-Encoding и ни один из них нельзя убрать (перестанет работать). А в другом примере Accept-Language вместо них - тогда тоже работает.

Из дома и с makecloud.ru - работает.

Как открыть www.dhl.ru curl'ом?

Да, спасибо! Опытным путем выяснил, что можно сократить до:

curl -v 'http://www.dhl.ru/'   -H 'Connection: keep-alive'  -H 'User-Agent: Mozilla/5.0'  -H 'Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7'

Но это уже сокращать некуда, от убирания каждого заголовка все ломается. И User-Agent можно установить в zzz, например, а вот в curl нельзя - видимо, некоторые user-agent в черном списке.

Спасибо!

Как открыть www.dhl.ru curl'ом?

Так это вы немного другой сайт открыли (dhl.ru, а не www.dhl.ru). Он вам кинул редирект на www.dhl.ru, а этот www уже не открывается.

xenon@pi:/tmp $ curl -k https://dhl.ru/ -I
HTTP/1.0 301 Moved Permanently
Location: http://www.dhl.ru/
Server: BigIP
Connection: Keep-Alive
Content-Length: 0

xenon@pi:/tmp $ curl -k https://www.dhl.ru/ -I
^C

Да и если б все дело было в левом сертификате - то и браузер бы не открыл, и curl бы выругался, а там именно подвисание со стороны сервера.

Почему сайт ФСБ (fsb.ru) не использует https и как проверить отозванные сертификаты по имени?

CityCat4, Зная, как у нас спецслужбы могут нагнуть кого угодно, а весь крупный бизнес, включая Яндекс - так или иначе под ними ходит - думаю, в этом и проблема. Мне сложно представить выигранный суд "Яндекс против ФСБ". Добавить российский CA - наверное, не проблема ни для FF ни для Chrome/IE (ты ж сам пишешь, даже Польша и Турция есть). Но создать правильный CA - наверное, стоит больших денег, это ж не просто на коленке openssl'ем сертификаты генерить, а если его создашь, тут же умный майор из конторы смекнет, и убедительно попросит сделать какой-нибудь сертификат для gmail.com, например. А вслед за этим сертификат нашего российского CA со свистом вылетит из всех браузеров, и превратится в тыкву (с TrustWave была похожая история, возможно с Comodo. WoSign и StartCom и даже Symantec). Все деньги, вложенные в его создание - пропадут. Какой дурак будет так вкладываться? В первую очередь, все trusted CA - соблюдают довольно строгие правила от разработчиков браузеров, а в наших условиях это сложно.

С другой стороны - есть турецкий? Турция вроде тоже не светоч демократии. Но, кажется, турецкий залочен только для Турции:
The Turkish Government CA is name-constrained to a set of turkish toplevel domains - that is, .gov.tr, .k12.tr, .pol.tr, .mil.tr, .tsk.tr, .kep.tr, .bel.tr, .edu.tr and .org.tr.
https://wiki.mozilla.org/CA/Additional_Trust_Changes

Вот что еще реально интересно (и я бы почитал такую статью) - это про то, как становятся CA. Ведь они же есть, и появляются новые, значит, есть какая-то процедура, правила. Это вообще публичная схема или каждый раз индивидуально решается? Ну и про "как перестают быть CA" (разбор про тот же конфликт с TrustWave) тоже интересно было бы.

https://blog.mozilla.org/security/2016/10/24/distr...
https://blog.mozilla.org/security/2018/07/30/updat...

Почему сайт ФСБ (fsb.ru) не использует https и как проверить отозванные сертификаты по имени?

Чем дальше, тем страньше и страньше. Спасибо, интересное подтверждение!

Почему сайт ФСБ (fsb.ru) не использует https и как проверить отозванные сертификаты по имени?

Алексей Харченко, я прямо представляю IT-детектив, как какой-нибудь губернатор открывает kremlin.ru по http и читает новость, например, о своей отставке, и назначении нового врио губрнатора. На сайте fsb.ru читает, что он объявлен в федеральный розыск. И тут в кабинет входит сын лейтенанта Шмидта и делает ему интересное предложение... .

Почему сайт ФСБ (fsb.ru) не использует https и как проверить отозванные сертификаты по имени?

А если б мы раньше захотели заранее подготовиться - имея сертификат c fsb.ru (с публичным ключом, без приватного) - то могли бы иметь те данные, по которым можно проверить наличие сертификата в отозванных?

Через OCSP может как-то можно?

Вот еще нашел интересный "поисковик по сертификатам" (не знал о нем):
https://crt.sh/?q=habr.ru

но он вообще не знает был ли у kremlin.ru и fsb.ru сертификат. Это вообще странная версия, получается. Неужели, никогда и не было? Или как-то можно проверить, что был?

Как на Debian поставить PHP под другую архитектуру?

Именно это я и делаю - воссоздаю ту же (то есть "странную") конфигурацию на новой виртуалке, где нет зоопарка (но я хочу его там построить, чтобы безопасно откатить назад, и все проблемы получить на тестовой системе, а не на боевой). Сейчас ситуация лабораторно-чистая - предельно чистый debian amd64 на который надо поставить php i386.

Прямо по multiarch гайду ставится произвольный пакет (links) - все красиво и сразу. А вот php-cli - не ставится.

То, что на 64битной чистой системе поставится 64битный PHP я и не сомневаюсь - но это не позволит мне создать ту же проблемную ситуацию, чтобы красиво ее решить.

Как быстро переносить сайты и реконфигурировать вебсервер (Облако как безотказный сервер)?

Я согласен, у меня вопрос довольно пространный, от "как обновить конфиг апача при установке докер контейнера" (то что шелл-скриптом можно решить) и до "как все переделать и переехать в облако".

Вообще, сложилось впечатление, что по стоимости ресурсов - AWS штука довольно дорогая, если сравнивать с недорогими VPS хостингами (ну и я замерял бенчмарки - не слишком-то быстрее, хотя ощутимо дороже). Полную отдачу можно получить если каждое приложение/сайт с самого начала под облако разрабатывать?

Правильно ли понимаю, что облачный хостинг особо хорошо работает для компаний-приложений вроде Netflix, когда есть ОДНО свое сложное приложение (под облако), ну или небольшой их набор, и сотни типовых виртуальных серверов. Но не очень хорошо подходит для обратной задачи - когда есть сотни-тысячи простеньких linux/apache/mysql/php сайтов и нужно их надежно хостить? (так как для каждого маленького сайта стоматологического кабинета и автомагазина нужно прорабатывать его облачную архитектуру)

Как быстро переносить сайты и реконфигурировать вебсервер (Облако как безотказный сервер)?

АртемЪ, ну эту-то проблему я решил :-) Даже на хабре писал. Сайт с котиками работает даже при обесточивании дата-центра. (Сервер не работает, а сайт работает). За каждый час "умирает" два сервера, а сайт не падает.

Если в одном браузере смотреть - то из-за кеширования DNS запросов могут быть задержки, но все равно видно переключение. А если, например, в браузере, и затем в смартфоне и через сотовый интернет - то видно, что реальное переключение занимает секунды.

Правда, там ситуация проще, никакой базы, контент не меняется, ничего синхронизировать не надо, ну и все три сайта заранее подготовлены.

Можно ли в Linux запустить процесс при OOM?

Я согласен. Поэтому, наверное, для такого rescue shell нужно использовать busybox, чтобы все утилиты уже были включены. Хотя бы ls/cat/ps.

Для решения частной проблемы - так и надо поступать, как вы описали. Но меня заинтересовало общее решение. При разработке же не знаешь где соломку подстелить. Поэтому и подумалось, что, наверное, было б хорошо, чтобы ssh сразу имел такую возможность, чтобы хоть что-то сразу сделать в аварийной ситуации и быстрее понять ситуацию. Еще при установке сервера включить какую-нибудь опцию EnableRescueShell yes, и через три года она пригодится.

Есть ли базы данных, хранилища, бэкенды для конфиденциальных данных?

Безусловно. А вероятность, что в бэкенде будет уязвимость, она растет, по мере того, как мы нагружаем бэкенд всякими разными сложными функциями?

Есть ли базы данных, хранилища, бэкенды для конфиденциальных данных?

nApoBo3, кстати, не могли бы вы пояснить по моделям безопасности один вопрос? Они все сводятся к тому, что субъект либо имеет доступ к объекту (файлу, записи), либо не имеет, и это не меняется динамически.

Но есть ведь важная потребность ограничить количество. Операционистка в Сбербанке должна иметь доступ к записи любого из ста миллионов клиентов. Но при этом она явно не должна иметь возможности слить всю базу целиком, за смену должна иметь доступ к не более чем 20 клиентам, допустим. В какой модели безопасности это динамическое ограничение реализуется?

Есть ли базы данных, хранилища, бэкенды для конфиденциальных данных?

nApoBo3, Идея не в том, чтобы "давайте не будем фиксить SQL Injection'ы, а вместо этого вот так вот усложним архитектуру, чтоб от них не было больно", а в том, что гарантировать безопасность, увы, нельзя. И все методы создания безопасного кода при применении на выходе создают НЕбезопасный код. (просто иногда уязвимость не видно по многу лет). Есть ли проект, где не было уязвимостей вообще никогда?

Поэтому, могут быть разного рода уязвимости. Мы не можем исключать никакую. И в API, так же может быть уязвимость, согласен. Но в отличие от приложения с его кучей "декоративного" функционала и тоннами кода, отладить API более реально. Я бы скорее положился на "бездырочность" API с кодом из 500 строчек (и списком URLов из 10 строчек), чем на "бездырочность" всего приложения, с кодом на из 50 000 строк. Вероятность уязвимости ниже все таки.

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

Вы изобретаете велосипед
Именно про это и вопрос - какие уже готовые велосипеды есть, чтобы их купить (а лучше бесплатно взять)

Есть ли базы данных, хранилища, бэкенды для конфиденциальных данных?

Магия в том, что машина с фронтендом и машина с API/backend - это разные машины. root на фронтенде не дает никаких профитов для работы с бэкендом.