По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Rocket.Chat — это бесплатный масштабируемый open source корпоративный чат, разработанный с помощью Meteor. Rocket.Chat можно считать аналогом Slack, который можно развернуть на своем сервере, и подключаться к нему с клиентов на Linux, Windows, macOS, Android и iOS. Функции Rocket.Chat Чат в реальном времени Аудиоконференции Видеоконференции Каналы Гостевой вход Трансляция экрана Передача файлов Полнофункциональный API Для обеспечения безопасности используется: Групповая синхронизация LDAP Двухфакторная аутентификация 2FA Сквозное шифрование Единый вход SSO Несколько поставщиков Oauth аутентификации Рассказываем как установить и настроить сервер и клиент Rocket.Chat в Linux. Шаг 1. Установка Snap в Linux Для простоты мы будем использовать систему управления пакетами Snaps. Первым делом надо установить пакет snapd c помощью диспетчера пакетов. $ sudo apt install snapd #Ubuntu и Debian $ sudo dnf install snapd #Fedora 22+/CentOS/RHEL 8 $ sudo yum install snapd #CentOS/RHEL 7 Далее необходимо включить модуль systemd, который управляет основным сокетом мгновенной связи. Эта команда запустит сокет и позволит ему запускаться при загрузке системы. $ sudo systemctl enable --now snapd.socket Шаг 2: Установка Rocket.Chat в Linux Для установки rocketchat-server выполните: $ sudo snap install rocketchat-server Когда установка через snap будет завершена, rocket.chat сервер начнет работать и прослушивать порт 3000. Далее откройте веб-браузер и введите следующий адрес, чтобы настроить rocket.chat через GUI. http://SERVER_IP:3000 После загрузки мастера настройки укажите следующие параметры: полное имя администратора, имя пользователя, адрес электронной почты организации и пароль. Далее надо указать информацию об организации: тип организации, название, отрасль, размер, страна и сайт. Затем нужно указать информацию о сервере - имя сайта, язык, тип сервера, и включение или отключение двухфакторной аутентификации 2FA. На следующей странице нужно зарегистрировать сервер. Здесь есть две опции. Первая - использовать предварительно настроенные шлюзы и прокси, предоставленные Rocket.Chat Вторая - сохранить автономность и создать учетные записи у поставщиков услуг, обновить предварительно настроенные параметры, а также перекомпилировать мобильные приложения с вашими частными сертификатами. Настройка завершена, и ваше рабочее пространство готово, теперь надо нажать Go to your workspace (Перейти в рабочее пространство) Вот так оно выглядит. Шаг 3: Настройка обратного прокси для Rocket.Chat Обратный прокси-сервер, например nginx или Apache, позволяет настроить приложение Rocket.Chat для доступа через домен или поддомен. Rocket.Chat является сервером приложений среднего уровня, который не поддерживает SSL/TLS. Обратный прокси-сервер позволит настраивать сертификаты SSL/TLS для включения HTTPS. Обратный прокси Nginx для Rocket.Chat Сначала установите Nginx. $ sudo apt apt install nginx #Ubuntu/Debian $ sudo dnf install nginx #Fedora 22+/CentOS/RHEL 8 $ sudo yum install nginx #CentOS/RHEL 7 Далее запустите службу Nginx, включите ее автоматический запуск при загрузке системы и проверьте ее статус $ sudo systemctl enable --now nginx $ sudo systemctl status nginx Затем создайте block файл виртуального сервера для приложения Rocket.Chat, например, в каталоге /etc/nginx/conf.d/. $ sudo vim /etc/nginx/conf.d/chat.merionet.com.conf Далее вставьте конфигурацию в этот файл, заменив домен на свой и сохраните. upstream backend { server 127.0.0.1:3000; } server { listen 80; server_name chat.merionet.com; # You can increase the limit if you need to. client_max_body_size 200M; error_log /var/log/nginx/chat.merionet.com.log; location / { proxy_pass http://backend/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forward-Proto http; proxy_set_header X-Nginx-Proxy true; proxy_redirect off; } } Наконец проверьте синтаксис и перезапустите службу Nginx. $ sudo nginx -t $ sudo systemctl restart nginx Обратный прокси Apache для Rocket.Chat Установите пакет Apache2 $ sudo apt install apache2 #Ubuntu/Debian $ sudo dnf install httpd #Fedora 22+/CentOS/RHEL 8 $ sudo yum install httpd #CentOS/RHEL 7 Далее запустите и включите службу apache и проверьте, запущена ли она и работает. ----- В Ubuntu/Debian ----- $ sudo systemctl enable --now apache2 $ sudo systemctl status apache2 ----- В CentsOS/RHEL 7/8 ----- $ sudo systemctl enable --now httpd $ sudo systemctl status httpd Затем создайте файл виртуального хоста для приложения Rocket.Chat, например, в каталоге /etc/apache2/sites-available/ или /etc/httpd/conf.d/. ----- В Ubuntu/Debian ----- $ sudo vim /etc/apache2/sites-available/chat.merionet.com.conf ----- В CentsOS/RHEL 7/8 ----- $ sudo vim /etc/httpd/conf.d/chat.merionet.com.conf Далее вставьте конфигурацию в этот файл, заменив домен на свой и сохраните. <VirtualHost *:80> ServerAdmin admin@merionet.ru ServerName chat.merionet.com LogLevel info ErrorLog /var/log/chat.merionet.com_error.log TransferLog /var/log/chat.merionet.com_access.log <Location /> Require all granted </Location> RewriteEngine On RewriteCond %{HTTP:Upgrade} =websocket [NC] RewriteRule /(.*) ws://localhost:3000/$1 [P,L] RewriteCond %{HTTP:Upgrade} !=websocket [NC] RewriteRule /(.*) http://localhost:3000/$1 [P,L] ProxyPassReverse / http://localhost:3000/ </VirtualHost> В Ubuntu и Debian включите необходимые модули apache2 и перезапустите службу. $ sudo a2enmod proxy_http $ sudo a2enmod proxy_wstunnel $ sudo a2enmod rewrite $ sudo systemctl restart apache2 В CentOS/RHEL и Fedora перезапустите службу apache. # systemctl restart httpd Теперь откройте браузер и введите ваш настроенный адрес и приложение Rocket.Chat станет доступно через ваш домен, настроенный на прокси-сервере. http://chat.merionet.com Шаг 4: Установка клиентов Rocket.Chat Клиентские приложения можно скачать с официального сайта Rocket.Chat. Чтобы установить десктопное приложение в Linux, вы загрузите пакет deb (x64) или rpm (x64) в зависимости от вашего дистрибутива Linux. $ wget -c https://github.com/RocketChat/Rocket.Chat.Electron/releases/download/2.17.7/rocketchat_2.17.7_amd64.deb Или $ wget -c https://github.com/RocketChat/Rocket.Chat.Electron/releases/download/2.17.7/rocketchat-2.17.7.x86_64.rpm Затем установите пакет с помощью диспетчера пакетов dpkg или rpm $ sudo dpkg -i rocketchat_2.17.7_amd64.deb #Ubuntu/Debian $ sudo rpm -i rocketchat-2.17.7.x86_64.rpm #CentOS/RedHat Ручная установка Rocket.Chat Если вы не хотите устанавливать Rocket.Chat через Snaps, вы можете сделать это вручную. Установка Node.js Сначала обновите список системных пакетов: sudo apt update Установите Node.js, npm и все другие зависимости, необходимые для сборки пакетов npm из исходного кода: sudo apt install nodejs npm build-essential curl software-properties-common graphicsmagick Мы будем использовать n, пакет npm, который позволяет интерактивно управлять версиями Node.js. Выполните команды ниже, чтобы установить n и Node.js: sudo npm install -g inherits n sudo n 8.11.3 Установка MongoDB MongoDB - это документно-ориентированная база данных NoSQL, которая используется Rocket.Chat для хранения данных. Импортируйте открытый ключ MongoDB и включите официальный репозиторий MongoDB: sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 9DA31620334BD75D9DCB49F368818C72E52529D4 sudo add-apt-repository 'deb [arch=amd64] https://repo.mongodb.org/apt/ubuntu bionic/mongodb-org/4.0 multiverse' После включения репозитория apt обновите список пакетов и установите MongoDB, набрав: sudo apt update sudo apt install mongodb-org Затем включите и запустите службу MongoDB: sudo systemctl start mongod sudo systemctl enable mongod Создание нового системного пользователя Теперь необходимо создать нового пользователя и группу с именем rocket, которые будут запускать инстанс Rocket.Chat. sudo useradd -m -U -r -d /opt/rocket rocket Добавьте пользователя www-data в новую группу пользователей и измените права доступа к каталогу /opt/rocket, чтобы Nginx мог получить доступ к установке Rocket.Chat: sudo usermod -a -G rocket www-data sudo chmod 750 /opt/rocket Установка Rocket.Chat Переключитесь на пользователя rocket sudo su - rocket Загрузите последнюю стабильную версию Rocket.Chat с помощью curl: curl -L https://releases.rocket.chat/latest/download -o rocket.chat.tgz После завершения загрузки извлеките архив и переименуйте каталог в Rocket.Chat: tar zxf rocket.chat.tgz mv bundle Rocket.Chat Перейдите в каталог Rocket.Chat/programs/server и установите все необходимые пакеты npm: cd Rocket.Chat/programs/server npm install Чтобы протестировать нашу установку перед созданием модуля systemd и настройкой обратного прокси с Nginx или Apache, мы установим необходимые переменные среды и запустим сервер Rocket.Chat export PORT=3000 export ROOT_URL=http://0.0.0.0:3000/ export MONGO_URL=mongodb://localhost:27017/rocketchat Вернитесь в каталог Rocket.Chat и запустите сервер Rocket.Chat, введя следующие команды: cd ../../ node main.js Если ошибок нет, вы должны увидеть следующий вывод: ? +---------------------------------------------+ ? | SERVER RUNNING | ? +---------------------------------------------+ ? | | ? | Rocket.Chat Version: 0.71.1 | ? | NodeJS Version: 8.11.3 - x64 | ? | Platform: linux | ? | Process Port: 3000 | ? | Site URL: http://0.0.0.0:3000/ | ? | ReplicaSet OpLog: Disabled | ? | Commit Hash: e73dc78ffd | ? | Commit Branch: HEAD | ? | | ? +---------------------------------------------+ Остановите сервер Rocket.Chat с помощью Ctrl+C и вернитесь к своему пользователю sudo, набрав exit. Создание модуль Systemd Чтобы запустить Rocket.Chat как службу, нужно создать файл модуля rocketchat.service в каталоге /etc/systemd/system/. sudo nano /etc/systemd/system/rocketchat.service Вставьте следующий код: [Unit] Description=Rocket.Chat server After=network.target nss-lookup.target mongod.target [Service] StandardOutput=syslog StandardError=syslog SyslogIdentifier=rocketchat User=rocket Environment=MONGO_URL=mongodb://localhost:27017/rocketchat ROOT_URL=https://chat.merionet.com PORT=3000 ExecStart=/usr/local/bin/node /opt/rocket/Rocket.Chat/main.js [Install] WantedBy=multi-user.target Сообщите systemd, что мы создали новый файл модуля, и запустите службу Rocket.Chat, выполнив: sudo systemctl daemon-reload sudo systemctl start rocketchat Проверьте статус сервиса: sudo systemctl status rocketchat Вывод должен быть таким: * rocketchat.service - Rocket.Chat server Loaded: loaded (/etc/systemd/system/rocketchat.service; disabled; vendor preset: enabled) Active: active (running) since Wed 2018-11-07 14:36:24 PST; 5s ago Main PID: 12693 (node) Tasks: 10 (limit: 2319) CGroup: /system.slice/rocketchat.service `-12693 /usr/local/bin/node /opt/rocket/Rocket.Chat/main.js Наконец, включите автоматический запуск службы Rocket.Chat во время загрузки: sudo systemctl enable rocketchat Готово, мы установили Rocket.Chat вручную, теперь можно переходить к настройке обратного прокси и инициализации системы, которые были описаны начиная с шага 3. Итоги В этом руководстве вы узнали, как установить Rocket.Chat в Linux и как настроить Nginx и Apache в качестве обратного прокси. Чтобы узнать больше о Rocket.Chat посетите страницу документации.
img
Классификация сама по себе не приводит к определенному состоянию переадресации со стороны сетевого устройства. Скорее, классификация трафика - это первый необходимый шаг в создании основы для дифференцированного поведения пересылки. Другими словами, пакеты были классифицированы и дифференцированы, но это все. Выявление различий - это не то же самое, что дифференцированные действия с этими классами. Наше обсуждение QoS теперь переходит в сферу политики. Как управлять перегруженными интерфейсами? Когда пакеты ожидают доставки, как сетевое устройство решает, какие пакеты будут отправлены первыми? Точки принятия решения основаны в первую очередь на том, насколько хорошо пользовательский интерфейс может выдерживать джиттер, задержку и потерю пакетов. Для решения этих проблем возникают различные проблемы и инструменты QoS. Своевременность: организация очередей с малой задержкой Сетевые интерфейсы пересылают пакеты как можно быстрее. Когда трафик проходит со скоростью, меньшей или равной пропускной способности выходного интерфейса, трафик доставляется по одному пакету за раз, без каких-либо проблем. Когда интерфейс может соответствовать предъявляемым к нему требованиям, перегрузки не возникает. Без перегрузок нет необходимости беспокоиться о дифференцированных типах трафика. Отметки на отдельных пакетах можно наблюдать в статистических целях, но политики QoS, которую нужно применять, нет. Трафик поступает на выходной интерфейс и доставляется. Как было рассказано ранее в лекции "Коммутация пакетов", пакеты доставляются в кольцо передачи после коммутации. Физический процессор исходящего интерфейса удаляет пакеты из этого кольца и синхронизирует их с физической сетевой средой. Что произойдет, если будет передано больше пакетов, чем может поддерживать канал связи? В этом случае пакеты помещаются в очередь, выходную очередь, а не в кольцо передачи. Политики QoS, настроенные на маршрутизаторе, фактически реализуются в процессе удаления пакетов из очереди вывода на кольцо передачи для передачи. Когда пакеты помещаются в очередь вывода, а не в кольцо передачи, интерфейс считается перегруженным. По умолчанию перегруженные сетевые интерфейсы доставляют пакеты в порядке очереди (FIFO). FIFO не принимает стратегических решений на основе дифференцированных классов трафика; скорее, FIFO просто обслуживает буферизованные пакеты по порядку настолько быстро, насколько это позволяет выходной интерфейс. Для многих приложений FIFO - неплохой способ удаления пакетов из очереди. Например, в реальном мире может быть небольшое влияние, если пакет протокола передачи гипертекста (HTTP, протокол, используемый для передачи информации World Wide Web) с одного веб-сервера передается раньше, чем пакет с другого веб-сервера. Для других классов трафика большое внимание уделяется своевременности. В отличие от FIFO, некоторые пакеты следует переместить в начало очереди и отправить как можно быстрее, чтобы избежать задержки и влияния на работу конечного пользователя. Одно из последствий - это пакет, прибывающий слишком поздно, чтобы быть полезным. Другой удар заключается в том, что пакет вообще не поступает. Стоит рассмотреть каждый из этих сценариев, а затем несколько полезных инструментов QoS для каждого. Голосовой трафик по IP (VoIP) должен вовремя. При рассмотрении голосового трафика подумайте о любом голосовом чате в реальном времени, который осуществляется через Интернет с помощью такого приложения, как Skype. В большинстве случаев качество связи приличное. Вы можете слышать другого человека. Этот человек может вас слышать. Разговор протекает нормально. С таким же успехом вы можете находиться в одной комнате с другим человеком, даже если он находится на другом конце страны. Иногда качество звонков VoIP может снижаться. Вы можете услышать серию субсекундных заиканий в голосе человека, при этом скорость передачи голоса нерегулярна. В этом случае вы испытываете джиттер, что означает, что пакеты не поступают стабильно вовремя. Чрезмерно длинные промежутки между пакетами приводят к слышимому эффекту заикания. Хотя пакеты не были потеряны, они не были своевременно доставлены по сетевому пути. Где-то по пути пакеты задерживались достаточно долго, чтобы появились слышимые артефакты. На рисунке 5 показан джиттер при пакетной передаче. Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением. Качество вызова VoIP также может пострадать из-за потери пакетов, когда пакеты на сетевом пути были сброшены по пути. Хотя существует множество потенциальных причин потери пакетов в сетевых путях, рассмотренный здесь сценарий - это "отбрасывание хвоста", когда поступило такое количество трафика, которое выходит за пределы возможностей выходного интерфейса, и в буфере не остается места для добавления в очередь дополнительных излишков. В результате отбрасываются самые последние поступления трафика; это падение называется хвостовым падением. Когда трафик VoIP отбрасывается, слушатель слышит результат потери. Есть пробелы, в которых голос говорящего полностью отсутствует. Отброшенные пакеты могут проходить в виде тишины, поскольку последний бит принятого звука зацикливается, чтобы заполнить пробел, продолжительное шипение или другой цифровой шум. На рисунке ниже показаны отброшенные пакеты через маршрутизатор или коммутатор. Чтобы обеспечить стабильное качество вызовов даже в условиях перегруженности сетевого пути, необходимо применять схему приоритезации QoS. Эта схема должна соответствовать следующим критериям. Трафик VoIP должен быть доставлен: потеря пакетов VoIP приводит к слышимому прерыванию разговора. Трафик VoIP должен доставляться вовремя: задержка или прерывание пакетов VoIP приводит к слышимым заиканиям. Трафик VoIP не должен ограничивать пропускную способность других классов трафика: так же важно, как и VoIP, хорошо написанные политики QoS уравновешивают своевременную доставку голосовых пакетов с необходимостью для других классов трафика также использовать канал. Распространенной схемой, используемой для определения приоритетов трафика, чувствительного к потерям и jitter, является организация очередей с низкой задержкой (LLQ). Никакие RFC IETF не определяют LLQ; скорее, поставщики сетевого оборудования изобрели LLQ в качестве инструмента в наборе политик QoS для определения приоритетов трафика, требующего низкой задержки, jitter и потерь, например, голоса. LLQ есть два ключевых элемента. Трафик, обслуживаемый LLQ, передается как можно быстрее, чтобы избежать задержки и минимизировать джиттер. Трафик, обслуживаемый LLQ, не может превышать определенный объем полосы пропускания (обычно рекомендуется не более 30% доступной полосы пропускания). Трафик, превышающий предел пропускной способности, скорее отбрасывается, чем передается. Этот метод позволяет избежать потери трафика других классов. В этой схеме подразумевается компромисс для услуг классов трафика посредством LLQ. Трафик будет обслуживаться как можно быстрее, эффективно перемещая его в начало очереди, как только он обнаруживается на перегруженном интерфейсе. Загвоздка в том, что существует ограничение на то, сколько трафика в этом классе будет обрабатываться таким образом. Это ограничение налагается сетевым инженером, составляющим политику QoS. В качестве иллюстрации предположим, что канал WAN имеет доступную пропускную способность 1024 Кбит/с. Этот канал соединяет головной офис с облаком WAN поставщика услуг, которое также соединяет несколько удаленных офисов с головным офисом. Это загруженный канал WAN, по которому проходит трафик VoIP между офисами, а также трафик веб-приложений и резервный трафик время от времени. Кроме того, предположим, что система VoIP кодирует голосовой трафик с помощью кодека, требующего 64 Кбит/с на разговор. Теоретически, этот канал с пропускной способностью 1024 Кбит/с может обеспечить одновременные разговоры VoIP 16 × 64 Кбит/с. Однако это не оставит места для других типов трафика, которые присутствуют. Это занятое соединение WAN! Решение должно быть принято при написании политики QoS. Сколько голосовых разговоров будет разрешено LLQ, чтобы избежать нехватки оставшегося трафика полосы пропускания? Можно было бы сделать выбор, чтобы ограничить LLQ пропускной способностью только 512 Кбит/с, что было бы достаточно для обработки восьми одновременных разговоров, оставив остальную часть канала WAN для других классов трафика. Предполагая, что канал перегружен, что произойдет с девятым разговором VoIP, если он должен находиться в ситуации, чтобы политика QoS была эффективной? Этот вопрос на самом деле наивен, потому что он предполагает, что каждый разговор обрабатывается отдельно политикой QoS. Фактически, политика QoS рассматривает весь трафик, обслуживаемый LLQ, как одну большую группу пакетов. После присоединения девятого разговора VoIP будет трафик на 576 Кбит/с, который будет обслуживаться LLQ, которому выделено только 512 Кбит/с. Чтобы найти количество отброшенного трафика, вычтите общий трафик, выделенный для LLQ, из общего предлагаемого трафика: 576 Кбит/с - 512 Кбит/с = 64 Кбит/с трафик LLQ будет отброшен в соответствии с ограничением полосы пропускания. Отброшенные 64 Кбит/с будут исходить от класса трафика LLQ в целом, что повлияет на все разговоры VoIP. Если десятый, одиннадцатый и двенадцатый разговор VoIP присоединиться к LLQ, проблема станет более серьезной. В этом случае 64 Кбит/с × 4 = 256 Кбит/с несоответствующего трафика, который будет отброшен из LLQ, что приведет к еще большим потерям во всех разговорах VoIP. Как показывает этот пример, для управления перегрузкой необходимо знать состав приложений, время пиковой нагрузки, требования к полосе пропускания и доступные варианты сетевой архитектуры. Только после того, как будут учтены все моменты, можно найти решение, отвечающее бизнес-целям. Например, предположим, что 1024 Кбит/с - это максимальное значение, которое вы можете сделать для линии дальней связи из-за ограничений по стоимости. Вы можете увеличить ограничение полосы пропускания LLQ до 768 Кбит/с, чтобы обеспечить 12 разговоров со скоростью 64 Кбит/с каждый. Однако для другого трафика останется только 256 Кбит/с, чего, возможно, недостаточно для удовлетворения потребностей вашего бизнеса в других приложениях. В этом случае можно согласовать с администратором системы голосовой связи использование голосового кодека, требующего меньшей полосы пропускания. Если новый кодек, требующий только 16 Кбит/с полосы пропускания на вызов, развернут вместо исходных 64 Кбит/с, 32 разговора VoIP могут быть перенаправлены без потерь через LLQ с выделенной полосой пропускания 512 Кбит/с. Компромисс? Качество голоса. Человеческий голос, закодированный со скоростью 64 Кбит/с, будет звучать более четко и естественно по сравнению с голосом, закодированным на скорости 16 Кбит/с. Также может быть лучше кодировать со скоростью 16 Кбит/с, чтобы отбрасывать меньше пакетов и, следовательно, общее качество лучше. Какое решение применить, будет зависеть от конкретной ситуации. Через интерфейс может пройти больше трафика, чем указано в ограничении полосы пропускания LLQ. Если ограничение полосы пропускания для трафика, обслуживаемого LLQ, установлено на максимум 512 Кбит/с, возможно, что трафик класса более чем на 512 Кбит/с пройдет через интерфейс. Такое запрограммированное поведение проявляется только в том случае, если интерфейс не перегружен. В исходном примере, где используется кодек 64 Кбит/с, передача 10 разговоров со скоростью 64 Кбит/с по каналу приведет к передаче голосового трафика 640 Кбит/с по каналу пропускной способности 1024 Кбит/с (1024 Кбит/с - 640 Кбит/с = 384 Кбит/с осталось). Пока все другие классы трафика остаются ниже общего использования полосы пропускания 384 Кбит / с, канал не будет перегружен. Если канал не перегружен, политики QoS не вступают в силу. Если политика QoS не действует, то ограничение полосы пропускания LLQ в 512 Кбит/с не влияет на 640 Кбит/с агрегированного голосового трафика. В этой статье о LLQ контекстом был голосовой трафик, но имейте в виду, что LLQ может применяться к любому желаемому виду трафика. Однако в сетях, где присутствует VoIP, VoIP обычно является единственным трафиком, обслуживаемым LLQ. Для сетей, в которых нет трафика VoIP, LLQ становится интересным инструментом, гарантирующим своевременную доставку с малой задержкой и дрожанием других видов трафика приложений. Однако LLQ - не единственный инструмент, доступный для составителя политики QoS. Также пригодятся несколько других инструментов.
img
Пока ты читаешь эту статью, в Интернете идёт настоящая война. Сотни тысяч ботов, сканируют сеть в поисках уязвимых систем, доступов со слабыми паролями, открытых баз данных и отсылают тонны спама с вредоносными вложениями. Миллионы зараженных устройств в огромных ботнетах готовы направить терабайты трафика, чтобы положить какой-нибудь ресурс. Сейчас мы попробуем вооружить тебя знаниями о том, какие бывают виды сетевых атак, вредоносного ПО и других угроз информационной безопасности. Погнали! Типы сетевых атак Начнем с самой известной атаки - DoS - Denial of Service (он же отказ в обслуживании). В ее случае злоумышленник отправляет огромное количество запросов к объекту атаки, перегружая его и тем самым, выводя из строя. Цель этой атаки - перегрузить системные ресурсы объекта и тем самым нарушить его нормальную работу. Возможно, ты также слышал про DDoS (или ддос), с еще одной буквой D, которая означает Distributed - распределенный. Разница между ними в том, что в случае DDoS, атака запускается не с одного компьютера, а при помощи множества подконтрольных злоумышленнику устройств, которые заражены вредоносным ПО, заставляющим их совершать атаку - это называется ботнет. Ботнеты могут быть очень большими. Например, самый большой ботнет Necurs только в 2017 году насчитывал свыше 6 миллионов скомпрометированных устройств. Что же это за дырявые устройства такие? Это, как правило “умные” девайсы интернета вещей IoT - лампочки, пылесосы, часы, холодильники, двери и окна, владельцы которых даже не догадываются, что они давно взломаны. Так что, пока ты по дороге домой приказываешь своей “умной” пароварке готовить рагу, она может участвовать в атаке на какой-нибудь банк на другом конце планеты. Кстати, ботнеты применяют не только для DDoS атак, гораздо чаще их применяют для массовой рассылки писем или проще говоря - спама. Однако, это не тот спам, к которому ты привык. Спам, о котором мы говорим, обычно маскируется под совершенно нормальное почтовое сообщение. Например, это может быть поддельное письмо от известной доверенной организации с каким-нибудь документом во вложении. Но как только ты откроешь этот документ, то запустишь в свой компьютер какой-нибудь страшный вредонос, который откроет к нему доступ злоумышленнику или просто заразит твою систему. Или тебя могут попросить перейти по ссылке на внешне знакомый сайт и ввести там свой логин и пароль. Это, кстати, называется фишинг (phishing). Но самое простое и самое прибыльное для злоумышленника - взять твой компьютер в заложники! Для этого он может подсунуть туда шифровальщик, который зашифрует все файлы операционный системы и сделает их нечитаемыми, а затем потребовать выкуп за ключ для расшифровки в биткоинах. Это называется вымогательское ПО или - ransomware. Помимо шифровальщиков, на твоём компьютере, планшете или мобильном телефоне также могут оказаться: Бэкдоры (Backdoor) - программы, которые позволяют злоумышленнику удаленно управлять твоим девайсом или устанавливать на него всякую дрянь Майнеры (Miner) - скрытая программа, которая тихонечко добывает крипту для злоумышленника за счет твоего компьютера Банкеры (Banker) - крадут с твоего девайса всю информацию, связанную с онлайн банкингом и других платежных системах Шпионские программы (Spyware) - отслеживают что ты набираешь с клавиатуры, следят за тем, что происходит на твоем рабочем столе, записывают видео и делают скриншоты и даже - могут получать доступ к твоей вэб камере или микрофону. Рекламное ПО (Adware) - наградит тебя надоедливым, неудаляемым рекламным баннером, от которого невозможно избавиться. Есть также отдельный подкласс такого ПО - Pornware. О содержимом таких баннеров вы догадываетесь Руткиты (Rootkit) - скрывают пребывание любого из озвученных вредоносов на твоем девайсе - стирает логи, прячет процессы. Всю эту гадость принято объединять одним определением - Троян (Trojan), в честь знаменитого Троянского коня. Вирусы - программы, которые заражают файлы на компьютере вредоносным кодом и инфицируют системы вокруг. Черви - тоже распространяют себя от системы к системе, но используют сетевые протоколы или уязвимые устройства. WannaCry, например, распространялся через уязвимость в протоколе SMB. Он просто сканировал весь интернет и нашел серверы с открытым портом 445, на котором и живёт SMB. Вообще, сканирование портов - это первые шаги для совершения атаки. Злоумышленники ищут в Интернете известные порты прикладных уровней - и пробуют пробить уязвимость этих протоколов, например - подсунуть туда какой-нибудь вредоносный код, который система возможно обработает. А если повезет - то и вовсе получить доступ к открытой информации, живущей на этом порту. Ну, а если владелец всё таки защитил доступ к сетевому ресурсу паролем, то злоумышленник может попробовать метод полного перебора или - Bruteforce, - то есть ввод всех возможных комбинаций логина и пароля, и, если ничто не будет блокировать его действия, то рано или поздно такая комбинация будет найдена. Помни - пароль только из цифр или только из букв может быть взломан меньше чем за секунду! Поэтому стоит воспользоваться нашим генератором устойчивых паролей. На этом все! А пока - сохраняйте спокойствие, не открывайте письма с непонятными вложениями, не переходите по подозрительным ссылкам, не используйте слабые пароли, не вводите их на подозрительных сайтах, не устанавливайте программы из недоверенных источников, используйте антивирус, носите шапочку из фольги, мойте руки и тщательно укрепляйте рубежи своей IT инфраструктуры.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59