Вопросы Теги

Ограничить пользователей запуском команд «history -d [arg]» и «set + o history»

Мы находимся на ранних стадиях стандартизации нашей инфраструктуры. В качестве немедленного шага мы хотим запретить пользователям манипулировать историей. Установите некоторые ограничения на то же самое. Но недавно обнаружил, что есть пара лазейок.

  • Пользователи могут удалить запись истории, просто запустив 'history -d'
  • 'set + o history' остановит обновление файла истории.

Я ищу способы запретить пользователям запускать эту команду. Я не могу придумать для этого выхода.

Любые предложения будут полезны. Пожалуйста, дайте мне знать, если что-то непонятно. Спасибо.

Мы используем CentOS, а наша оболочка - bash

-Ram Kumar

0
задан 4 July 2018 в 11:24
1 ответ

HTTP Strict Transport Security (HSTS) может быть реализовано двумя разными способами:

1) HSTS путем установки заголовков HSTS

Пример для Nginx: add_header Strict-Transport-Security "max-age = 15768000; preload" always;

Посетители, впервые увидевшие этот заголовок, и их браузеры будут выполнять внутреннее перенаправление на HTTPS (см. 307 редирект на вкладке сети, если вы веб-сайт). Браузеры кэшируют этот HSTS для данного максимального возраста, и постоянные посетители будут использовать HTTPS, если они запросят ваш сайт.

2) HSTS от Preload

Для этого вы можете использовать сервис, предоставляемый сайтом https://hstspreload.org/

Здесь вы можете добавить домен 2-го уровня (например, my-company. com) в список основных браузеров, которые будут использовать для загрузки веб-сайта через HTTPS. Прежде чем вы сможете добавить сайт в этот список, этот сайт должен установить правильные заголовки HSTS.

Кроме того, вам следует учесть следующие детали:

  • удаление домена из списка требует некоторого времени, и вам лучше избегать этой предварительной загрузки
  • , включающей все поддомены для этого домена 2-го уровня (например, www.my-company. com, abc.my-company.com, printer.my-company.com)
  • HTTP-доступ к субдоменам (например, для локальных служб печати) может больше не работать
  • помимо перечисленных выше проблем, предварительная загрузка HSTS ускоряет доступ к

Что касается перенаправления HTTP-трафика на HTTPS и HSTS, я рекомендую следующую настройку:

Nginx Virtual Host Config 

# HTTPS server section
server {
    listen          443 ssl http2;
    listen          [::]:443 ssl http2;
    server_name     www.my-company.com;

    # include SSL configuration
    include         mycompany-ssl.conf;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }
    ...
}

# redirect HTTPS and non-www requests
server {
    listen          443 ssl http2;
    listen          [::]:443 ssl http2;
    server_name     my-company.com;

    # include SSL configuration
    include         mycompany-ssl.conf;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }

    # default redirect
    location / {
        return      301 https://www.$http_host$request_uri;
    }
}

# redirect HTTP to HTTPS
server {
    listen          80;
    listen          [::]:80;
    server_name     my-company.com www.my-company.com;

    # web root path
    root            /var/www/www.my-company.com/htdocs;

    # allow access to .well-known (PKI validation folder)
    location ~ ^/\.well-known {
        allow       all;
    }

    # default redirect
    location / {
        return      301 https://$http_host$request_uri;
    }
}

Nginx Include Config for SSL / TLS 

ssl                             on;
ssl_protocols                   TLSv1.2;
ssl_ciphers                     "EECDH+AESGCM:EDH+AESGCM:EECDH:EDH:!MD5:!RC4:!LOW:!MEDIUM:!CAMELLIA:!ECDSA:!DES:!DSS:!3DES:!NULL";
ssl_prefer_server_ciphers       on;
# Create session ticket key:    openssl rand -out /etc/nginx/ssl/session_ticket_key 48
ssl_session_ticket_key          /etc/nginx/ssl/session_ticket_key;
# Create dhparam4096.pem:       openssl dhparam -out /etc/nginx/ssl/dhparam4096.pem 4096
ssl_dhparam                     /etc/nginx/ssl/dhparam4096.pem;
ssl_ecdh_curve                  secp384r1;

# Enable SSL stapling
ssl_stapling                    on;
ssl_stapling_verify             on;
resolver                        8.8.8.8 8.8.4.4 valid=1800s;
resolver_timeout                15s;

# set security headers (see http://securityheaders.io/ for more details)
add_header                      Strict-Transport-Security "max-age=15768000; preload" always;
add_header                      X-Frame-Options "SAMEORIGIN" always;
add_header                      X-XSS-Protection "1" always;
add_header                      X-Content-Type-Options "nosniff" always;
add_header                      Referrer-Policy "strict-origin" always;

# set certificate files
ssl_certificate                 /etc/letsencrypt/www.my-company.com/fullchain.pem;
ssl_certificate_key             /etc/letsencrypt/www.my-company.com/privkey.pem;
ssl_trusted_certificate         /etc/letsencrypt/www.my-company.com/fullchain.pem;
-121------401246-

Сначала необходимо создать псевдоним для истории, а затем использовать оболочку для захвата опции. это простой пример, но его можно расширить. Создайте псевдоним для команды history (его можно поместить в bashrc)

alias history = '/ usr / local / bin / myhistory

, затем в / usr / local / bin / myhistory (вы можете при необходимости добавьте больше случаев и добавьте предложение else, чтобы перейти к функции истории по умолчанию): 

if [ $username == 'myuser' ]
then 
while getopts ":d" opt; do
  case ${opt} in
    d )
      echo "Invalid Option:"
      exit 1
      ;;
  esac
done

fi

Вы можете изучить rbash и lshell - это более элегантные способы ограничения оболочки. Надеюсь, это даст вам некоторое представление.

0
ответ дан 5 December 2019 в 05:44

Теги

Похожие вопросы