Search
Write a publication
Pull to refresh

Comments 50

UFO landed and left these words here
>Да, это звучит как анекдот про Неуловимого Джо, который хостеру даром не нужен, но всё равно…
Система виртуализации? Если это xen/kvm, то в принципе можно создать файлик, в нем создать шифрованную FS, и монтировать ее, но тут сразу 2 «но»:
1) При перезагрузке придется лазить ручками вводить пароль
2) Хостер управляем памятью. То есть чисто теоретически ему никто не сможет помешать читать и писать «вашу» память.

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

Дополнительными минусами будет падение производительности, возможность перехватить пароль и неработоспособность системы после сбоя (пока админ не введет пароль).
Программисты познают системное администрирование. Есть ещё второй том ­-- «Сисадмины познают программирование». Жанр — саспенс-триллер. Уже который год зачитываюсь.
Так а где C++? Надеюсь хоть серверная логика-то была написана на нем?
Нет, не была :)

Серверная логика на PHP и функциях PostgreSQL (не к чему лупить из С++ пушки по воробьям; PHP было более чем достаточно для решения задач). От С++ в статье лишь мой взгляд на вещи, да излишняя дотошность в мелочах.
После стольких лет, почему я не знал что так можно с tail… :(
С tail вообще забавная история:

Однажды я заметил что tail ест меньше ресурсов процессора чем less. Решившись заглянуть в исходники натолкнулся на фишку со множеством файлов на вход. Думал пасхалка… Оказалось что нет:
VirtualBox:~$ man tail

DESCRIPTION
       Print  the  last  10  lines of each FILE to standard output.  With more
       than one FILE, precede each with a header giving the file  name.
Но ещё больше удовольствия вы получите от специализированных вещей, multitail например.
А что будет в случае спуфинга? Если злоумышленник отправит по 10 SYN-пакетов с мульона разных адресов? У вас в iptables миллион правил окажется? Похоже на прекрасную атаку.
Вот, как раз про это автор не раскрыл тему ipset
Если вы считаете, что 1М забанненых адресов много весят — то миллион айпи адрессов это чуть более 4мб оперативы. Ну ~20 мб вместе с ttl и временем получения пакетов. Не так уж и много.

Если у злоумышленника есть возможность контролировать сразу миллион машин — то у него будет десяток более простых способов нагадить. И iptables тут скорее всего не спасут.
Дело не в том, сколько они весят. А в том, что на каждый входящий пакет машине придётся делать перебор миллиона записей в таблице iptables.
Чтобы отправить пакет с поддельным IP-адресом, контролировать машины не надо. ru.wikipedia.org/wiki/IP-%D1%81%D0%BF%D1%83%D1%84%D0%B8%D0%BD%D0%B3
Насколько я помню по документации, там адреса хранятся в хэш-таблице, а соответсвенно это не перебрать миллион записей, а за константное время получить ответ.
Почитал интернеты. Оказывается, есть классная штука — ipset. Но ее надо явно использовать. Если просто добавлять правило в iptables на каждый адрес, то будет тормозить при большом числе правил.
Ubuntu?
Ну тогда надо еще настроить ip6tables — ipv6 вам дали же?
А вот еще суперская вещь — byobu. Это обертка над tmux или screen, которая позволяет консольной сессии продолжаться даже если отвалится ssh.
А что использовалось для бана iptables? fail2ban какой-нибудь?
Объясните пожалуйста человеку, не понимающему зачем нужен tmux, если есть screen, зачем нужен byobu?
И, заодно, понимающему, зачем нужен tmux, чем он в деталях отличается от screen, и пользовавшемуся обоими много лет.
Если у вас есть screen, то tmux, в общем-то, не нужен. А вот на роутере у меня tmux потому что туда screen просто жалко ставить, уж очень места мало.
Я пользовался screen как основным средством мультиплексирования терминалов года три. Потом упёрся в его ограничения, расстроился и бросил совсем. Потом перешёл на tmux и с тех пор пользуюсь только им. Я как раз тот самый человек, у которого постоянно существует несколько сессий с множеством окон на нескольких разных машинах для выполнения разной работы, при этом сессии могут существовать месяцами. Я часть целевая аудитории этих программ. И я со всей ответственностью заявляю: tmux — это развитие идей screen в правильном направлении. Впрочем, в контексте отваливающихся SSH-соединений действительно всё равно чем пользоваться, хоть nohup.
В контексте отваливающихся ssh соединений надо пользоваться mosh
Как только оно IPv6 научится, так сразу. А пока что не надо.
byobu — обертка, которая позволяет сделать screen или tmux более удобным. Мы юзаем screen (при первом запуске делаем byobu-select-backend и выбираем screen).
Это я в гугле прочитал. А в деталях?
Известные мне отличия минимальны — я почти не пользовался screen и не пользовался tmux.
А с byobu поступем так — после его установки на серверах и выбора бэкенда запускем byobu-enable, и после следующего логина сразу запускается screen с некоторыми базовыми показателями по системе: сколько есть обновлений, сколько занято памяти, процессора. Плюс добавляются бинды на F*, но там снова-таки нет никаких особенностей.
Собственно, то же самое делается и для tmux.
То есть, это для тех, кто не осилил .tmux.conf или .screenrc, без добавления каких-то уникальных полезных функций?
Если правильно помню:
  • screen, в отличие от tmux`а то ли до недавнего времени застыл в развитии, то ли просто медленно развивался.
  • у tmux`а лучше со сплитами
  • у tmux`а можно прицепиться к окнам не «отрывая» предыдущего прицепившегося


Сам долго сидел на screen`е и не видел особого смысла переходить на tmux, при том, что был уже конфиг для screen-щиков. Но приспичило мне получить 256 цветов в консоли. В скрине при этом то ли что-то отвалилось в консоли, то ли в vim`е, быстро разобраться не удалось… Ради интереса поставил tmux, все завелось с полпинка, еще где-то час заняло допилить конфиг до того, к чему привык со screen`ом, и все.
screen устарел.
tmux — новый скрин. Больше комфорта и удобства. Поддержка современных терминалов улучшена.
Если вы активно пользуетесь скрин, просто попробуйте недельку попользоваться tmux и ответ у вас будет собственный.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
Не спасёт это от уязвимостей. 0-day уязвимость никто ботами применять не станет, она слишком ценная, её для направленных атак берегут.

Это какой-то фундаментальный закон вселенной или вы так себя успокаиваете?

Вам он доставит больше неудобств, чем злоумышленнику.

Все мнимые неудобства исчезают после man ssh_config.
UFO landed and left these words here
А можно про эти основы где-то прочитать в конкретном месте? Ну там, учебник какой-то или статью в научном журнале?
UFO landed and left these words here
… настолько мизерную, что она незаметна
… особенно если у вас веб сервер

максимум что будет это поиск rDNS у IP, что обычно отключается для ускорения логина.
В последней версии OpenSSH 6.8 rDNS Lookup отключен по умолчанию.
Ну и китайцы здорово перебирают пароли, я всем советую ставить sshguard. Он заметно меньше потребляет ресурсов, нежели более популярный fail2ban.
пусть перебирают до посинения — авторизация по ключу.

не спорю — если делать то делать нормально: port knocking или vpn до сервера + ssh слушающий только на интерфейсе vpn итд.
речь о том, что делать это совсем не обязательно сейчас
А за vpn'ы всякие вам потом такое «спасибо» скажут — не сомневайтесь.
Я все же придерживаюсь мнения — лучше сменить порт и настроить какой-нибудь автобан.
Как к sshguard прикрутить защиту http auth (nginx/apache)?
Есть куча ботов, которые не сканят все открытые порты, а ломятся в набор портов с интересующими их сервисами: 22, 3389, 5900 и пр., поэтому есть смысл менять дефолтный порт.
Есть также смысл использовать защиту от брутфорса (автоматический бан типа fail2ban).
UFO landed and left these words here
Да-да, я как-то халтурил на одних товарищей, у них удаленно в нужный мне для работы терминал можно было попасть только через VNC, предварительно прокинув порт на другой сервак по ssh с овер 9000 указанных опций, которыми бы я никогда не воспользовался. При этом пароли были 123456, а в ssh было достаточно всего 2 ключа. Порты конечно же везде нестандартные. Ах, да, они еще наотрез отказывались пользоваться приватным git-репозиторием, ибо боялись за какую-то конфиденциальность, поэтому я вручную через всю эту жопу загружал им туда архивы каждого «коммита». Но зато какому-то неизвестному чуваку (т.е. мне) вообще без задней мысли выдали рутовые пароли. Wut?
что мешает хостеру просмотреть мои файлы и данные

Может все-таки помешает как раз таки отказ от использования интерпретируемого языка :)
Зачем заставлять читающего постоянно кликать спойлеры с одним предложением? Неужели не нашли другого способа сделать отступление?
Предлагаю выпить ещё за здоровье ssh [-g] -D.
Теги, конечно, никто не читает, но поиск-то по ним, небось, работает…
Sign up to leave a comment.

Articles