Вы думаете, если зарплата вебмастера будет 150 тысяч рублей, то кол-во профессионалов в госорганах увеличится? Отнюдь, увеличится кол-во «племянников».
Флудить нужно для оценки качества линии связи. Операция выполняется после ремонтно-восстановительных работ самым низкооплачиваемым персоналом, часто — с антисоциальными наклонностями. Стандартными пингами выявлять потери менее 1% не очень удобно.
На вопрос «в чём именно принципиальная разница всё-таки разных вещей» я ответить затрудняюсь. Извините.
«Ой, я не в том окошке нажала» — сказала одна девушка перед тем, как её уволили за то, что она обнулила лицевые счета всех абонентов… А ведь девушке говорили — «Никогда, слышишь — НИКОГДА не оставляй открытой консольку базы данных, которую ты администрируешь».
Давайте упростим тему — сделаем вид, что про LDAP я не говорил. Он просто добавляет гибкости к sudo, у которой этой гибкости уже и так много.
Для моих целей гибкости authorized_keys оказалось недостаточно, и этого аргумента мне достаточно. Про бэкапы — первый вопрос из трёх заданных, и только для него был получен ответ. А, как я уже говорил, у меня в запасе есть ещё много вопросов, ответом на которые является «sudo», а не «authorized_keys». И не такие уж эти вопросы глупые — все возникли по ходу жизни, а не «от балды».
Для начала хватит, но я не начинающий. Если подскажете способ делегировать доступ лучше или так же, как sudo, но не имеющий перечисленных недостатков — буду благодарен. Не подскажете — буду и дальше рисковать, и пользоваться sudo. Не привыкать, каждый день рискую: едой можно подавиться, водой захлебнуться :)
segoon, это не только Вам лично, а в целом о дикуссии — вместо обмена позитивным опытом началось ругание sudo/suid и других механизмов управления доступом, которые плохи тем, что ругающие их просто «ниасилили».
«command=» — спусковой крючок для выполнения команд. Годный, но не гибкий механизм.
sudo — способ делегирования доступа. Мне и моим коллегам это позволяет выборочно повышать привилегии сотрудникам, которые не должны иметь неограниченного (рутового) доступа. Тоже годный, но более сложный/гибкий.
sudo-ldap — тоже тема, но не про авторизацию. Не pam-ldap, и не nss-ldap.
Спорно. Если честный и злоумышленник брутфорсят с одного IP, то должен быть кто-то ответственный за использование этого IP.
Если честный — юзер, а злоумышленник — вирус на компе юзера, то виноват всё равно юзер.
Если оба за прячутся за NAT — будут интересные диалоги с тем, кто делает NAT — вероятно, провайдером.
Если как-то хитро злоумышленнику удалось воспользоваться IP честного — виноват честный (хотя он же и пострадал): не обеспечил свою безопасность.
Могут быть ситуации с сознательным искажением src IP, но где профит?
Кончайте придумывать глупые ответы, глупые вопросы придумывать проще. Получайте — как быть с:
tcpdump -i ath0
tcpdump: ath0: You don't have permission to capture on that device
(socket: Operation not permitted)
ping -i 0.01 localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
ping: cannot flood; minimal interval, allowed for user, is 200ms
Все требуют рутового доступа, но могут использоваться «админами на час» для диагностики сети, например.
А как быть, если названия копируемых файлов меняются, и вписать их в скрипт нельзя?
Если админов много, но с головой — один, то ему при помощи sudo будет удобно делегировать доступ. Особенно, если безголовые часто меняются. sudo — наше всио, если правильно приготовить.
Есть ещё sudo-ldap всякие — тоже неспроста, наверно…
iptables умеет ограничивать кол-во соединений в секунду/минуту/… и устанавливать допустимый burst. Например — с одного IP не более 10 соединений в первую минуту, не более 1 в следующие сутки. Брутфорсерам это почему-то не нравится, а мне работать не мешает.
В сислог записать таких брутфорсеров с правильным префиксом, iptables тоже умеют.
Какая польза от юзера, у которого шеллом стоит /bin/false?
Для рута нужно отключать вход по паролю, но оставлять вход по ключу, если это необходимо.
Зачем нужен вход по ключу, и почему он предпочтительнее, можно прочитать в man authorized_keys, /AUTHORIZED_KEYS FILE FORMAT. Например, вот такая вкусность:
from="pattern-list"
Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in
the comma-separated list of patterns. See PATTERNS in ssh_config(5) for more information on patterns.
В понедельник я собеседовал претендента на должность, не связанную с программированием. Тем не менее, в резюме значилось «знание C++», и я задал задачу: «Нужна программа, выводящая строку на экран. Не важно — какую, придумайте удобную Вам. Придумали? Ок, напишите хотя бы одну строку программы.»
Запаслись попкорном? Зря. Продолжения нет, рассказ кончился.
Рация опять на бронепоезде… Уточню вопрос: зачем нужны статьи, описывающие некрасивый интерфейс, которым никто не пользуется? Начнут пользоваться -> начнут жаловаться, просить красивый. Что, собственно, уже произошло.
Понятно, что кое-кто интерфейсом пользуется, и если бы был выбор, то этот кое-кто предпочёл бы красивый интерфейс некрасивому.
Объяснение «оптимизировал производительность (или что там под капотом можно улучшать), на рюшечки времени не хватило» — объясняет.
Объяснение «а что вы хотели за такие деньги?» — объясняет.
Объяснение «а вам это не нужно» — тоже объясняет. Объясняет, что автор объяснения не нуждается в мнении оппонента, по причине авторской упёртости самодостаточности.
На вопрос «в чём именно принципиальная разница всё-таки разных вещей» я ответить затрудняюсь. Извините.
Для моих целей гибкости authorized_keys оказалось недостаточно, и этого аргумента мне достаточно. Про бэкапы — первый вопрос из трёх заданных, и только для него был получен ответ. А, как я уже говорил, у меня в запасе есть ещё много вопросов, ответом на которые является «sudo», а не «authorized_keys». И не такие уж эти вопросы глупые — все возникли по ходу жизни, а не «от балды».
В этой ситуации нужно:
- гордиться собой и важничать
- подумать об отделении услуг от безопасности — погрузить сервер в DMZ, безопасность которой обеспечивается уже не подручными средствами
Второе предложение уже за рамками статьи, а первое — неэффективно.«command=» — спусковой крючок для выполнения команд. Годный, но не гибкий механизм.
sudo — способ делегирования доступа. Мне и моим коллегам это позволяет выборочно повышать привилегии сотрудникам, которые не должны иметь неограниченного (рутового) доступа. Тоже годный, но более сложный/гибкий.
sudo-ldap — тоже тема, но не про авторизацию. Не pam-ldap, и не nss-ldap.
Если честный — юзер, а злоумышленник — вирус на компе юзера, то виноват всё равно юзер.
Если оба за прячутся за NAT — будут интересные диалоги с тем, кто делает NAT — вероятно, провайдером.
Если как-то хитро злоумышленнику удалось воспользоваться IP честного — виноват честный (хотя он же и пострадал): не обеспечил свою безопасность.
Могут быть ситуации с сознательным искажением src IP, но где профит?
- tcpdump -i ath0
- ping -i 0.01 localhost
Все требуют рутового доступа, но могут использоваться «админами на час» для диагностики сети, например.А как быть, если названия копируемых файлов меняются, и вписать их в скрипт нельзя?
Если админов много, но с головой — один, то ему при помощи sudo будет удобно делегировать доступ. Особенно, если безголовые часто меняются. sudo — наше всио, если правильно приготовить.
Есть ещё sudo-ldap всякие — тоже неспроста, наверно…
Угадайте второй вопрос команды ssh-keygen без доп. опций.
Архив — можно, но не полезно: ключи маленькие.
В сислог записать таких брутфорсеров с правильным префиксом, iptables тоже умеют.
- заломав рута, ты получаешь рута
- заломав юзера, ты рута не получаешь
Какая польза от юзера, у которого шеллом стоит /bin/false?Для рута нужно отключать вход по паролю, но оставлять вход по ключу, если это необходимо.
Зачем нужен вход по ключу, и почему он предпочтительнее, можно прочитать в man authorized_keys, /AUTHORIZED_KEYS FILE FORMAT. Например, вот такая вкусность:
from="pattern-list" Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in the comma-separated list of patterns. See PATTERNS in ssh_config(5) for more information on patterns.Запаслись попкорном? Зря. Продолжения нет, рассказ кончился.
упёртостисамодостаточности.