Важно помнить одно правило, что сис. админу надо уметь работать удаленно.
При работе с удаленными объектами надо задумываться о следующем:
1. Управление должно осуществляться по безопасным каналам связи.
2. Управление должно быть даже при очень плохом канале.
Первое требование оно простое. Я не доверяю каналу связи и хочу иметь возможность управлять сервером из любой точки мира. Почему из любой? А вдруг ты на Камчатке, а я в Москве. Всяко бывает. И бывает так, что подключаешься к халявному вайфаю, а у человека там tcpdump во всю играет. Вот твой пароль от сервера уже и у него. А значит и сервер его. Т.е. хочется иметь возможность авторизовываться и сообщать команды по шифрованному соединению.
Второе требование ещё проще. Я поехал в поездку и у меня из "ентернетов этих" только gprs. Да ещё и связь на одно деление. Вот тут сразу отпадают citrix, radmin, remote desktop аки присутствую в огромном количестве в виндоузе. Понятно, что текстовые команды тут на высоте. И дублировать на несколько серверов действия - легко.
За сим хочу представить такую вещь как ssh - security shell.
Разделяется она на две части. Нет не мужскую и женскую. Клиентскую и серверную.
Работают с этой штукой так же как и в обычной консоли, правда к удаленной консоли надобно нам подключиться:
ssh icegreg@example.com
Вот пользователь icegreg запрашивает подключению к серверу по адресу example.com. И запрашивает по 22 порту. Что такое порт? Приведу аналогию:
вот звоним мы в какую-нибудь контору. номер телефона - это адрес хоста. А нам в ответ говорят наберите добавочный номер. Вот добавочный номер и будет портом. И тот кто нам ответит на другом конце - сервер. Вот такая простая аналогия.
Собственно после этой команды останется только ввести пароль и всё. Можно работать как в обычной консоли. Причем канал успешно зашифрован, так что пусть пытаются перехватить.
Настроек и дополнительных опций у ssh целая телега.
например ssh -X icegreg@example.com firefox
Запустит команду firefox на удаленном сервере и транслирует все запросы графического сервера на локальную машину. Т.е. будем работать в firefox, только будет он серверным.
ssh -L 4899: 192.168.1.2:4899 icegreg@example.com -Nf
если example.com так же подключен к сети 192.168.1.0/24 то он пробросит через себя все данные к порту 4899 компьютера 192.168.1.2 и обращаться к этому порту можно будет на прямую из локальной машины, по адресу 127.0.0.1:4899, а -Nf не откроет нам консоль.
Вкусностей много. Например можно сделать авторизацию только по ключам, без паролей.
Но минусы как всегда есть.
Если ты поднял этот сервер у себя на внешнем сервере, то готовься, что тебя начнут брутфорсить.
Т.е. будет валить гигантское кол-во запросов на авторизацию по справочникам.
Т.е. твои пароли не должны быть легкими и стоит в любом виде запретить пользователя root. Т.к. это точно единственно известный пользователь в системе.
А так же не давать больше 3-5 попыток авторизации на сервере.
Уф сколько всего. А теперь если подумать.
Вот веб-служба работает на 80 порту по умолчанию. ДНС на 53. ftp на 21/20.
Но это популярные общественные сервисы, а наш ssh нужен только админам.
А теперь давай подумаем. Раз атака работает автоматически и по порту 22, то если мы перекинем сервис ssh на 8022 или 9022, то и автоматический сервис по обнаружению ssh уже до нас не доберётся. И не будет атак с подбором, и не надо ставить fail2ban, для бана ip-адресов.
А т.к. пользоваться будет только узкий круг, то можно сказать всем, что по умолчанию у нас 8022. И всё. Но всё таки пароль надо сделать сильным.
Для того, что бы сервер стал работать по порту 8022
надо в файле /etc/ssh/sshd_config
строку: # Port 22
заменить на: Port 8022
и перезапустить сервер
/etc/init.d/ssh restart
Вот теперь, если зайдем на наш сервер, то ssh не зайдет.
Т.к. стучится он на порт 22, а ответа там нет.
тут есть два варианта
ssh icegreg@example.com -p 8022
или же поправить порт по умолчанию в файле /etc/ssh/ssh_config
И так же указать: Port 8022
В общем таким способом наш лог-файл /var/log/auth.log перестанет разрастаться прямо на глазах.
P.S.: хотя профит в fail2ban по ssh тоже есть :) Но он уже для профи так сказать.
При работе с удаленными объектами надо задумываться о следующем:
1. Управление должно осуществляться по безопасным каналам связи.
2. Управление должно быть даже при очень плохом канале.
Первое требование оно простое. Я не доверяю каналу связи и хочу иметь возможность управлять сервером из любой точки мира. Почему из любой? А вдруг ты на Камчатке, а я в Москве. Всяко бывает. И бывает так, что подключаешься к халявному вайфаю, а у человека там tcpdump во всю играет. Вот твой пароль от сервера уже и у него. А значит и сервер его. Т.е. хочется иметь возможность авторизовываться и сообщать команды по шифрованному соединению.
Второе требование ещё проще. Я поехал в поездку и у меня из "ентернетов этих" только gprs. Да ещё и связь на одно деление. Вот тут сразу отпадают citrix, radmin, remote desktop аки присутствую в огромном количестве в виндоузе. Понятно, что текстовые команды тут на высоте. И дублировать на несколько серверов действия - легко.
За сим хочу представить такую вещь как ssh - security shell.
Разделяется она на две части. Нет не мужскую и женскую. Клиентскую и серверную.
Работают с этой штукой так же как и в обычной консоли, правда к удаленной консоли надобно нам подключиться:
ssh icegreg@example.com
Вот пользователь icegreg запрашивает подключению к серверу по адресу example.com. И запрашивает по 22 порту. Что такое порт? Приведу аналогию:
вот звоним мы в какую-нибудь контору. номер телефона - это адрес хоста. А нам в ответ говорят наберите добавочный номер. Вот добавочный номер и будет портом. И тот кто нам ответит на другом конце - сервер. Вот такая простая аналогия.
Собственно после этой команды останется только ввести пароль и всё. Можно работать как в обычной консоли. Причем канал успешно зашифрован, так что пусть пытаются перехватить.
Настроек и дополнительных опций у ssh целая телега.
например ssh -X icegreg@example.com firefox
Запустит команду firefox на удаленном сервере и транслирует все запросы графического сервера на локальную машину. Т.е. будем работать в firefox, только будет он серверным.
ssh -L 4899: 192.168.1.2:4899 icegreg@example.com -Nf
если example.com так же подключен к сети 192.168.1.0/24 то он пробросит через себя все данные к порту 4899 компьютера 192.168.1.2 и обращаться к этому порту можно будет на прямую из локальной машины, по адресу 127.0.0.1:4899, а -Nf не откроет нам консоль.
Вкусностей много. Например можно сделать авторизацию только по ключам, без паролей.
Но минусы как всегда есть.
Если ты поднял этот сервер у себя на внешнем сервере, то готовься, что тебя начнут брутфорсить.
Т.е. будет валить гигантское кол-во запросов на авторизацию по справочникам.
Т.е. твои пароли не должны быть легкими и стоит в любом виде запретить пользователя root. Т.к. это точно единственно известный пользователь в системе.
А так же не давать больше 3-5 попыток авторизации на сервере.
Уф сколько всего. А теперь если подумать.
Вот веб-служба работает на 80 порту по умолчанию. ДНС на 53. ftp на 21/20.
Но это популярные общественные сервисы, а наш ssh нужен только админам.
А теперь давай подумаем. Раз атака работает автоматически и по порту 22, то если мы перекинем сервис ssh на 8022 или 9022, то и автоматический сервис по обнаружению ssh уже до нас не доберётся. И не будет атак с подбором, и не надо ставить fail2ban, для бана ip-адресов.
А т.к. пользоваться будет только узкий круг, то можно сказать всем, что по умолчанию у нас 8022. И всё. Но всё таки пароль надо сделать сильным.
Для того, что бы сервер стал работать по порту 8022
надо в файле /etc/ssh/sshd_config
строку: # Port 22
заменить на: Port 8022
и перезапустить сервер
/etc/init.d/ssh restart
Вот теперь, если зайдем на наш сервер, то ssh не зайдет.
Т.к. стучится он на порт 22, а ответа там нет.
тут есть два варианта
ssh icegreg@example.com -p 8022
или же поправить порт по умолчанию в файле /etc/ssh/ssh_config
И так же указать: Port 8022
В общем таким способом наш лог-файл /var/log/auth.log перестанет разрастаться прямо на глазах.
P.S.: хотя профит в fail2ban по ssh тоже есть :) Но он уже для профи так сказать.
