upd lab4
This commit is contained in:
Binary file not shown.
@@ -301,61 +301,43 @@ done
|
||||
|
||||
*В части 4 вы использовали готовые команды для настройки NAT. Поясните какие параметры передаются в ключах команды iptables.*
|
||||
|
||||
Пример команды:
|
||||
|
||||
```bash
|
||||
iptables -t nat -A POSTROUTING -o enp1s0 -s 10.0.0.0/24 -j MASQUERADE
|
||||
```
|
||||
|
||||
- `-t nat` — выбрать таблицу NAT;
|
||||
- `-A POSTROUTING` — добавить правило в цепочку POSTROUTING;
|
||||
- `-o enp1s0` — указывает выходной интерфейс;
|
||||
- `-s 10.0.0.0/24` — диапазон внутренних адресов, для которых применяется правило;
|
||||
- `-j MASQUERADE` — действие: подменить IP-адрес источника на внешний адрес интерфейса.
|
||||
|
||||
Аналогично, при `-j SNAT --to-source <IP>` адрес подменяется на указанный вручную.
|
||||
`-t nat` — выбрать таблицу NAT, `-A POSTROUTING` — добавить правило в цепочку POSTROUTING, `-o enp1s0` — указывает выходной интерфейс, `-s 10.0.0.0/24` — диапазон внутренних адресов, для которых применяется правило, `-j MASQUERADE` — действие: подменить IP-адрес источника на внешний адрес интерфейса. Аналогично, при `-j SNAT --to-source <ip>` адрес подменяется на указанный вручную.
|
||||
|
||||
*При создании ключей ssh программа-генератор предлагает ввести пароль. Зачем он нужен и для чего используется?*
|
||||
|
||||
Пароль защищает приватный ключ.
|
||||
Даже если файл ключа попадёт в чужие руки, без пароля им нельзя воспользоваться.
|
||||
Это как двойная защита: пароль → разблокирует закрытый ключ, ключ → разблокирует доступ по SSH.
|
||||
Пароль защищает приватный ключ. Даже если файл ключа попадёт в чужие руки, без пароля им нельзя воспользоваться.
|
||||
|
||||
*При первом подключении по ssh к новому серверу вам выводится хэш и программа предлагает принять его или отклонить. Зачем это нужно?*
|
||||
|
||||
Это fingerprint публичного ключа сервера.
|
||||
Он нужен, чтобы убедиться, что ты подключаешься к правильному серверу, а не к подменённому.
|
||||
После подтверждения отпечаток сохраняется в `~/.ssh/known_hosts`.
|
||||
Если при следующем подключении хэш изменился — SSH предупредит о возможной подмене.
|
||||
Это fingerprint публичного ключа сервера. Он нужен, чтобы убедиться, что мы подключаемся к правильному серверу, а не к подменённому. После подтверждения отпечаток сохраняется в `~/.ssh/known_hosts`. Если при следующем подключении хэш изменился — SSH предупредит о возможной подмене.
|
||||
|
||||
*Как на сервере ssh определить сколько подключений по ssh есть и от каких пользователей?*
|
||||
|
||||
Можно посмотреть процессы:
|
||||
|
||||
```bash
|
||||
ss -tuna | grep ':22'
|
||||
```
|
||||
|
||||
или более конкретно:
|
||||
или
|
||||
|
||||
```bash
|
||||
who
|
||||
```
|
||||
|
||||
или:
|
||||
или
|
||||
|
||||
```bash
|
||||
ps aux | grep sshd
|
||||
```
|
||||
|
||||
`sshd` показывает каждое активное соединение, `who` — кто вошёл в систему, с каких IP-адресов, и сколько пользователей сейчас в системе.
|
||||
`sshd` показывает каждое активное соединение, `who` — кто вошёл в систему, с каких ip, и сколько пользователей сейчас в системе.
|
||||
|
||||
*Если у двух пользователей в Linux будут одинаковые пароли, то сможем ли мы понять это по данным в файле `/etc/shadow`? Почему?*
|
||||
|
||||
Нет.
|
||||
Файл `/etc/shadow` хранит хэши паролей с солью, то есть у каждого пароля добавляется случайное значение перед хэшированием.
|
||||
Даже если два пользователя используют одинаковый пароль, их хэши будут разными.
|
||||
Это сделано специально, чтобы невозможно было определить совпадение паролей.
|
||||
Нет. Файл `/etc/shadow` хранит хэши паролей с солью, то есть у каждого пароля добавляется случайное значение перед хэшированием. Даже если два пользователя используют одинаковый пароль, их хэши будут разными.
|
||||
|
||||
*Заполните таблицу, описывающую действие различных атрибутов прав (r, w, x) и атрибутов безопасности (suid, sgid, stiky bit) при назначении их файлу или каталогу. В таблице должны быть следующие столбцы:*
|
||||
|
||||
@@ -363,13 +345,13 @@ ps aux | grep sshd
|
||||
|
||||
*В Linux существует расширенные права на файлы или каталоги. Работать с ними можно с помощью утилит satfacl и getfacl. Приведите пример команды, с помощью которой мы можем дать конкретному пользователю все права на файл, не делая его владельцем и не добавляя его в группы.*
|
||||
|
||||
Чтобы дать пользователю `alex` все права на файл `/DATA/info.txt`, не меняя владельца и групп:
|
||||
Чтобы дать пользователю `vlad` все права на файл `/DATA/info.txt`, не меняя владельца и групп:
|
||||
|
||||
```bash
|
||||
sudo setfacl -m u:alex:rwx /DATA/info.txt
|
||||
sudo setfacl -m u:vlad:rwx /DATA/info.txt
|
||||
```
|
||||
|
||||
Проверить можно:
|
||||
Проверить можно при помощи:
|
||||
|
||||
```bash
|
||||
getfacl /DATA/info.txt
|
||||
@@ -377,5 +359,4 @@ getfacl /DATA/info.txt
|
||||
|
||||
=== Вывод.
|
||||
|
||||
В ходе лабораторной работы были изучены основы администрирования Linux-систем: настройка NAT с помощью iptables, управление пользователями и правами доступа, работа с ACL и специальными битами, организация аутентификации по SSH-ключам и настройка sudo. На практике реализовано взаимодействие двух виртуальных машин, проброс портов и защита доступа. Получены навыки безопасной настройки сетевых и пользовательских прав в многопользовательской системе.
|
||||
|
||||
В ходе лабораторной работы я изучил основы администрирования linux-систем: настройка nat, управление пользователями и правами доступа, работа с acl, организация аутентификации по ssh-ключам и настройка sudo. На практике реализовано взаимодействие двух виртуальных машин, проброс портов и защита доступа.
|
||||
|
||||
Reference in New Issue
Block a user