antoshkka20 мар 2015 в 06:38

Администрирование глазами C++ программиста

5 мин

57K

C++ *

+22

Комментарии 50

НЛО прилетело и опубликовало эту надпись здесь

TaHKucT 20 мар 2015 в 06:59

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

antoshkka 20 мар 2015 в 09:00

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

Дополнительными минусами будет падение производительности, возможность перехватить пароль и неработоспособность системы после сбоя (пока админ не введет пароль).

akamajoris 20 мар 2015 в 08:52

Подскажите, о чём пост?

dsx 20 мар 2015 в 19:09

Программисты познают системное администрирование. Есть ещё второй том -- «Сисадмины познают программирование». Жанр — саспенс-триллер. Уже который год зачитываюсь.

risik 20 мар 2015 в 11:11

Так а где C++? Надеюсь хоть серверная логика-то была написана на нем?

antoshkka 20 мар 2015 в 12:00

Нет, не была :)

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

saboteur_kiev 20 мар 2015 в 12:34

После стольких лет, почему я не знал что так можно с tail… :(

antoshkka 20 мар 2015 в 12:50

С 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.

sequence 23 мар 2015 в 05:45

Но ещё больше удовольствия вы получите от специализированных вещей, multitail например.

aml 20 мар 2015 в 16:44

А что будет в случае спуфинга? Если злоумышленник отправит по 10 SYN-пакетов с мульона разных адресов? У вас в iptables миллион правил окажется? Похоже на прекрасную атаку.

mickvav 21 мар 2015 в 21:47

Вот, как раз про это автор не раскрыл тему ipset

antoshkka 23 мар 2015 в 09:51

Если вы считаете, что 1М забанненых адресов много весят — то миллион айпи адрессов это чуть более 4мб оперативы. Ну ~20 мб вместе с ttl и временем получения пакетов. Не так уж и много.

Если у злоумышленника есть возможность контролировать сразу миллион машин — то у него будет десяток более простых способов нагадить. И iptables тут скорее всего не спасут.

aml 23 мар 2015 в 09:54

Дело не в том, сколько они весят. А в том, что на каждый входящий пакет машине придётся делать перебор миллиона записей в таблице iptables.
Чтобы отправить пакет с поддельным IP-адресом, контролировать машины не надо. ru.wikipedia.org/wiki/IP-%D1%81%D0%BF%D1%83%D1%84%D0%B8%D0%BD%D0%B3

antoshkka 23 мар 2015 в 10:05

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

aml 23 мар 2015 в 12:34

Почитал интернеты. Оказывается, есть классная штука — ipset. Но ее надо явно использовать. Если просто добавлять правило в iptables на каждый адрес, то будет тормозить при большом числе правил.

Gendalph 20 мар 2015 в 18:01

Ubuntu?
Ну тогда надо еще настроить ip6tables — ipv6 вам дали же?
А вот еще суперская вещь — byobu. Это обертка над tmux или screen, которая позволяет консольной сессии продолжаться даже если отвалится ssh.
А что использовалось для бана iptables? fail2ban какой-нибудь?

TaHKucT 20 мар 2015 в 18:07

Объясните пожалуйста человеку, не понимающему зачем нужен tmux, если есть screen, зачем нужен byobu?

dsx 20 мар 2015 в 19:12

И, заодно, понимающему, зачем нужен tmux, чем он в деталях отличается от screen, и пользовавшемуся обоими много лет.

khim 21 мар 2015 в 14:09

Если у вас есть screen, то tmux, в общем-то, не нужен. А вот на роутере у меня tmux потому что туда screen просто жалко ставить, уж очень места мало.

dsx 21 мар 2015 в 22:29

Я пользовался screen как основным средством мультиплексирования терминалов года три. Потом упёрся в его ограничения, расстроился и бросил совсем. Потом перешёл на tmux и с тех пор пользуюсь только им. Я как раз тот самый человек, у которого постоянно существует несколько сессий с множеством окон на нескольких разных машинах для выполнения разной работы, при этом сессии могут существовать месяцами. Я часть целевая аудитории этих программ. И я со всей ответственностью заявляю: tmux — это развитие идей screen в правильном направлении. Впрочем, в контексте отваливающихся SSH-соединений действительно всё равно чем пользоваться, хоть nohup.

d3m1gd 22 мар 2015 в 07:49

В контексте отваливающихся ssh соединений надо пользоваться mosh

dsx 22 мар 2015 в 13:59

Как только оно IPv6 научится, так сразу. А пока что не надо.

Gendalph 21 мар 2015 в 12:19

byobu — обертка, которая позволяет сделать screen или tmux более удобным. Мы юзаем screen (при первом запуске делаем byobu-select-backend и выбираем screen).

dsx 21 мар 2015 в 22:29

Это я в гугле прочитал. А в деталях?

Gendalph 21 мар 2015 в 23:13

Известные мне отличия минимальны — я почти не пользовался screen и не пользовался tmux.
А с byobu поступем так — после его установки на серверах и выбора бэкенда запускем byobu-enable, и после следующего логина сразу запускается screen с некоторыми базовыми показателями по системе: сколько есть обновлений, сколько занято памяти, процессора. Плюс добавляются бинды на F*, но там снова-таки нет никаких особенностей.
Собственно, то же самое делается и для tmux.

dsx 22 мар 2015 в 14:00

То есть, это для тех, кто не осилил .tmux.conf или .screenrc, без добавления каких-то уникальных полезных функций?

Gendalph 22 мар 2015 в 16:39

Похоже на то.

dimas 22 мар 2015 в 23:56

Если правильно помню:

screen, в отличие от tmux`а то ли до недавнего времени застыл в развитии, то ли просто медленно развивался.
у tmux`а лучше со сплитами
у tmux`а можно прицепиться к окнам не «отрывая» предыдущего прицепившегося

Сам долго сидел на screen`е и не видел особого смысла переходить на tmux, при том, что был уже конфиг для screen-щиков. Но приспичило мне получить 256 цветов в консоли. В скрине при этом то ли что-то отвалилось в консоли, то ли в vim`е, быстро разобраться не удалось… Ради интереса поставил tmux, все завелось с полпинка, еще где-то час заняло допилить конфиг до того, к чему привык со screen`ом, и все.

saboteur_kiev 23 мар 2015 в 09:39

screen устарел.
tmux — новый скрин. Больше комфорта и удобства. Поддержка современных терминалов улучшена.
Если вы активно пользуетесь скрин, просто попробуйте недельку попользоваться tmux и ответ у вас будет собственный.

НЛО прилетело и опубликовало эту надпись здесь

dsx 23 мар 2015 в 19:32

Не спасёт это от уязвимостей. 0-day уязвимость никто ботами применять не станет, она слишком ценная, её для направленных атак берегут.

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

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

Все мнимые неудобства исчезают после man ssh_config.

НЛО прилетело и опубликовало эту надпись здесь

dsx 24 мар 2015 в 13:06

А можно про эти основы где-то прочитать в конкретном месте? Ну там, учебник какой-то или статью в научном журнале?

НЛО прилетело и опубликовало эту надпись здесь

StirolXXX 21 мар 2015 в 11:51

… настолько мизерную, что она незаметна
… особенно если у вас веб сервер

максимум что будет это поиск rDNS у IP, что обычно отключается для ускорения логина.

ValdikSS 21 мар 2015 в 13:51

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

StirolXXX 21 мар 2015 в 13:56

пусть перебирают до посинения — авторизация по ключу.

не спорю — если делать то делать нормально: port knocking или vpn до сервера + ssh слушающий только на интерфейсе vpn итд.
речь о том, что делать это совсем не обязательно сейчас

Gendalph 21 мар 2015 в 21:27

А за vpn'ы всякие вам потом такое «спасибо» скажут — не сомневайтесь.
Я все же придерживаюсь мнения — лучше сменить порт и настроить какой-нибудь автобан.

Gendalph 21 мар 2015 в 21:25

Как к sshguard прикрутить защиту http auth (nginx/apache)?

ValdikSS 21 мар 2015 в 21:27

Прикрутите к нему как-нибудь log sucker

Gendalph 21 мар 2015 в 12:23

Есть куча ботов, которые не сканят все открытые порты, а ломятся в набор портов с интересующими их сервисами: 22, 3389, 5900 и пр., поэтому есть смысл менять дефолтный порт.
Есть также смысл использовать защиту от брутфорса (автоматический бан типа fail2ban).

НЛО прилетело и опубликовало эту надпись здесь

estum 21 мар 2015 в 14:58

Да-да, я как-то халтурил на одних товарищей, у них удаленно в нужный мне для работы терминал можно было попасть только через VNC, предварительно прокинув порт на другой сервак по ssh с овер 9000 указанных опций, которыми бы я никогда не воспользовался. При этом пароли были 123456, а в ssh было достаточно всего 2 ключа. Порты конечно же везде нестандартные. Ах, да, они еще наотрез отказывались пользоваться приватным git-репозиторием, ибо боялись за какую-то конфиденциальность, поэтому я вручную через всю эту жопу загружал им туда архивы каждого «коммита». Но зато какому-то неизвестному чуваку (т.е. мне) вообще без задней мысли выдали рутовые пароли. Wut?