По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Все мы знаем, что время – самый ценный ресурс. Сегодня мы рассмотрим 5 способов, которые помогут сэкономить немного времени, при работе в командной строке Cisco IOS. Не будем терять время и рассмотрим их!
exec-timeout 0 0
Эта команда позволяет не терять соединение с вашим роутером или коммутатором при достижении времени таймаута, выставив его на ноль минут и ноль секунд. Если ее применить на консольных линиях и VTY, то IOS интерпретирует это, как никогда не истекающий таймаут.
Конечно, ни в коем случае нельзя использовать эту команду в продакшне из соображений безопасности, но она прекрасно подойдет, чтобы сэкономить ваше время в лаборатории, избавив от необходимости повторного входа на несколько устройств в течение дня.
logging synchronous
Наверняка вы были в ситуации, когда посреди набора вашей команды Cisco IOS чувствовала сильную необходимость отправить сообщение Syslog в консоль? :) Это может сильно отвлекать. Способ предотвращения такого вторжения заключается в применении команды logging synchronous. После ввода этой команды, если IOS понадобится отправить Syslog сообщение, то после его отправки, консоль вернет в сеанс терминала то, что вы уже набрали, чтобы продолжить там, где вы остановились.
no ip domain-lookup
Эта команда позволяет отключить интерпретацию команды как DNS имя, если в ней была сделана ошибка. Еще два менее радикальных метода как обойти это можно найти в этой статье.
alias exec
В качестве еще одного способа экономии времени можно создать несколько команд псевдонимов (alias). Это относительно короткие команды, которые транслируются в IOS в длинные команды. Например, если вам часто приходится смотреть конфигурацию протоколов маршрутизации при помощи команды show run | s router, то можно создать ее короткую версию используя команду alias exec src show run | s router. Теперь вместо всей длинной команды нам нужно будет набрать просто ее псевдоним – src.
Сохраненная начальная конфигурация
И в качестве окончательного способа по экономии времени можно рассмотреть сохранения начальной конфигурации в текстовый файл и вставить текст при запуске оборудования «из коробки» или после сброса. Например, можно завести документ со всеми командами из этой статьи и вставлять его в начале работы.
conf t
line con 0
exec-timeout 0 0
logging synchronous
exit
line vty 0 15
exec-timeout 0 0
logging synchronous
exit
no ip domain-lookup
alias exec src show run | s router
alias exec sib show ip interface brief
end
Надеемся, что это поможет сохранить вам пару драгоценных минут!
Redis – это высокопроизводительная БД, которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Она может использоваться в качестве базы данных, кэша и брокера сообщений и поддерживает различные структуры данных, такие как строки, хэши, списки, наборы и т. Д. Redis обеспечивает высокую доступность через Redis Sentinel и автоматическое разбиение между несколькими узлами Redis с помощью Redis Cluster.
Это руководство описывает установку и настройку Redis в CentOS 8. Подробно про Redis можно прочесть в этой статье.
Установка Redis в CentOS 8
Redis версии 5.0.x включен в стандартные репозитории CentOS 8. Для его установки выполните следующие команды от имени пользователя root или пользователя с привилегиями sudo (про то как получить права sudo можно прочесть тут)
sudo dnf install redis-server
После завершения установки включите и запустите службу Redis:
sudo systemctl enable --now redis
Чтобы проверить, работает ли сервер Redis, введите:
sudo systemctl status redis
Получим следующий вывод:
? redis.service - Redis persistent key-value database
Loaded: loaded (/usr/lib/systemd/system/redis.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/redis.service.d
L-limit.conf
Active: active (running) since Sat 2020-02-08 20:54:46 UTC; 7s ago
Вот и все! Redis установлен и работает на вашем сервере CentOS 8.
Настройка удаленного доступа Redis
По умолчанию Redis не разрешает удаленные подключения. Вы можете подключиться к серверу Redis только с 127.0.0.1 (localhost) - компьютера, на котором работает Redis.
Если вы используете установку с одним сервером, где клиент, подключающийся к базе данных, также работает на том же хосте, вам не нужен удаленный доступ.
Чтобы настроить Redis для приема удаленных подключений, откройте файл конфигурации Redis в текстовом редакторе:
sudo nano /etc/redis.conf
Найдите строку, начинающуюся с bind 127.0.0.1, и добавьте внутренний IP-адрес вашего сервера после 127.0.0.1.
bind 127.0.0.1 192.168.1.10
Убедитесь, что вы заменили 192.168.1.10 своим IP-адресом. Сохраните файл и закройте редактор. Если вы хотите, чтобы Redis прослушивал все интерфейсы, просто закомментируйте строку.
Перезапустите службу Redis, чтобы изменения вступили в силу:
sudo systemctl restart redis
Используйте следующую команду ss, чтобы убедиться, что сервер Redis прослушивает ваш локальный интерфейс через порт 6379:
ss -an | grep 6379
Вы должны увидеть что-то вроде этого:
tcp LISTEN 0 128 192.168.1.10:6379 0.0.0.0:*
tcp LISTEN 0 128 127.0.0.1:6379 0.0.0.0:*
Затем вам нужно настроить фаервол для доступа трафика с TCP-порта 6379.
Скорее всего вы захотите разрешить доступ к серверу Redis только с определенного IP-адреса или диапазона IP-адресов. Например, чтобы разрешить подключения только с подсети 192.168.2.0/24, выполните следующие команды:
sudo firewall-cmd --new-zone=redis –permanent
sudo firewall-cmd --zone=redis --add-port=6379/tcp –permanent
sudo firewall-cmd --zone=redis --add-source=192.168.2.0/24 –permanent
sudo firewall-cmd --reload
Приведенные выше команды создают новую зону с именем redis, открывают порт 6379 и разрешают доступ из частной сети. На этом этапе сервер Redis будет принимать удаленные подключения через порт TCP 6379.
Убедитесь, что ваш фаервол настроен на прием соединений только из доверенных диапазонов IP-адресов. Чтобы убедиться, что все настроено правильно, вы можете попробовать пропинговать сервер Redis с удаленного компьютера, используя утилиту redis-cli, которая предоставляет интерфейс командной строки для сервера Redis:
redis-cli -h ping
Команда должна вернуть ответ PONG:
PONG
Если это так, то значит, что мы все сделали правильно!
Основной причиной серьезных атак является предоставление доступа к таким активам, которые не должен быть открыты для всех.
Одной из цифровых инфраструктур, где часто встречаются проблемы с безопасностью является Kubernetes. "Облачное" программное обеспечение, развернутое на устаревших центрах обработки данных, требует от конечных пользователей и администраторов своевременного обнаружения и устранения некорректных настроек, в виде предоставление привилегий высокого уровня программам и людям, которым они вовсе не нужны.
IBM Study пришла к выводу, что в 95% случаям нарушения безопасности, которые они исследовали, содействовали или были вызваны человеческими ошибками, в том числе и разработчиками программного обеспечения. Остальные же были, главным образом, из-за технической оплошности.
В последующих исследованиях, касающихся нарушений безопасности, также приводились аналогичные выводы с цифровыми инструментами всех видов.
В Kubernetes привилегии часто предоставляются с помощью ролевых средств управления доступом. Он может ошибочно разрешить административные разрешения для всего кластера, даже если это не требуется. Тот факт, что Kubernetes может включать крупномасштабные и автоматизированные разрешения на инфраструктуру, также создает почву для атаки на контейнеры, приложения и злоупотребления разрешениями.
Проблемы также включают множество встроенных функций безопасности, но не все они включены в инструменте по умолчанию. Поскольку Kubernetes способствует быстрому развертыванию и разработке приложений, управление может помешать быстрому развертыванию инфраструктуры.
После окончательного развертывания приложений, делая их доступными для пользователей, неверно сделанные конфигурации безопасности увеличивают возможные риски.
Стратегии безопасности для облачных инструментов
Для защиты облачных средств с помощью контейнеров необходима другая стратегия, отличная от стратегии, используемой для устаревших инфраструктурных систем. С ростом внедрения облачных инструментов существуют два подхода к обеспечению безопасности, главным образом, Kubernetes-ориентированный и контейнерный.
В ориентированном на контейнеры подходе к обеспечению безопасности основное внимание уделяется обеспечению безопасности среды выполнения контейнеров и образов. Для управления связью между контейнерами используются такие методы управления, как shim специально написанный интерфейс и встроенные прокси-серверы.
С другой стороны, подход, ориентированный на Kubernetes, использует встроенную масштабируемость и гибкость Kubernetes. Она работает на уровнях Kubernetes и продвигает свои принудительные политики. Следовательно, вы должны позволить ему контролировать как вашу инфраструктуру, так и безопасность.
Что делает встроенное средство безопасности Kubernetes?
Характеристики, которые делают средство безопасности Kubernetes-ориентированным или Kubernetes-native, представляют собой сочетание того, что они выполняют и как. Во-первых, необходимо интегрировать инфраструктуру и рабочие нагрузки с API Kubernetes и оценить уязвимости.
Убедитесь, что функции безопасности основаны на ресурсах Kubernetes, включая службы, развертывания, модули и пространства имен. Также необходимо использовать встроенные функции безопасности Kubernetes. Такая глубокая интеграция охватывает все аспекты среды Kubernetes, включая управление уязвимостями, управление конфигурацией, сегментацию сети, реагирование на инциденты, соответствие нормативным требованиям и обнаружение угроз.
Почему инструменты, ориентированные на Kubernetes, превосходят контейнеры?
Платформы безопасности, ориентированные на Kubernetes, считаются превосходными, если вы работаете с контейнерами. Причину можно сформулировать тремя способами.
Во-первых, они обеспечивают лучшую защиту с помощью богатого понимания принципов работы контейнеров и самого Kubernetes. Они также используют декларативные данные для контекстуализации рисков и информирования о них.
Во-вторых, платформы безопасности Kubernetes обеспечивают повышенную операционную эффективность, что позволяет быстро обнаруживать угрозы, а также оценивать риски на приоритетном уровне. Он позволяет всем членам вашей команды находиться на одной странице для устранения неполадок и более быстрой работы.
В-третьих, ваш операционный риск может быть снижен с помощью встроенных средств управления Kubernetes, облегчающих масштабируемость и адаптируемость. Кроме того, между оркестратором и внешними элементами управления не может возникнуть никакого конфликта.
Таким образом, собственные возможности Kubernetes в области безопасности могут лучше защитить контейнерные экосистемы. Если вашим специалистам по безопасности инфраструктуры и DevOps удается использовать весь потенциал этих инструментов, вы можете продолжать обнаруживать угрозы и останавливать их, когда у вас есть время.