http://www.opennet.ru/openforum/vsluhfo ... 64776.html
И вот http://habrahabr.ru/post/44783/В варианте с su - пароль рута знаю все члены группы wheel.
В варианте с sudo пароль рута не знает никто, кроме одного. Далее, если увольняется сотрудник из группы wheel, нет необходимости менять рутовый пароль, просто удаляется запись из sudoers. Кроме того, при помощи sudo можно ограничивать права на выполнение от имени рута.
А именно
Ну и вдогонку....При этом доверенным пользователям приходилось помнить пароль root'а и у всех пользователей, перечисленных в группе «wheel» (т.е. в группе, члены которой могли выполнить команду su и стать суперпользователем), был одинаковый неограниченный доступ ко всей системе, что являлось серьёзной проблемой безопасности...
Я полностью согласен с хабром и опеннетом(ни разу ещё не подводили). В своей деятельности весьма внимательно рассматриваю вопросы безопасности и уж точно использование su естьQ: sudo -i длиннее, чем su -, а разницы между ними вроде как и никакой, зачем печатать больше?
A: У sudo есть несколько преимуществ, ради которых стоит потрудиться набрать несколько лишних символов:
по умолчанию sudo записывает всю пользовательскую активность в syslog-канал authpriv (как правило, результат кладется в файл /var/log/auth.log), а в su подобную фичу надо включать с помошью задания специального параметра в файле настроек, различающемся от дистрибутива к дистрибутиву (SULOG_FILE в /etc/login.defs в Ubuntu Linux, /etc/login.conf и /etc/pam.d/su в FreeBSD и т.д.)
в случае с su администратор системы не может ограничить команды, выполняемые пользователями, а в sudo — может
если пользователь должен быть лишен права администрирования, в случае с su после удаления его из группы wheel он должен забыть пароль root'а; если используется sudo, достаточно вынести его из соответствующей группы (например, wheel или admin) и/или файла sudoers, если он был дополнительно настроен.
Q: я единственный пользователь своей системы и привык к su, зачем мне sudo?
A: отвечу вопросом на вопрос: если есть правильный sudo, зачем использовать устаревший su?
Предпочитаю курить маны по sudousers. ИМХО.Как и обещал...это у меня на десктопе. Секретов особо нет. Тут основа, которую в принципе можно забивать по дефолту. Только интерфейс указать иной
Да такой вот у мну легкопредсказуемый интерфейс.
# Generated by iptables-save v1.4.19.1 on Wed Jul 10 19:43:58 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -i enp2s0 -m state --state INVALID -j DROP
-A INPUT -i enp2s0 -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP # А это вот то самое правило ниже копипаст. http://www.opennet.ru/docs/RUS/iptables/
-A INPUT -i enp2s0 -p icmp -m state --state ESTABLISHED -j ACCEPT
-A INPUT -i enp2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i enp2s0 -p tcp -m tcp --tcp-flags SYN,ACK FIN,SYN -j REJECT --reject-with icmp-port-unreachable
-A INPUT -i enp2s0 -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j DROP
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o enp2s0 -p icmp -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --sport 123 --dport 123 -j ACCEPT
-A OUTPUT -o enp2s0 -p tcp -m tcp --sport 1024:65535 -j ACCEPT
-A OUTPUT -o enp2s0 -p udp -m udp --sport 1024:65535 -j ACCEPT
-A OUTPUT -j DROP
COMMIT
# Completed on Wed Jul 10 19:43:58 2013
Это свойство iptables недостаточно хорошо задокументировано, а поэтому многие могут уделить ему недостаточное внимание (включая и меня). Если вы используете правила, определяющие статус пакета NEW, но не проверяете состояние бита SYN, то пакеты со сброшенным битом SYN смогут "просочиться" через вашу защиту. Хотя, в случае, когда мы используем несколько брандмауэров, такой пакет может оказаться частью ESTABLISHED соединения, установленного через другой брандмауэр. Пропуская подобные пакеты, мы делаем возможным совместную работу двух или более брандмауэров, при этом мы можем любой из них остановить не боясь разорвать установленные соединения, Поскольку функции по передаче данных тут же возьмет на себя другой брандмауэр. Однако это позволит устанавливать практически любое TCP соединение. Во избежание этого следует добавить следующие правила в цепочки INPUT, OUTPUT и FORWARD:
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \
--log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
Вышеприведенные правила позаботятся об этой проблеме. Будьте чрезвычайно внимательны при построении правил принимающих решение на основе статуса пакета.
Обратите внимание, что имеются некоторые неприятности с вышеприведенными правилами и плохой реализацией TCP/IP от Microsoft. Дело в том, что при некоторых условиях, пакеты, сгенерированные программами от Microsoft маркируются как NEW и согласно этим правилам будут сброшены. Это, однако, не приводит к разрушению соединений, насколько я знаю. Происходит это потому, что, когда соединение закрывается, и посылается завершающий пакет FIN/ACK, то netfilter закрывает это соединение и удаляет его из таблицы conntrack. В этот момент, дефектный код Microsoft посылает другой пакет, которому присваивается статус NEW, но в этом пакете не установлен бит SYN и, следовательно соответствует вышеупомянутым правилам. Короче говоря - особо не переживайте по поводу этих правил. В случае чего - вы сможете просмотреть системный журнал, куда логируются отбрасываемые пакеты (см. правила выше) и разобраться с ними.
Имеется еще одна известная проблема с этими правилами. Если кто-то в настоящее время связан с брандмауэром, например из LAN, и активирует PPP, то в этом случае соединение будет уничтожено. Это происходит в момент, когда загружаются или выгружаются conntrack и nat модули. Другой способ получить эту проблему состоит в том, чтобы выполнить сценарий rc.firewall.txt из сеанса telnet с другого компьютера. Для этого вы соединяетесь по telnet с брандмауэром. Запускаете rc.firewall.txt, в процессе исполнения которого, запускаются модули трассировки подключений, грузятся правила "NEW not SYN". Когда клиент telnet или daemon пробуют послать что нибудь, то это подключение будет распознано трассировочным кодом как NEW, но пакеты не имеют установленного бита SYN, так как они, фактически, являются частью уже установленного соединения. Следовательно, пакет будет соответствовать правилам в результате чего будет зажурналирован и сброшен.
