По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
SQL Express – бесплатный инструмент начального уровня. Рано или поздно, ваше приложение, которое будет использовать SQL Express столкнется с его существенными ограничениями: Однопроцессорная архитектура; Максимальный размер БД 10 Гб; Максимум 1Гб ОЗУ будет задействован в работе – не больше; Так себе перспектива, не правда ли? Уверены, если вы работаете в Enterprise сегменте, то задумались о миграции на версию Standard и закупили лицензионный ключ. В статье расскажем, как бесшовно перейти с SQL Express 2012 на SQL Standard 2012. Процесс апгрейда редакции Проверим текущую редакцию SQL. Сделаем это с помощью SQL Server Management Studio. Подключаемся к серверу, выбираем наш сервер, нажимаем правой кнопкой мыши на него и выбираем Properties: Проверили – у нас SQL Express. Но, это временно :) Монтируем ISO файл с дистрибутивом Standard 2012, открываем его и нажимаем на setup.exe: Открывается инсталлятор. Выбираем, слева, раздел Maintenance: Внутри раздела, выбираем пункт Edition Upgrade: Запускается процесс апгрейда. Сначала, он проверяет некие пререквизиты. Выглядит это так: Окно закрывается, потом показывается очередное меню проверки. Оно финальное, тут нажимаем Next: Поехали. В разделе Product Key укажите ваш лицензионный ключ: Принимаем лицензионное соглашение. Или не принимаем – решать вам :) Выбираем инстанс SQL. У нас на сервере уже установлен SQL Express, поэтому, он подтянулся в это окно – у вас должно быть так же. Если все ОК, нажимаем Next: На следующем шаге происходит финальная проверка всех условий начала апгрейда: Все! Инсталлятор показывает, что готов приступить к процессу апгрейда. А еще, он показывает какие компоненты буду обновлены в рамках смены редакции и путь к конфигурационному файлу. Жмякаем Upgrade и ждем. Готово! По окончанию, инсталлятор доложит вам, какие именно фичи были успешно обновлены в рамках новой редакции: Помните с чего мы начали? СSQL Server Management Studio :) Снова открываем его и смотрит, что же стало с редакцией нашего SQL:
img
Во любой цепочке безопасности самым слабым звеном был и остается человек. Забывчивые сотрудники, которые пароли хранят в открытом виде, иногда даже приклеивают на монитор; любопытные пользователи, которые не прочь покликать по первой попавшейся кнопке или ссылке. Чем сидеть и ждать, когда кто-то извне взломает и потом принять меры, лучше самому выявить таких нарушителей и предотвратить взлом со всеми его последствиями. Одной из наиболее распространённых видов атак является фишинг атака. Фишинг это такой вид атаки, когда злоумышленник создает поддельную страницу, которая точь-в-точь копирует легальный сайт. Невнимательный пользователь перейдя по поддельной ссылке попадает на эту страницу. Так как внешний вид похож на доверенный ресурс, никто не догадывается проверить URL. Далее он, как ни в чем не бывало, вводит свои данные и нажимает на соответствующую кнопку. Страница перезагружается и перебрасывает пользователя уже на реальный сайт, а последний думает, что где-то ввёл что-то неправильно и еще раз вводит. А тем временем злоумышленник уже получил нужную ему информацию. Это могут быть пароли, номера кредитных карт и т.п. Данную атаку может провернуть даже начинающий хакер. Но мы лишим его такого удовольствия и сами раскинем свою сеть и посмотрим кто туда попадётся. В этом деле нам поможет бесплатный фреймворк gophish. Фреймворк мультиплатформенный, но я предпочитаю и советую поднять всё это на Linux машине. Подойдёт абсолютно любая версия. Перед тем как начать, посмотрите наш ролик "Информационная безопасность компании. Никаких шуток": Погнали. На сайте разработчика переходим по ссылке Download и качаем нужный нам дистрибутив. На Linux машину можно скачать сразу. Копируем ссылку на zip архив и в терминале вводим: wget https://github.com/gophish/gophish/releases/download/v0.8.0/gophish-v0.8.0-linux-64bit.zip Далее разархивируем скачанный файл: unzip gophish-v0.8.0-linux-64bit.zip Если в системе нет пакета unzip качаем его. Для Debian/Ubuntu apt-get install unzip Для RedHat/CentOS: yum install unzip Затем открываем файл config.json любым удобным вам редактором: nano config.json Меняем указанные ниже значения admin_server.listen_url 127.0.0.1:3333 IP/Port админ панели gophish admin_server.use_tls False Нужно ли защищённое соединение с админ панелью admin_server.cert_path example.crt Путь к SSL сертификату admin_server.key_path example.key Путь к приватному ключу SSL phish_server.listen_url 0.0.0.0:80 IP/Port самого фишинг сервера, куда переходят пользователи по ссылке Здесь первый параметр я поменял на 0.0.0.0:3333 так как мой сервер находится за межсетевым экраном и доступа извне туда нет. Но при необходимости можно организовать это. Также я отключил требование TLS. Во внутренней сети особой надобности в нем нет. Далее просто запускаем файл gophish командой: ./gophish И переходим на админскую часть нашего фишинг сервера. По умолчанию имя пользователя admin, а пароль gophish. Всё это можно потом поменять, но по порядку. При входе открывается панель, где видны проведённые атаки и результаты. Кликнув на иконке статистики можно перейти к детальным отчётам. Тут отображается вся информация о пользователях, которые перешли по ссылке, ввели данные. Есть еще отчёт по открытым письмам, но если пользователь не кликнул на ссылку в письме и не перешёл на нашу фишинговую страницу, то это значение не меняется. Поэтому, на мой взгляд, это просто лишняя информация. Теперь начнём непосредственно настраивать систему и готовить нашу атаку. Пойдем снизу вверх. На вкладке User Management можно создать новых пользователей. Для этого переходим на нужную страницу и нажимает на кнопку Add user: Хотя и пользователям можно назначать права, особого смысла тут тоже нет. Потому, что пользователь, во-первых, не видит никакие кампании другого пользователя, во-вторых, имеет те же самые права, что и администратор, с тем лишь отличием, что он не может создавать других пользователей или сбрасывать их пароли. На этой всё странице интуитивно понятно, так что не буду слишком углубляться. На вкладке Account Settings можно поменять имя пользователя пароль текущего пользователя. Следующая вкладка Sending Profiles. Вот тут то и переходим к этапу подготовки нашей атаки. На этой странице настраиваются профили, от имени которых будет идти атака. Вводим название профиля, e-mail, с которого будут рассылаться письма, адрес SMTP сервера и порт, имя пользователя и пароль при необходимости. Тут бы я хотел остановиться поподробней. Когда планировали свою атаку, мы решили создать почту на общедоступном почтовом ресурсе. Но там стоял лимит на число получателей, что в принципе и правильно. Поэтому первая наша кампания провалилась. И тогда мы оперативно создали новую DNS запись на нашем AD и провернули затею. Создание доменной записи я тут не буду объяснять, ибо этим занялись наши сисадмины, за что им спасибо. Далее можно создать mail заголовки, но для тестовой среды это не критично. После ввода данных можно отправить тестовое письмо, дабы проверить работоспособность нашего профиля: Затем переходим к созданию самой страницы. Делается это на вкладке Landing Pages. Здесь можно пойти двумя путями: сверстать свою страницу с нуля или же просто скопировать с реального сайта и подкорректировать нужное. Для этого предусмотрен очень удобный инструмент в самой системе. Нажав на кнопку Import Site вы можете ввести URL любого сайта и фреймворк сам подтянет оттуда весь дизайн, только учтите, что для этого системе нужен доступ в интернет. Чтобы перехватывать введённые данные, нужно поставить соответствующие галочки. Capture Submitted Data и Capture Passwords. Учтите, что пароли не шифруются и хранятся в базе системы в открытом виде! Также не забываем прописать адрес ресурса, куда будет перенаправляться пользователь после ввода данных. Следующий шаг создание шаблона письма, для чего переходим на страницу Email Template. Тут тоже можно и самому набрать текст или же импортировать уже готовое письмо. Ещё один минус, нельзя вставлять фото из локального ресурса, что досадно. Можно только вставить ссылку на картинку, что в моём случае тоже не сработало картинка не открывалась. Но есть и удобные фичи: переменные например. Ниже приведён список переменных, которые можно указать в тексте, создавая персонализированные письма. {{.RId}} Уникальный ID цели {{.FirstName}} Имя цели {{.LastName}} Фамилия цели {{.Position}} Должность {{.Email}} Почтовый адрес {{.From}} Отправитель {{.TrackingURL}} Ссылка отслеживания {{.Tracker}} Псевдоним <img src="{{.TrackingURL}}"/> {{.URL}} Адрес фишинг ссылки {{.BaseURL}} Та же фишинг ссылка, только без RID Далее создаем пользователя или группу пользователей, которые получат наше письмо. Делается это на вкладке Users & Groups. Здесь тоже разработчики предусмотрели массовый импорт адресов. Если у вас настроен AD и Exchange Server, попросите админов отдать вам список всех акттвных пользователей в формате CSV. Затем импортируйте их в систему. И, наконец, переходим к созданию самой атаки. Для этого переходим на вкладку Campaigns. Здесь в принципе дублируется основная панель. Выбираем New Campaign задаём название кампании, из выпадающих списков выбираем ранее созданные шаблоны письма и фейковой страницы, указываем профиль, с которого пойдут письма, и определяем целевую группу. В URL прописываем адрес нашего сервера. Здесь можно написать и IP или же, что еще лучше, задать доменное имя, которое похоже на доверенный ресурс. В этом случае пользователь в адресной строке увидит не IP, а полноценный домен. Также можно выставить дату начала кампании. И, собственно, запускаем кампанию и ждем пока кто-то попадётся на нашу удочку. Система заботливо показывает текущий статус отправки, и, в случае ошибки, указывает почему не удалось отправить письмо. На этом, пожалуй все. Система очень лёгкая, интуитивно понятная. Удачи в реализации!
img
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки: Первую часть статьи про траблшутинг EIGRP можно почитать здесь. Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась. Было настроено автосуммирование или кто-то настроил суммирование вручную Split-horizon блокирует объявление маршрутной информации. Перераспределение было настроено, но информация из EIGRP не используется. Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются. Case #1 Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов: OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF1(config-router)#network 1.1.1.0 0.0.0.255 OFF1(config-router)#network 192.168.12.0 0.0.0.255 OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary OFF2(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config-router)#network 192.168.12.0 0.0.0.255 Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите: По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации. Видно, что на OFF1 не настроен distribute lists. OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит. Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list. Другой быстрый способ проверить это - использовать команду show ip protocol. В этом случае использование show run могло бы быстрее обнаружить distribute-list. Вот список доступа, доставляющий нам неприятности. OFF2(config)#router eigrp 12 OFF2(config-router)#no distribute-list 1 out Удалим distribute-list. Задача решена! Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации. Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа. Case #2 В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация: OFF1(config)#router eigrp 12 OFF1(config-router)#network 192.168.12.0 OFF1(config-router)#network 10.0.0.0 OFF2(config)#router eigrp 12 OFF2(config-router)#network 192.168.12.0 OFF2(config-router)#network 10.0.0.0 Как вы видите - это довольно базовая конфигурация. Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации. Давайте включим отладку и посмотрим, что мы можем найти. OFF2#clear ip eigrp 12 neighbors Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс. Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам: Суммирование было кем-то настроено Авто-суммирование включено для EIGRP. Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary OFF2(config)#router eigrp 12 OFF2(config-router)#no auto-summary Отключение автоматического суммирования должно помочь. Ну что, наши сети появились в таблице маршрутизации. Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями. Case #3 Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов: Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование. Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16. Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит? OFF2#clear ip eigrp 12 neighbors Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс. Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1. Давайте проведем отладку OFF1. Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его. Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем. OFF1(config)#router eigrp 12 OFF1(config-router)#no auto-summary Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование. Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена! Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов. Case #4 Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов. Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах. Суммирование было настроено на OFF2 и должно быть объявлено к OFF1. К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так. Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show. Странно, это единственная сеть, которую OFF2 объявляет. Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24. Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи. OFF2(config)#interface loopback 0 OFF2(config-if)#no shutdown OFF2(config)#interface loopback 1 OFF2(config-if)#no shutdown Включим интерфейсы. Теперь мы видим, что суммирование объявляется. Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена! Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации. ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон! Case #5 Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов: CONC(config)#router eigrp 123 CONC(config-router)#no auto-summary CONC(config-router)#network 192.168.123.0 OFF1(config-if)#router eigrp 123 OFF1(config-router)#no auto-summary OFF1(config-router)#network 192.168.123.0 OFF1(config-router)#network 2.2.2.0 0.0.0.255 OFF2(config)#router eigrp 123 OFF2(config-router)#no auto-summary OFF2(config-router)#network 192.168.123.0 OFF2(config-router)#network 3.3.3.0 0.0.0.255 Видно, что все сети объявлены. Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов. К сожалению, наши маршрутизаторы не видят ничего ... Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит. CONC#clear ip eigrp 123 neighbors Сбросим соседство EIGRP, чтобы ускорить процесс. В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой. CONC(config)#interface serial 0/0 CONC(config-if)#no ip split-horizon eigrp 123 Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора. Теперь мы видим, что маршрутизатор-концентратор объявляет все сети. OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все. Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали. Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить. Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом: Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3: Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1? Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC. У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2. Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом: Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем! Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2 Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3. Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2. OFF2(config)#int s0/0 OFF2(config-if)#frame-relay map ip 192.168.123.2 301 Давайте frame-relay map сами. Теперь роутер OFF2 знает, как связаться с роутером OFF1 Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map: OFF1(config)#int s0/0 OFF1(config-if)#frame-relay map ip 192.168.123.3 201 Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1. И наш пинг проходит!
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59