Название: Linux Отправлено: tFF от Апрель 20, 2006, 18:32:47 Код: netstat -l -p Linux System Files (http://ka1fsb.home.att.net/linuxsys.html) System run levels and init.d scripts (http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit) (from: Debian Policy Manual (http://www.debian.org/doc/debian-policy/)) Unix runlevels (http://en.wikipedia.org/wiki/Runlevel) APT HOWTO (Управление пакетами Debian) (http://www.debian.org/doc/manuals/apt-howto/index.ru.html#contents) 25+ Useful Linux and Unix Cheat Sheets (http://www.techieblogger.com/2009/10/linux-unix-ubuntu-solaris-cheat-sheets.html) Название: SSH Отправлено: tFF от Сентябрь 24, 2009, 23:42:26 соединение без пароля с доверенным ключом
http://webiteam.ru/2009/05/sozdanie-doverennogo-ssh-klyucha/ Цитировать Решая различные задачи довольно часто приходиться соединятся по ssh с удаленными серверами. От банального shell доступа, экспорта из svn и sftp до синхронизации данных через rsync (об этом поговорим отдельно). И каждый раз вводить пароль доступа согласитесь – очень не удобно. И что бы облегчить юзверям жизнь была придумана схема rsa-ключей. Создав однажды ключ, и добавив его в доверенные ключи на сервере, мы сможем соединятся с ним(с сервером) не вводя пароль. Первое что нам понадобится это сгенерировать rsa ключ. Делаем это при помощи команды: Код: :~$ ssh-keygen Первое что предложат нам сделать, это выбрать путь для сохранения ключа. По умолчанию это /home/user/.ssh/id_rsa. Это ключ используется при ssh соединении если не указан иной. Но мы можем указать другой, к примеру /home/user/.ssh/id_rsa_myserver. Далее у нас спросят пароль для доступа к ключу, но мы оставим его пустым (иначе придется вводить его при каждом соединении). Ключ у нас есть! Теперь нужно его добавить в доверительные на сервере. Выполняем для этого: Код: :~$ ssh-copy-id -i /home/user/.ssh/id_rsa_myserver user@server.ru и вводим пароль доступа от учетной записи на сервере. Все готово! Можно заходить на сервер без пароля, достаточно указать при подключении путь до ключа. Код: :~$ ssh -i /home/user/.ssh/id_rsa_myserver user@server.ru Если был сгенерирован ключ по умолчанию, то вообще ничего указывать не нужно. Вот полный лог всех действий: Код: :~$ ssh-keygen Название: Backup Отправлено: tFF от Сентябрь 26, 2009, 00:56:53 Backup TOC (http://www.debianhelp.co.uk/backup.htm)
Backup using dd (http://www.debianhelp.co.uk/ddcommand.htm) Backup using tar (http://www.debianhelp.co.uk/tarbackup.htm) Код: #!/bin/sh -e Better: Код: #!/bin/sh -e Название: TMPFS and RAMFS Отправлено: tFF от Декабрь 12, 2009, 17:36:24 Store log files in memory:
http://ohioloco.ubuntuforums.org/showthread.php?t=1305192 http://www.howtoforge.com/storing-files-directories-in-memory-with-tmpfs http://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/ Название: Основы безопасности Отправлено: tFF от Январь 08, 2010, 00:47:18 http://quizz.bhome.ru/448-osnovy-bezopasnosti-linux/#more-448
Цитировать Обсудим основы безопасности в Linux. Знаете, я не заморочен ею до паранойи, но сталкивался со взломом серверов и последствиями. На серверах и рабочих станциях под Windows пока не буду останавливаться, хотя мне и там есть, что сказать, я про сервера под альтернативными ОС, хотя, знаете ли, это Windows – альтернативная ОС для сервера. Итак, у нас есть Linux-сервер, стоит он где-то. Где-то – это может быть на работе, дома, VPS или VDS в дата-центре. Операционную систему Linux поставили, открыли доступ по ssh, сейчас собираемся начать работать. Только для начала выполним следующие процедуры: 1. Это прям самое базовое, про что исписали половину интернета для IT-специалистов самой разной руки: создадим для себя пользователя, отличного от рута (ну да, в Ubuntu рута по-умолчанию нет, поэтому Ubuntu это не очень касается), а в файле /etc/ssh/sshd_config в опции PermitRootLogin поставим No. Этим мы уже уберем 60% вероятности того, что нас поломают через тривиальный брутфорс. 2. Обновите программное обеспечение сервера через пакетный менеджер. 3. Всем пользователям, который не нужен shell-доступ, а только всякие ftp в качестве шелла поставим /bin/nologin. Не нужно, значит не положено. 4. Уволился сотрудник так или иначе имеющий аккаунт на сервере – отключаем. Даже если вы расстались лучшими друзьями – мало ли чего он там натворит. 5. Еще я сталкивался с таким моментом, причем сразу было не очень очевидно, откуда потекло: человека уволили, пользователи как прежде работали со всякими своими сервисами с /bin/nologin, в один день одному из сотрудников технического отдела дали доступ к sh и sudo, в тот момент и начались проблемы. Оказалось, что свой пароль сотрудник не менял в течение года с лишним, а уволенный его знал. Так что меняйте свои пароли. Хотя бы раз в три месяца. 6. Используйте sudo. Это лучше, когда административный доступ нужен больше, чем двум it-специалистам. 7. Установите fail2ban: он на 39.99 из оставшихся 40 процентов защитит Вас от брутфорса с помощью обычной блокировки хоста на n минут, вводившего неправильный пароль m раз подряд. 8. Используйте сервисы, поддерживающие шифрование через ssl – imaps, sftp, https. Это лишь основы безопасности в Linux, но приведенными выше методами вы минимизируете возможность взлома Вашего сервера самыми распространенными способами. |