Я говорил о не публичных устройствах: роутеры, свичи, контроллеры умных домов, внутренние сервера компаний, промышленное оборудование (где то на хабре была статья о поисковике уязвимость, там вроде даже измерительное оборудование турбины электростанции нашли) и тд. и тд. Доступ к таким устройствам должен быть как минимум ограничен по IP, а лучше вообще только через VPN. Потому что в куче подобных железок есть бекдоры и тонны багов (таких, как описанные в статье).
Тут правильнее использовать transfer вместо seize, т.к. seize это принудительный захват схемы и возможна ситуация, когда бывший владелец схемы будет считать себя таковым после seize.
Применяется seize только при потери владельца роли и/или невозможности сделать transfer.
Стоит ли написать статью-мануал о своем скрипте бэкапа на python (сейчас похоже только ленивый не пишет свои велосипеды на питоне;))? Умеет делать дифы файловой системы, lvm, email отчеты и прочие плюшки.
Потому что насколько я помню есть теория о том, что в точке торможения такого корабля будет происходить уничтожение солнечной системы.
Было бы обидно прилететь на таком корабле в нашу солнечную систему и выяснить, что теория верна.;)
Вы используете х86 железо или их роутерборды? DNS server и OpenVPN это больная тема, даже не напоминайте ;)
А OpenWrt на чем крутите? Обычный х86 или спец роутерборды на х86 или на других архитектурах?
Если железо не стандартное 86е, то откуда берете прошивки?
Спасибо.
1) Мне кажется, что лучше все таки использовать стандартное средство. Unix-way'но.
2) Монтирование по UUID настраивается легко, отключить правило udev так-же просто. Про время отклика вы ошибаетесь, ваш скрипт отработает когда устройство появиться в /dev, а появится оно там тогда, когда отработает udev. Ну и зачем нагружать проц постоянным циклом (хоть он почти ничего и не потребляет).
Опять же имхо, выйдет гораздо гибче. Можно фильтровать не только по uuid, но и по моделям, вендору и тд.
Извините, если прозвучит резко, но статья состоит из воды чуть менее, чем полностью. Все таки хабр технический ресурс и хотелось увидеть технический, а не маркетинговый обзор. Где например информация о скорости работы с диском, многие NAS не дотягивают и до 60 Мб/сек. Хотелось узнать, как обстоят дела у этого. Или например тест скорости usb 3.0. Ну и другие тех. детали.
Тоже не очень понял смысла сего действа. Если вы указываете для vnc сервера порт выше 1024го, то к нему (этому порту) может подключиться любой пользователь, не обязательно root. Создаем отдельного пользователя, даем ему только право ssh входа и биндинга портов. На каждую виртуалку ставим пароль (можно через вирт-менеджер), vnc слушает только лупбек. Что бы подключиться к консоли коннектимся по ssh коммандой ssh user@host -L 5900:127.0.0.1:5945, где 5945- порт нужной консоли, указывается в вирт-манеджере. И коннектимся vnc клиентом на 127.0.0.1:5900, вводим пароль и вуаля.
Подразумевается, что все действия делаются на «ноде виртуализации» ( где стоит libvirtd, в данном случае это CentOS 6 ) и selinux отключен. Выполняем в консоли:
Не очень это хорошо, selinux не просто так сделан. Он призван минимизировать ущерб безопасности от дыр в приложениях, ну и ограничить сами приложения.
Это возможно, но это должен быть троян, который специально охотится на базы keepass'a. Он должен скейлогить пароль и угнать файл базы. И конечно безопастность должна обеспечиваться комплексом мер (антивирус, руки не из задници и тд). Серебрянной пули не существует.
Если мы говорим о взломе брутфорсом пароля от базы, то во первых нужно, что бы она оказалась у злоумышленника (троян). Во вторых естественно база должна быть защищена сильным паролем, подбор которого невозможен или экономически не выгоден.
[зануда]Оба пароля не надежны. Один ламается брутфорсом, 2ой подбором по словарю.
Имхо нужно использовать пароли Gi702X1eh9X5ywGVIgN6. И для их хранения менеджер паролей (keepass, lastpass). Плюс такого подхода еще и в том, что к каждому сервису свой пароль. Взлом ресурса не компрометирует аккаунты на других ресурсах [/зануда]
Видимо имеються в виду их новые L3 свитчи. Внутри routeros 3 уровня, умеет роутить, файрволл и тд. В общем обычный роутер без спец фич, типа MPLS, метароутера и тд (лучше уточнить на офф сайте). Есть модели с беспроводным интерфейсом, правда насколько я помню только bgn.
Сам тоже пользуюсь микротиком дома, тоже подкупила стабильность в купе с отличной функциональностью (правда за некоторые функции разрабам надо пинков отвешать, днс сервер умеет только кешировать запросы, внесение своих записей на уровне /etc/hosts, openvpn сервер и клиент работают на половину).
Я тоже достаточно долго мучился с тонкой настройкой самбы на убунте, получал 60-70Мб/с максимум. Плюнул, поставил CentOS и получил 90-110 Мб/с.
А 60Мб/с между виртуалками (если они на одном хосте) выглядит и правда маловато.
Тут правильнее использовать transfer вместо seize, т.к. seize это принудительный захват схемы и возможна ситуация, когда бывший владелец схемы будет считать себя таковым после seize.
Применяется seize только при потери владельца роли и/или невозможности сделать transfer.
Было бы обидно прилететь на таком корабле в нашу солнечную систему и выяснить, что теория верна.;)
А OpenWrt на чем крутите? Обычный х86 или спец роутерборды на х86 или на других архитектурах?
Если железо не стандартное 86е, то откуда берете прошивки?
Спасибо.
2) Монтирование по UUID настраивается легко, отключить правило udev так-же просто. Про время отклика вы ошибаетесь, ваш скрипт отработает когда устройство появиться в /dev, а появится оно там тогда, когда отработает udev. Ну и зачем нагружать проц постоянным циклом (хоть он почти ничего и не потребляет).
Опять же имхо, выйдет гораздо гибче. Можно фильтровать не только по uuid, но и по моделям, вендору и тд.
Не очень это хорошо, selinux не просто так сделан. Он призван минимизировать ущерб безопасности от дыр в приложениях, ну и ограничить сами приложения.
Если мы говорим о взломе брутфорсом пароля от базы, то во первых нужно, что бы она оказалась у злоумышленника (троян). Во вторых естественно база должна быть защищена сильным паролем, подбор которого невозможен или экономически не выгоден.
Имхо нужно использовать пароли Gi702X1eh9X5ywGVIgN6. И для их хранения менеджер паролей (keepass, lastpass). Плюс такого подхода еще и в том, что к каждому сервису свой пароль. Взлом ресурса не компрометирует аккаунты на других ресурсах [/зануда]
Сам тоже пользуюсь микротиком дома, тоже подкупила стабильность в купе с отличной функциональностью (правда за некоторые функции разрабам надо пинков отвешать, днс сервер умеет только кешировать запросы, внесение своих записей на уровне /etc/hosts, openvpn сервер и клиент работают на половину).
А 60Мб/с между виртуалками (если они на одном хосте) выглядит и правда маловато.
Они не откажутся от ipv4 пока хотя-бы 1-5% клиентов поддерживает только его.