По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Резервное копирование данных - важная часть как индивидуальной, так и корпоративной инфраструктуры. Машины с операционной системой Linux могут использовать rsync и ssh для облегчения процесса. Rsync - это утилита командной строки, которая позволяет передавать файлы в локальные и удаленные места. Rsync удобен в использовании, поскольку он по умолчанию входит в состав большинства дистрибутивов Linux. Вы можете настроить инструмент, используя многие из доступных опций. В этом случае мы будем использовать SSH в сочетании с rsync для защиты передачи файлов. Следуйте этому руководству, чтобы узнать, как использовать rsync для резервного копирования данных. В руководстве будет приведено несколько примеров, иллюстрирующих, как работает этот процесс. Базовый синтаксис Rsync для локальной и внешней передачи Синтаксис использования инструмента rsync отличается для локальной и удаленной передачи. Для локальных резервных копий синтаксис следует этой базовой схеме: rsync options SOURCE DESTINATION Для передачи файлов во внешнее хранилище мы будем использовать несколько иной шаблон: rsync options SOURCE user@IP_or_hostname:DESTINATION В обоих случаях источником и местом назначения являются каталог или путь к файлу. Резервное копирование данных с помощью Rsync Для лучшего понимания того, что делает rsync, мы будем использовать подробный ключ -v. Кроме того, поскольку мы будем создавать резервные копии данных в каталогах, мы будем использовать режим архива -a для рекурсивной синхронизации. Существует множество вариантов и примеров rsync, поэтому используйте любой из них, который вам нужен. Rsync Dry Run - Меры предосторожности Утилита rsync позволяет вам по-разному манипулировать вашими данными. Так что будьте осторожны при резервном копировании файлов. Если вы используете неправильный вариант или неправильный пункт назначения, вы можете смешать свои данные. Хуже того, вы можете случайно перезаписать или удалить файлы. По этой причине используйте параметр --dry-run, чтобы убедиться, что инструмент делает то, что вы хотите. Возможна случайная потеря данных, но этот параметр помогает предотвратить ее. Для простых передач вам может не понадобиться использовать --dry-run, но когда речь идет о большем наборе данных, мы настоятельно рекомендуем вам это сделать. Используйте основной формат синтаксиса и добавьте --dry-run: rsync options --dry-run SOURCE DESTINATION Используйте Rsync для локального резервного копирования данных Мы начнем с резервного копирования каталога на той же машине Linux. Путь может быть любым - другой раздел, жесткий диск, внешнее хранилище и так далее. Используйте полный путь как к источнику, так и к месту назначения, чтобы избежать ошибок. Например, чтобы создать резервную копию Dir1 из документов в /media/hdd2/rscync_backup, используйте команду rsync в этой форме: rsync -av /home/test/Documents/Dir1 /media/hdd2/rsync_backup На выходе отображается список переданных файлов и каталогов, а также другие сведения о передаче. Примечание. Чтобы создать новый каталог в месте назначения и создать в нем резервную копию файлов, добавьте в конец пути к месту назначения косую черту /. Если вы добавите завершающую косую черту к источнику, то исходный каталог не будет создан в месте назначения. Rsync передает только свое содержимое в этом случае. Используйте Rsync для резервного копирования данных по сети Для безопасного резервного копирования данных по сети rsync использует SSH для передачи. Ваш сервер должен быть настроен на разрешение SSH-соединения. Как только вам удастся подключиться к удаленному компьютеру через SSH, вы можете начать резервное копирование данных в место на этой машине. Например, чтобы создать резервную копию Dir1 для резервного копирования на другой машине по сети, введите: rsync -av /home/test/Documents/Dir1 test@192.168.56.101:/home/test/backup В выводе перечислены каталоги и файлы, перенесенные rsync на другой компьютер. Вы можете проверить, действительно ли файлы находятся на удаленном сервере: Если вы подключаетесь в первый раз, вам нужно будет ввести свой пароль и подтвердить его, когда вы получите запрос. Нет необходимости вводить имя пользователя для удаленных передач, если вы хотите подключиться как текущий пользователь. Примечание: вы можете избежать ввода пароля каждый раз, когда вы хотите создать резервную копию данных с помощью rsync через SSH. Настройте аутентификацию на основе ключей SSH, и вы сможете использовать беспарольный вход на удаленный компьютер. В примере, который мы использовали здесь, предполагается, что SSH использует порт по умолчанию. Если вам нужно указать другой порт для SSH-соединения, используйте флаг -e и введите параметры SSH. Чтобы указать порт 4455, например, выполните указанную выше команду в следующем формате: rsync -av -e 'ssh -p 4455' /home/test/Documents/Dir1 test@192.168.56.101:/home/test/backup При необходимости вы можете удалить исходные файлы после их переноса в другое место. Сжать данные при резервном копировании с помощью Rsync Чтобы сэкономить место, вы можете сжать свои данные перед их переносом в другое место. Вы можете использовать встроенную опцию rsync для сжатия данных или можете использовать другой инструмент для этого перед запуском rsync. Чтобы сжать данные во время передачи, используйте параметр -z с командой rsync. rsync -avz /home/test/Documents/Dir1 test@192.168.56.101:/home/test/backup Другой вариант - использовать команду zip, чтобы заархивировать ваши файлы или каталог, а затем запустить rsync. В нашем случае мы заархивируем Dir1 в Dir.zip: zip /home/test/Documents/Dir1.zip /home/test/Documents/Dir1 Затем перенесите этот файл в другое место: rsync -avz /home/test/Documents/Dir1.zip test@192.168.56.101:/home/test/backup Теперь у вас есть заархивированная копия вашего каталога на удаленном сервере. Вы также можете сделать это для локальных передач, если хотите иметь резервную копию на другом диске или разделе. Итог В этом руководстве показано, как создавать резервные копии данных с помощью rsync как локально, так и по сети. Будьте осторожны при использовании этого инструмента и обязательно выполните пробный запуск, если вы не уверены в параметрах rsync, которые хотите использовать.
img
В предыдущей статье мы рассказали, как включить дополнительные функции в OpenScape Voice. Сейчас мы расскажем о том, как создать Call Pickup группы (группы перехвата). /p> Прежде всего, разберемся, что такое Call Pickup группа и для чего она нужна. Она представляет собой несколько телефонных номеров, объединенных в одну группу, внутри которой пользователи могут “перехватывать” звонки друг друга. Другими словами, можно принять звонок, приходящий на другой телефон, состоящий в группе. В одной группе может находиться до 64 абонентов. Сам абонент может находиться только в одной группе перехвата. Создание Call Pickup группы Для начала нужно создать саму группу перехвата. Для этого в Common Management Portal перейдем в раздел Configuration → OpenScape Voice → Business Group → Teams → Call Pickup Groups и нажмем на кнопку Add. Там во вкладке General в поле Group Number указываем номер группы, который будет использоваться в системе. Во вкладке Members нажимаем на Add и там указываем номер телефона, который необходимо добавить в группу. Если телефон уже находится в другой группе, то он будет удален из нее и добавится в новую. Внизу отображается список номеров, состоящих в группе. После того как все абоненты добавлены нажимаем Save и сохраняем настроенную группу. Также добавлять абонента в группу можно в разделе Configuration → OpenScape Voice → Business Group → Members → Subscribers , найдя необходимый номер и перейдя во вкладку Groups. В поле Call Pickup Group ID нужно указать номер группы и нажать Save. Настройка сервисного кода в системе (Prefix Access Code) Для настройки сервисного кода для группы перехвата перейдем в раздел Configuration → OpenScape Voice → Business Group → Translations → Prefix Access Codes и нажмем Add для добавления нового кода. В поле Prefix Access Code вводим код, который будет использоваться для групп перехвата, а в поле Digit Position указываем его длину, чтобы он впоследствии удалялся. Ниже в поле Destination Name из списка выбираем функцию Call Pickup Orig, нажимаем OK и Save. Настройка Call Pickup группы на телефонах Openscape Заходим на веб-интерфейс телефона и переходим во вкладку Administrator → System → Features → Addressing и в поле Group Pickup URI указываем код группы перехвата, который создали ранее. Нажимаем Submit и переходим во вкладку Configuration. Тут необходимо выбрать тип уведомлений, который будет применяться. Group Pickup Tone allowed включает короткий тоновый сигнал, при звонке в группу. При Group Pickup as ringer будет проигрываться стандартный сигнал вызова. Настройка визуальной индикации в пункте Group Pickup visual alert имеет несколько опций: Prompt → индикация на дисплее, перехват при поднятии трубки, Notify - индикация на дисплее, перехват при нажатии кнопки ОК, FPK Only → индикация на программируемой клавише, перехват при нажатии на нее.
img
Инъекции Инъекция происходит, когда злоумышленник пытается отправить данные в веб-приложение с намерением заставить его выполнить что-то, что не было предусмотрено при разработке приложения. Наиболее распространенным примером этой уязвимости является SQL-запрос, используемый с целью извлечения конфиденциальных данных организаций. Например, злоумышленник может ввести код SQL в форму, которая ожидает имя пользователя с открытым текстом. Если эта форма ввода не защищена должным образом, это приведет к выполнению этого кода базой данных. Таким образом злоумышленник может читать, изменять и удалять информацию базы данных, которая для него не предназначена. Все, что принимает параметры в качестве входных данных потенциально может быть уязвимо для атаки путем внедрения кода. Поскольку формы пользовательского ввода являются главным способом реализации таких атак, то лучшим подходом для предотвращения таких угроз является контроль и проверка пользовательского ввода. Процесс контроля направлен на проверку того, разрешен ли тип входных данных, представленных пользователем. Проверка ввода гарантирует, что это допустимый тип, формат и длинна. Обрабатывается только то значение, которое проходит проверку. Это помогает противодействовать любым командам, вставленным во входную строку. Так же для предотвращения угрозы используется функция экранирования символов для пользовательского ввода. Это делается чтобы СУБД не путала пользовательский запрос с SQL командой. Одним из лучших способов идентификации атак с использованием инъекций SQL является использование брандмауэра веб- приложений (WAF). WAF отслеживает трафик, который приходит на веб-сервер, и определяет шаблоны которые представляют угрозу. Таким образом для предотвращения данной атаки необходимо применять проверку ввода, параметризированные запросы, хранимые процедуры и экранирование в сочетании с надежным брандмауэром. Это повысит шансы успешной защиты от данной атаки. Нарушение системы аутентификации Уязвимости в системах аутентификации (входа в систему) могут предоставить злоумышленникам доступ к учетным записям пользователей и даже возможность компрометировать всю систему с помощью учетной записи администратора, Например, злоумышленник, обладая базой тысяч известных комбинаций имени пользователя и пароля, может, используя ручные или автоматические методы может выполнить атаку грубой силы. Из-за того, что многие пользователи не соблюдают требований к сложности пароля и веб-сервис не ограничивает количество попыток ввода пароля, злоумышленник может без труда получить доступ к интересующей его учетной записи. Для уменьшения вероятности успеха данной атаки рекомендуется применять многофакторную аутентификацию, чтобы предотвратить автоматизированный ввод данных, проверку на сложность пароля, а также ограничение или задержку повторных попыток входа. Практически полностью уменьшить вероятность такой угрозы может применение аутентификации по токенам. Незащищенность конфиденциальных данных Уязвимость конфиденциальных данных является одной из наиболее распространенных уязвимостей в списке OWASP. Уязвимость заключается в доступности критичных данных, которые должны быть защищены. Если веб-приложение не защищают конфиденциальные данные, такие как финансовая информация, медицинская информация и пароли, злоумышленники могут получить доступ к этим данным и использовать их в своих целях. Плохая реализация криптографической защиты информации и использование небезопасных протоколов основные причины популярности данной угрозы. Одним из популярных способов кражи конфиденциальной информации является реализация атаки "человек посередине". Такая атака осуществляется, когда злоумышленник подключается между веб-браузером и веб-сервисом и перехватывает или изменяет соединение. Затем злоумышленник может просматривать весь трафик и собирать информацию или выдавать себя за одну из двух сторон. Например, злоумышленник может находиться между пользователем и веб-сервисом, который пользователь собирается посетить и собирать его данные для входа. Это можно сделать с помощью перехвата HTTP-соединения между пользователем и веб-сервисом. Захват этого соединения позволяет действовать злоумышленнику как прокси-сервер, собирая и изменяя информацию, передаваемую между пользователем и сайтом. Кроме того, злоумышленник может украсть файлы cookie пользователя. Это небольшие фрагменты данных, созданные веб-сайтом и хранящиеся на компьютере пользователя для идентификации и других целей. Такие файлы могут быть использованы для захвата сеанса пользователя, позволяя злоумышленнику выдавать себя за этого пользователя. Отсутствие шифрования конфиденциальных данных является основной причиной, по которой эти атаки все еще широко распространены. Риск несанкционированного получения данных может быть сведен к минимуму путем шифрования всех конфиденциальных данных, а также отключение временного хранения конфиденциальной информации для повторного использования. Одним из способов защиты передаваемых данных является наличие на веб-сервисе сертификата SSL (Secure Sockets Layer). Это стандартная технология безопасности для установления зашифрованного канала связи между веб-сервисом и браузером. Данный сертификат помогает обеспечить целостность передаваемых данных при передаче между веб-сервером и клиентом. Более новой и надежной версией протокола SSL является протокол TLS. Также для защиты от таких атак используют протокол HTTP Strict Transport Security (HSTS), который обеспечивает безопасное соединение SSL/TLS с любым браузером или приложением, блокируя любые незащищенные HTTP соединения, а также предотвращает кражу cookie. Кроме того, администраторы и разработчики веб-сервисов следует не использовать лишнюю конфиденциальную информацию. Нарушение контроля доступа Управление доступом позволяет разграничивать доступ к информации или функциям для разных пользователей. Если управление доступом нарушено, злоумышленник, имеющий доступ к учетной записи, может использовать привилегии, которые не предназначены для этой учетной записи. Это позволяет обычной учетной записи читать и копировать файлы, которые должны быть доступны только администратору. Неправильная настройка элемента управления доступом позволяет злоумышленникам обходить авторизацию и выполнять задачи, которые доступны только привилегированным пользователям, администраторам. Например, веб-приложение может позволить пользователю изменить учетную запись, в которую он вошел, просто изменим часть url-адреса без какой-либо другой проверки. Это происходит из-за неправильной конфигурации или вовсе отсутствия настройки прав на администрирование и управление приложением. Предоставляя глобальный доступ к панели управления хостингом, серверу через FTP/SSH, базе данных или другим приложениям на сервере мы открываем доступ к функциям или просмотру конфиденциальных данных и файлов. Для снижения рисков использования нарушенного контроля доступа рекомендуется предоставление только необходимые функции для выполнения задачи и только в течение времени, необходимого для выполнения указанной задачи, применение многофакторной аутентификации ко всем возможным точкам доступа, аудит веб-сервера, удаление не использующихся служб и учетных записей. Для предотвращения нарушения доступа необходимо запретить глобальный доступ к функциям управления сервером. Каждый пользователь должен иметь доступ только к его информации. Небезопасная конфигурации Наличие безопасной конфигурации всех компонентов инфраструктуры требуется для безопасности веб-сервера. Небезопасные и уязвимые компоненты могут быть представлены в различных формах: фреймворки, веб-серверы, сервер баз данных, сетевые службы и сами приложения. По умолчанию настройки компонентов сервера в своем большинстве небезопасны и это открывает злоумышленникам поле для атаки. Например, использование настроек по умолчанию в серверах баз данных может привести к доступу ка закрытой службе через публичный IP-адрес, что в сумме с использованием установленным производителем по умолчанию паролем чревато очень серьезными проблемами с утечкой или потерей критичных, или конфиденциальных данных. Злоумышленник сможет изменять и читать данные в числе которых могут быть выводимые браузером данные для пользователя или же сессионные cookies, утечка которых может привести к использованию злоумышленником платежных данных пользователей или же другой секретной информации. Ежедневно исследователи находят уязвимости в системах и компонентах. От уязвимостей нулевого дня трудно защититься. Уязвимость нулевого дня является ошибкой при разработке программного обеспечения, которая несет угрозу безопасности программного обеспечения. Термин "нулевой день" относится к недавно обнаруженной уязвимости программного обеспечения. Поскольку разработчик не знает о возможной уязвимости при проектировании ПО то, когда он узнает о найденном недостатке неожиданно, разработчик не имеет возможности сразу исправить эту уязвимость, так как для этого нужно подготовить официальный патч или обновление для исправления проблемы. У разработчика есть "ноль дней" чтобы исправить проблему, которая была обнаружена и возможно уже используется злоумышленниками, чтобы успеть защитить своих пользователей. Использование небезопасных компонентов приводит к краже и широкомасштабным атакам. Когда приложение использует небезопасные компоненты, злоумышленники могут узнать все, что им нужно знать о серверах, компонентах и многом другом. Поэтому необходимо постоянно проверять актуальность программного обеспечения, так как уязвимости могут быть обнаружены в самых разных программных компонентах таких как сервера, базы данных и операционной системе. Для предотвращения угроз, связанных с использованием неправильной конфигурации системы, следует использовать только необходимые компоненты и функции, автоматизировать процесс для проверки эффективности конфигураций и параметров во всех средах, использовать методы сегментации и контейризации для ограничения поверхности атаки. Межсайтовое выполнение сценариев XSS (Cross Site Scripting) Межсайтовое выполнение сценариев это широко распространенная уязвимость, которая затрагивает многие веб-приложения. XSS-атаки состоят из внедрения вредоносных клиентских сценариев на веб-сайт и использование ве-сайта в качестве распространения. Риск XSS заключается в том, что он позволяет злоумышленнику вводить контент на веб-сайт и изменять способ его отображения, заставляя браузер жертвы выполнять код, предоставленный злоумышленником во время загрузки страницы. Такие уязвимости возникают, когда веб-приложение позволяет пользователям добавлять пользовательский код в URL-ссылку или на веб-сайт, который будет виден другим пользователям. Эта уязвимость может быть использована для запуска вредоносного кода JavaScript в браузере жертвы. XSS-атаки не направлены на конкретную цель. Злоумышленник просто использует уязвимость сайта или приложения, внедряя код через случайного пользователя и далее этот сайт или приложение становится центром рассылки вредоносных сценариев для множества других пользователей. Например, злоумышленник может отправить жертве электронное письмо, которые выглядит как официальное письмо от банка с ссылкой на веб-сайт этого банка. Однако эта ссылка может иметь какой-то вредоносный код JavaScript, оставленный в конце URL-адреса. Если сайт банка не будет должным образом защищен от межсайтового выполнения сценариев, то этот вредоносный код будет запущен в веб-браузере жертвы, когда он пройдет по ссылке. Уязвимость XSS дает злоумышленнику почти полный контроль на самым важным программным обеспечением компьютеров в настоящее время браузерами. Существует три типа межсайтовых скриптовых атак: Хранимые XSS (постоянные). Наиболее опасный тип уязвимостей, так как злоумышленник получает доступ к серверу и уже с него может управлять вредоносным кодом. Вредоносный код постоянно хранится на целевом сервере и выполняется каждый раз при обращении к сервису. Это может произойти на любых страницах с вводом данных пользователей, например, в полях комментариев, базе данных и может быть встроен как текст картинки, или рисунки. Отраженные XSS (непостоянные). Отраженная атака происходит, когда вредоносный сценарий не хранится на сервере, а содержится во входных данных, отправленных от пользователя к серверу. Это атака реализуется путем отправки жертве ссылки, содержащей вредоносный сценарий, на электронную почту или другим способом. Проходя по ссылке, жертва отправляет запрос с вредоносным кодом к серверу, который автоматически берет данные из вредоносной строки и отправляет модифицированный ответ жертве. В итоге браузер жертвы распознает запрос как надежный и выполняет вредоносный скрипт. DOM-модели. Третий тип атаки, известный как атака на основе DOM (Document Object Model) не является распространённой, но может произойти. Атака происходит, когда среда DOM изменяется в веб-браузере жертве и приводит к запуску вредоносного кода на стороне клиента. Атаки на основе DOM отличаются тем, что они используют уязвимости на стороне клиента, а не на стороне сервера. Для снижения рисков XSS-атаки используются межсетевые экраны, которые помогают смягчить такие атаки. Также для предотвращения таких атак рекомендуется осуществлять экранирование ненадежных данных HTTP-запроса или же использовать фреймворки, которые автоматически экранируют XSS. Небезопасная дессериализация Эта угроза нацелена на многие веб-приложения, которые часто сериализиуют или дессериализуют данные. Сериализация означает получение объектов из кода приложения и преобразование их в формат, который может использоваться для других целей, таких как хранение данных на диске или их потоковая передача. Дессериализация это обратное действие, преобразование сериализованных данных обратно в объекты, которые может использовать приложение. Когда поток данных преобразуется в объекты, вредоносные или измененные объекты могут вызвать серьезные проблемы безопасности. Небезопасное осуществление десериализации является результатом десериализации данных из ненадежных источников и может привести к серьезным последствиям, таким как DDoS-атака, удаленное выполнение кода и запуска программ. Несмотря на то, что можно предотвратить такие уязвимости используя мониторинг и проверку типов, единственным надежным способом защиты от атак десериализации является запрет десериализации из ненадежных источников. Если же это сделать невозможно, то для предотвращения таких атак также может быть осуществлена проверка целостности, например, при помощи цифровой подписи, применение строгих ограничений типа при создании объектов. Также изолирование и выполнение кода, который десериализуется в средах с низким уровнем привилегий. Использование компонентов с известными уязвимостями Значительная часть веб-сервисов состоит из множества специальных компонентов, такие как библиотеки и фреймворки (англ. - framework), которые поставляются сторонними компаниями. Эти компоненты являются частями программного обеспечения, которые помогают разработчикам сократить время, избежать выполнения избыточной работы и обеспечить необходимую функциональность. Например, популярный фреймворк, применяемый для разработки интерфейсов React или же библиотеки для проведения тестирования. Злоумышленники постоянного ищут уязвимости в таких компонентах и потом используют для организации атак. Обнаружив уязвимость в безопасности одного из компонентов приложения, злоумышленник может сделать уязвимыми сотни тысяч веб-сервисов. Разработчики компонентов часто выпускают обновления для устранения известных уязвимостей, однако администраторы и разработчики не всегда имеют возможность обновить компоненты до последней версии. Чтобы свести к минимуму риск запуска компонентов с известными уязвимостями, разработчикам следует удалять неиспользуемые компоненты из своих проектов, а также проверять актуальность обновлений и получать их от надежных источников. Недостаточный мониторинг и логирование Большинство веб-сервисов не предпринимают достаточных шагов для обнаружения нарушений безопасности данных. Среднее время обнаружения нарушений составляет около 200 дней после того, как оно произошло. Это дает злоумышленникам много времени, чтобы нанести ущерб, прежде чем происходит какая-то реакция. Логирование и мониторинг необходим, чтобы оставаться в курсе любых подозрительных изменений приложения.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59