Поиск

Когда то я использовал KALI linux и главное что мне там запомнилось - удобный терминал. (Kali terminal to MacOS?) Искал много в сети и почти ничего не нашел. Поэтому собрал инструкцию как превратить оформление классического терминала MacOS в удобную вариацию похожую на Kali Linux. В целом. этими же шагами можно пройтись и на linux в т.ч. Ubuntu Подготовка Установите Homebrew /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" Ставим iTerm 2 и Git brew install --cask iterm2 brew install git Также ставим Oh My Zsh sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)" Установка темы Чтобы символы были доступны все, а шрифт соответствовал ожиданиям нам необходимы шрифты Meslo: https://github.com/romkatv/powerlevel10k#fonts После чего ставим выбранную тему. Я выбрал тему powerlevel10k/powerlevel10k git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k Далее, В ~/.zshrc пропишите, какую ZSH- тему использовать: ZSH_THEME="powerlevel10k/powerlevel10k" Я рекомендую два основных модуля: zsh-syntax-highlighting — Подсветка синтаксиса для Zsh. Благодаря ей мои алиасы и команды стали зелеными. Ошибки красным, правильные команды зелёным. zsh-autosuggestions — Автодополнение для Zsh. Показывает превью последней подходящей команды при вводе. Удобно, если не помнишь основные. Принимаются предложения стрелкой в правой или Табом. Устанавливаем: git clone https://github.com/zsh-users/zsh-autosuggestions ~/.oh-my-zsh/custom/plugins/zsh-autosuggestions git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ~/.oh-my-zsh/custom/plugins/zsh-syntax-highlighting В ~/.zshrc пропишите, какие ZSH-плагины нужно использовать: plugins=( git zsh-syntax-highlighting zsh-autosuggestions ) Перезапустите свой терминал с Zsh. Теперь запускаем настройку темы: p10k configure Данная команда запустит настройки темы. Наконец, если хотите включить имеющиеся у вас bash-алиасы и функции, пропишите в ~/.zshrc для source путь к вашему bash_profile перед export ZSH. source ~/.bash_profile Стоит отметить, если вы продолжите использовать стандартный терминал - то на этом в принципе всё. Мой терминал выглядит так: Как видите, изменился дизайн, появился синтаксис и стали предлагаться варианты команды. Если вы хотите использовать iTerm, то можно ещё включить в верхней части терминала дополнительные настройки: Откройте iterm2 > Profile > Session и отметьте Status bar enabled. Выберите нужные вам виджеты Всё сделано! Приятного использования!

