tFF.msk.ru :: Sharing tFFed mind
Май 28, 2024, 14:41:50 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.

Войти
Новости: Пропал ребенок. Вся информация и фотографии здесь.
 
   Начало   Помощь Поиск Войти Регистрация  
Страниц: [1]   Вниз
  Печать  
Автор Тема: Linux  (Прочитано 7463 раз)
0 Пользователей и 1 Гость смотрят эту тему.
tFF
Administrator
Sr. Member
*****
Offline Offline

Сообщений: 422



WWW
« : Апрель 20, 2006, 18:32:47 »

Код:
netstat -l -p
lsof -i :80 (to see exactly what is listening on port 80)

Linux System Files
System run levels and init.d scripts (from: Debian Policy Manual)
Unix runlevels
APT HOWTO (Управление пакетами Debian)
25+ Useful Linux and Unix Cheat Sheets
« Последнее редактирование: Ноябрь 21, 2009, 14:05:01 от tFF » Записан

So it goes...
tFF
Administrator
Sr. Member
*****
Offline Offline

Сообщений: 422



WWW
SSH
« Ответ #1 : Сентябрь 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
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa): /home/user/.ssh/id_rsa_myserver
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa_myserver.
Your public key has been saved in /home/user/.ssh/id_rsa_myserver.pub.
The key fingerprint is:
6f:d2:ab:cc:f4:a8:e4:d9:63:ff:de:35:ad:05:6e:75 user@comp
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|                 |
|        S     . E|
|         o   . oo|
|      . o +   o.+|
|     o *o= . o +.|
|      +o*++oo o  |
+-----------------+
:~$ ssh-copy-id -i /home/user/.ssh/id_rsa_myserver user@server.ru
user@server.ru's password:
Now try logging into the machine, with "ssh 'user@server.ru'", and check in:
 
  .ssh/authorized_keys
 
to make sure we haven't added extra keys that you weren't expecting.
 
:~$ ssh -i /home/user/.ssh/id_rsa_myserver user@server.ru
Last login: Fri May 24 13:05:30 2009 from 192.168.0.1
-bash-3.2$
Записан

So it goes...
tFF
Administrator
Sr. Member
*****
Offline Offline

Сообщений: 422



WWW
« Ответ #2 : Сентябрь 26, 2009, 00:56:53 »

Backup TOC
Backup using dd
Backup using tar

Код:
#!/bin/sh -e
echo Tarring...
tar --create --file /bak.tar /etc /home /root /var
echo Tarred! Wait to compare...
sleep 5;
echo Comparing... Wait.
tar --compare --verbose -f /bak.tar

Better:
Код:
#!/bin/sh -e
echo Tarring...
tar --create --file /etc.tar /etc
tar --create --file /home.tar /home
tar --create --file /root.tar /root
tar --create --file /var.tar /var
echo Tarred! Wait to compare...
sleep 5;
echo Comparing... Wait.
tar --compare --verbose -f /etc.tar
tar --compare --verbose -f /home.tar
tar --compare --verbose -f /root.tar
tar --compare --verbose -f /var.tar
« Последнее редактирование: Сентябрь 27, 2009, 03:03:25 от tFF » Записан

So it goes...
tFF
Administrator
Sr. Member
*****
Offline Offline

Сообщений: 422



WWW
« Ответ #3 : Декабрь 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/
Записан

So it goes...
tFF
Administrator
Sr. Member
*****
Offline Offline

Сообщений: 422



WWW
« Ответ #4 : Январь 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, но приведенными выше методами вы минимизируете возможность взлома Вашего сервера самыми распространенными способами.
Записан

So it goes...
Страниц: [1]   Вверх
  Печать  
 
Перейти в:  

 ONLINECHANGE
Powered by MySQL Powered by PHP Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC Valid XHTML 1.0! Valid CSS!


Google visited last this page Март 05, 2020, 14:16:23