Имена пользователей и хостов в открытом ключе на ssh-copy-id

Я бы немного изменил ваш список критериев защиты сценария.Учитывая эту или аналогичную запись в / etc / sudoers :

 www-data ALL = (ALL) NOPASSWD: / usr / local / sbin / mycommand 
 

мы может указывать, что сценарий:

• должен быть доступен для записи только пользователю root
• должен быть доступен для чтения и исполняться пользователем root
• должен находиться в иерархии каталогов, которые могут быть записаны только пользователем root
• должны проверить свой ввод «в достаточной степени» для использования и отклонить что-либо еще
• должен иметь наименьший набор привилегий, необходимых для выполнения своей задачи (не обязательно setuid root)
• должен определить свой ПУТЬ перед использование любых внешних команд
• должно установить все переменные в известное значение перед их использованием
• должен генерировать контрольный журнал, чтобы показать не только, когда и как он был вызван, но также и результирующее действие (подумайте logger ])

Кроме того, во многих случаях нет реальной необходимости запускать сценарий от имени пользователя root - он может запускать setgid или даже setuid для какой-либо другой учетной записи. В общем случае рассмотрите эти варианты, чтобы избежать предоставления скрипту полного корневого доступа.

Для сред SELinux можно создать политику, которая предотвращает выполнение сценарием каких-либо неожиданных действий. Такие возможности, как CAP_NET_ADMIN, более детализированы, чем общие привилегии root, и их также стоит рассмотреть.

В указанном вами конкретном случае, когда вы хотите проверить один IPv4-адрес и передать его iptables , вы можете обойтись без проверки IP-адреса. адрес как последовательность неспецифических октетов. В данном случае 444.555.666.999 можно считать правдоподобным, зная, что сам iptables отклонит все, что не является настоящим IP-адресом. В одном крайнем случае вы можете решить, что сопоставление RE / ^ [0-9.] + $ / достаточно, чтобы передать значение в iptables . С другой стороны, есть много ответов на StackExchange и в других местах , которые касаются проблемы проверки IP-адреса. Некоторые лучше, чем другие.

Особые случаи, которые следует учитывать, - это адреса RFC1918, адреса многоадресной рассылки и ваш собственный диапазон внешних IP-адресов. Да, и зарезервированный блок, ранее известный как Class E. Нужна ли вам поддержка IPv6?

Что произойдет, если ваш скрипт будет вызывать сотни раз в минуту? Вам нужно подготовиться к такому повороту событий? Будет ли ваша цепочка iptables переполнена? Если вы думаете, что вам понадобятся сотни правил в вашей цепочке, [более эффективно будет использовать расширение ipset до iptables , а не линейный список. Вот хороший учебник . Что касается защиты, он позволяет создавать наборы из тысяч (если не десятков тысяч ) похожих правил, которые могут выполняться без значительного замедления трафика, проходящего через ваши наборы правил.

Внезапно ваше очевидно прямое требование становится довольно сложным.