Общие правила безопасности для VPS и VDS серверов помогут защитить ваш сервер от потенциальных угроз и повысить уровень безопасности. Статья написана из общих рекомендаций и переведена на русский Вот несколько общих правил безопасности, которые рекомендуется следовать: 1. Обновляйте операционную систему: Регулярно обновляйте операционную систему, чтобы устранить уязвимости и получить последние исправления безопасности. Используйте команды apt-get update и apt-get upgrade для Debian и Ubuntu, или соответствующие команды для других дистрибутивов. 2. Используйте сильные пароли: Установите сложные пароли для всех пользователей и сервисов на сервере. Пароли должны содержать комбинацию букв, цифр и специальных символов, а также быть достаточной длины. Рекомендуется использовать инструменты для генерации и управления паролями, такие как pwgen или pass. 3. Настройте брандмауэр: Включите брандмауэр на сервере и настройте правила, чтобы разрешить только необходимые сетевые соединения. Для Linux можно использовать iptables или более простой в использовании ufw. Закройте все неиспользуемые порты. 4. Отключите ненужные службы: Отключите все ненужные службы и демоны, которые не используются на сервере. Это уменьшит поверхность атаки и улучшит безопасность. Проверьте список активных служб с помощью команды systemctl list-units --type=service. 5. Используйте SSH-ключи для аутентификации: Вместо паролей рекомендуется использовать SSH-ключи для аутентификации. Сгенерируйте ключевую пару на клиентской машине, а затем установите открытый ключ на сервере в файле ~/.ssh/authorized_keys для каждого пользователя. 6. Используйте VPN или SSH туннели: Если вы работаете с удаленным доступом к серверу, рекомендуется использовать VPN или SSH туннели для шифрования сетевого трафика и защиты от прослушивания. 7. Резервное копирование: Регулярно создавайте резервные копии данных на сервере. Это поможет восстановить данные в случае атаки или сбоя сервера. Рассмотрите использование автоматического резервного копирования на удаленное хранилище. 8. Мониторинг и журналирование: Настройте систему мониторинга и журналирования, чтобы отслеживать активность на сервере и быстро реагировать на подозрительные события. Используйте инструменты, такие как fail2ban, для автоматической блокировки IP-адресов с повторными неудачными попытками входа. 9. Физическая безопасность: Обеспечьте физическую безопасность сервера. Разместите сервер в надежном помещении, ограничьте доступ к серверу только необходимым лицам и защитите его от физического вмешательства. 10. Регулярные аудиты и проверки: Регулярно проводите аудит безопасности сервера. Изучайте все возможные совершенствования систем безопасности. 11. Установите SSL-сертификат: Если на вашем сервере работает веб-сервер, рекомендуется установить SSL-сертификат для шифрования передаваемых данных. Это обеспечит безопасное соединение между сервером и клиентами. 11.1. Не забывайте про использование проксирования, чтобы скрыть реальный адрес вашего сервера. 12. Ограничьте доступ к файлам и каталогам: Убедитесь, что разрешения на файлы и каталоги на сервере установлены правильно. Ограничьте доступ к конфиденциальным файлам и каталогам только для необходимых пользователей или групп. 13. Используйте обновленные и безопасные программные решения: Установите только необходимое программное обеспечение на сервере и убедитесь, что все установленные программы и пакеты обновлены до последних версий. Используйте только официальные и проверенные источники для загрузки программного обеспечения. 13.1. Для обновления контейнеров Docker до последних версий в автоматическом режиме, также существуют специальные сервисы, которые вы можете установить на ваш сервер. 14. Минимизируйте атаку посредством отказа в обслуживании (DDoS): Используйте службы защиты от DDoS для снижения риска атаки. Рассмотрите возможность использования услуги CDN (Content Delivery Network), которая распределяет нагрузку и защищает от DDoS-атак. Это конечно касается особо крупных и доходных проектов. Не пренебрегайте этой защитой, если ваш сайт/сервер приносит вам значительный доход. Помимо этого, важно выбирать надежного провайдера. 15. Используйте двухфакторную аутентификацию: Включите двухфакторную аутентификацию (2FA) для доступа к важным аккаунтам и сервисам на сервере. Это добавит дополнительный уровень защиты, требуя не только пароль, но и второй фактор (например, одноразовый код или биометрические данные). 16. Защитите базы данных: Если на сервере установлена база данных, обеспечьте ее безопасность. Используйте сильные пароли для доступа к базе данных и установите ограничения на доступ к базам данных с удаленных адресов. Вы также можете обеспечить децентрализацию хранения, разместив базу в максимально надежном сервисе. Но не забывайте ограничить возможность доступа через фильтрацию IP адресов с вашего основного, а всем остальным запретить. 17. Обеспечьте аудит безопасности: Регулярно выполняйте аудит безопасности сервера с помощью инструментов, таких как OpenVAS или Nessus. Это поможет обнаружить потенциальные уязвимости и проблемы безопасности. 18. Будьте внимательны к фишинговым атакам: Будьте осторожны при получении электронных писем, содержащих подозрительные ссылки или приложения. Не предоставляйте конфиденциальную информацию или доступы к серверу в ответ на подозрительные запросы. 19. Создайте политику безопасности: Разработайте и документируйте политику безопасности для вашего сервера. В политике должны быть указаны правила и процедуры в отношении доступа, паролей, обновлений и других аспектов безопасности. 20. Будьте готовы к восстановлению: Создайте план восстановления после сбоя или атаки, чтобы быстро восстановить работоспособность сервера. Регулярно создавайте резервные копии данных и проверяйте их целостность.

ShadowSocks решения: Marzban | Marzban Node | x-ui | 3x-ui Мануал получился достаточно случайно. Было обсуждение в чате по SS.. И вот на одном из сайтов нашел подсказку, про использование Warp в качестве локального прокси сервера. Давайте для начала разберемся для чего это может быть полезно: Можно пустить весь трафик сервера через warp для доступа к OpenAI с тех серверов, на которых его нет. Можно дополнительно зашифровать весь трафик отправив его через warp Потенциальные минусы: Снижение скорости работы и увеличенный ping. Пора к делу! На самом деле всё довольно просто, но в конфигурации с DWG сборками еще работа не проверялась. Вся информация есть на оф сайте: Announcing WARP for Linux and Proxy Mode (cloudflare.com) Дополнительно читаем про добавление ключей: Cloudflare Package Repository (cloudflareclient.com) А теперь пример реальный, на Ubuntu: Добавляем GPG key: curl https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg Добавляем репозиторий: echo "deb [arch=amd64 signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list Обноляемся: sudo apt update Ставим sudo apt install cloudflare-warp Теперь настраиваем. 1. Всю помощь получаем тут: warp-cli --help 2. Нужно зарегистрироваться: warp-cli register 3. Теперь выставить режим работы (possible values: warp, doh, warp+doh, dot, warp+dot, proxy), я выбираю proxy: warp-cli set-mode proxy Вы можете попробовать и другие варианты.. для эксперимента.. 4. Используем. В моем случае я использовал с панелькой 3х-ui: MHSanaei/3x-ui: Xray panel supporting multi-protocol multi-user expire day & traffic & ip limit (Vmess & Vless & Trojan & ShadowSocks) (github.com) 5. ГОТОВО. Теперь доступ к ресурсам отмеченных галочкой - у нас есть. О том как поставить x-ui, что это, как использовать и как настроить - будет отдельная статья..

Хотите узнать, где находятся образы, контейнеры и тома Docker? В типичной среде Linux образы Docker и данные контейнеров можно найти в: /var/lib/docker/ Если на вашем сервере не хватает места, вам обязательно следует заглянуть в этот каталог. В основном, все связанные с Docker сущности находятся в /var/lib/docker. Но давайте рассмотрим его более конкретно, на примере образа и контейнера Alpine. Расположение образов Docker Всякий раз, когда вы используете команду docker pull или запускаете docker-compose up -d для подготовки запуска приложений, именно здесь хранятся образы на сервере Ubuntu: /var/lib/docker/overlay2 Здесь Overlay2 является драйвером хранилища Docker по умолчанию в Ubuntu. Вы можете подтвердить это, выполнив команду docker info и поискав Storage Driver: ... Storage Driver: overlay2 ... Если оно отличается от вашего, значит, вы используете другой драйвер хранения для Docker. Аналогично, расположение каталога будет названо в соответствии с тем же драйвером хранения. Доступность драйвера хранилища зависит от поддержки ядра. Определенные местоположения образов Если вы ищете местоположение конкретных образов, вы можете использовать команду inspect в Docker для извлеченного образа. Скажем, например, я извлек образ alpine с помощью команды docker pull alpine. Выполните следующую команду для его проверки: $ docker inspect alpine После выполнения команды вы заметите три поля в подразделе Data в разделе GraphDriver: ... "GraphDriver": { "Data": { "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged", "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff", "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work" }, ... Вышеуказанные каталоги – это физическое расположение данных вашего контейнера внутри хост-системы. Помните большую директорию с хэш-именем: 64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a525ab9e365e из раздела Docker Images? Каталог под ним называется diff, как вы можете видеть в разделе LowerDir после :, который теперь является точкой монтирования контейнера – полученной из базового образа UpperDir! Эти каталоги будут оставаться доступными даже после остановки контейнера. Итак, полный путь, который является общим между образом (MergedDir, UpperDir и WorkDir) и контейнером (точка монтирования LowerDir), следующий: /var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/ После присвоения контейнеру до уровня LowerDir цель образа является смежной, поэтому четыре поля выделяются и основываются на другом каталоге (с новым хэшем) из-за динамической природы последнего, который становится: /var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/ Расположение томов Docker В отличие от образов и контейнеров Docker, физическое расположение томов довольно простое. Тома располагаются по адресу: /var/lib/docker/volumes/ Конкретные места расположения томов В этом случае существует два типа томов. Первый – обычные тома Docker, а второй – bind mounts. Тома Docker Если вы ищете местоположение определенных томов, вы можете сначала использовать команду docker volume ls и проверить имя или ID тома. Например, я запустил контейнер alpine с помощью следующей команды с томом: $ docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine Теперь автоматически будет создан том с именем test-data. Теперь давайте создадим файл test.md в этом месте: ~$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md" Убедитесь, что файл действительно был создан: $ docker exec -ti alpine-container sh / # ls /var/lib/app/content/ test.md / # exit Когда вы запустите docker volume ls, в списке появится том с именем test-data: $ docker volume ls DRIVER VOLUME NAME local d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1 local e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b local test-data Наконец, вы можете подтвердить фактическое расположение файла на вашей хост-системе: $ sudo ls -l /var/lib/docker/volumes/test-data/_data total 0 -rw-r--r-- 1 root root 0 Oct 6 23:20 test.md Поэтому путь для смонтированного тома всегда находится в каталоге с именем _data внутри соответствующего каталога тома. Вы также можете проверить такие пути используя команду docker volume inspect с последующим указанием имени или ID тома и просмотрев параметр Mountpoint в выводе: $ docker volume inspect test-data [ { "CreatedAt": "2021-10-06T23:20:20+05:30", "Driver": "local", "Labels": null, "Mountpoint": "/var/lib/docker/volumes/test-data/_data", "Name": "test-data", "Options": null, "Scope": "local" } ] Монтирование на хосте Расположение привязанных монтирований довольно очевидно и даже более просто, поскольку вы монтируете том непосредственно из расположения на стороне хоста: $ mkdir /home/avimanyu/test-data $ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine В этом случае смонтированный том с именем test-data станет доступен на стороне контейнера как /var/lib/app/content. Заключение В этом кратком руководстве я использовал общий подход на базе Linux, чтобы показать физическое расположение образов Docker, контейнеров и томов, расположенных на вашем Linux-сервере (в данном случае Ubuntu 20.04) на уровне хоста.

Всем привет. Оформлю тему для частых ошибок и их решение.