Коммуникационная маркетинговая программа - это документ. Этот документ излагает, обосновывает и детализирует маркетинговые цели и маркетинговые планы компании.

Обычно этот документ состоит из трех частей:

Изложение маркетинговых и финансовых целей компании;

Обоснование планируемых маркетинговых действий компании;

Медиа-план маркетинговой деятельности компании.

Разработка маркетинговой программы реализуется совместной рабочей группой, в которую входят консультанты, маркетологи и заинтересованные лица компании заказчика. Работы оформляются в виде проекта. Проект управляется в соответствии с корпоративными стандартами.

Этапы разработки маркетинговой программы:

- Определение целей.

Разработка коммуникационной маркетинговой программы начинается с определения целей, которые предполагается достичь с помощью комплекса маркетинговых мероприятий. Правильная постановка целей является залогом их достижения. Цели должны быть достижимы, измеряемы и выражать потребность бизнеса. При определении целей крайне полезными могут оказаться материалы, которые возможно уже есть в компании. К их числу могут относиться бизнес-план или план развития продукта, стратегические цели компании и система сбалансированных показателей, маркетинговый план, анализ конкурентной среды, состояние рынка и общие тренды и другое.

Крайне полезно определение целей сделать на общем собрании компетентных и ответственных сотрудников компании, предоставив каждому из них возможность высказать свое мнение о целях, важных для компании и реализуемых с применением маркетинговых инструментов.

- Разработка маркетинг-концепции.

На этом этапе необходимо решить, к какой целевой аудитории будет обращаться маркетинговая программа, какими конкретными маркетинговыми мероприятиями она должна быть наполнена.

Концепция в первую очередь определяет общее направление маркетинговой программы и содержит видение основных маркетинговых инструментов. Разработка маркетинг-концепции является креативной задачей. Здесь могут рождаться новые маркетинговые инструменты с уникальными механизмами из реализации, идеи по названиям этих инструментов, слоганы и другое. При разработке маркетинг-концепции анализируется возможная привлекательность маркетинговой программы для целевой аудитории.

Вместе с тем, при создании маркетинг-концепции могут быть использованы референтные библиотеки маркетинговых акций, отраслевые или смежные маркетинговые кейсы и лучшие практики. Дается предварительная оценка эффективности, как отдельных маркетинговых инструментов, так и всей маркетинговой программы в целом.

- Апробирование новых маркетинговых акций.

Для того, что бы выиграть конкурентную борьбу за покупателя необходимо создавать и использовать новые и нестандартные маркетинговые акции. Применение таких акций обеспечит привлекательность разработанной маркетинговой программы для покупателей. Вместе с тем, существуют и риски того, что новая акция не сработает так, как хотелось бы ее создателям. Оценить потенциал новой акции и риски ее использования в маркетинговой программе поможет пробное применение акции и анализ достигнутых результатов перед широкомасштабным запуском.

- Определение целевых и контрольных групп покупателей.

Правильно выделенные целевые аудитории - залог экономической эффективности разрабатываемой маркетинговой программы.

- Определение маркетинговых мероприятий.

Полный список маркетинговых акций, мероприятий и инструментов создается на этом этапе. Разрабатываются и уточняются правила работы каждой из акций, входящих в список. Определяется последовательность и порядок взаимодействия акций и мероприятий между собой. Формируется список необходимых маркетинговых инструментов (карты постоянных покупателей, купоны, подарочные карты), которые будут использоваться в рамках программы. Создаются сценарии коммуникаций, поддерживающих проведение акций, включая голосовую коммуникацию с использованием контакт-центра, SMS- и почтовые рассылки.

- Медиа-план поддержки маркетинговой программы.

Мероприятия, заложенные в маркетинговой программе, могут нуждаться в рекламной и PR-поддержке. Такие медиа-кампании могут использоваться для инициации выполнения маркетинговой программы или повышения ее эффективности. Разработка медиа-плана так же является одним из этапов при подготовке маркетинговой программы.

- Оценка эффективности маркетинговой программы.

Оценка эффективности наиболее важный этап при подготовке маркетинговой программы. От него зависит принятие решения о финансировании программы. От него зависят инвестиционные ожидания. Завышенная оценка приведет к потере доверия со стороны инвесторов, наполняющих маркетинговый бюджет. Заниженная оценка приведет к упущенной прибыли.

- Налоговое и правовое обоснование маркетинговой программы.

Налоговое и правовое обоснование маркетинговой программы. В случаях включения в маркетинговую программу сложных или неиспользовавшихся ранее акций или мероприятий рекомендуется подготовить схему налогообложения торговых операций, проводимых в рамках программы. Налоговая и правовая экспертизы маркетинговой программы, проведенные внешними аудиторскими и юридическими компаниями, повысят ее надежность и безопасность для бизнеса.

- Техническое обоснование маркетинговое программы.

При подготовке маркетинговой программы особое внимание стоит уделить ее техническому обоснованию. Если программа не будет иметь необходимой технической поддержки, то она просто не состоится.

На этом этапе разработки маркетинговой программы стоит обратить внимание на способы идентификации покупателей, принимающих участие в акциях, требования к эмиссии маркетинговых инструментов, которые запланированы к использованию в рамках программы, схему организации маркетинг-процессинга торговых операций, схемы коммуникации с целевыми группами покупателей, наличие и состояние основных и резервных каналов передачи данных, оценка рисков технических и программных сбоев и методы управления этими рисками.

- Выполнение маркетинговой программы.

Самый важный этап. Становится понятно, все ли работает так, как задумано. Оправдываются ли оценки эффективности. Требуется ли вмешательство в ход выполнения маркетинговой программы.

Для того, что бы управлять маркетинговой программой, необходимо непрерывно получать и анализировать показатели эффективности по всем проводимым маркетинговым акциям, входящим в программу. Отклонение этих показателей от оптимистических и пессимистических оценок, сформированных при подготовке программы, дают возможность принимать решение по управлению программой и достижению плановых результатов.

сталь, норка, говядина, бумага 28 сентября 2010 в 19:47

Основы iptables на примере Debian глазами младенца

О чем же пойдёт речь

Всё очень просто, в очередной раз объясняя на форуме новичкам в мире Linux, что да как я понял, что на просторах интернет не найти собранную воедино статью с объяснением не только настройки iptables, но и некоторых сетевых основ.
Так что вашему вниманию я представляю небольшой экскурс по настройке firewall в Linux. Углубимся лишь в настройку netfilter/iptables, остальных прикладных вопросов мы несомненно тоже коснёмся, ведь нам не хватает именно комплексных ответов на наши вопросы… И я постараюсь ка можно более доходчиво здесь все изложить.

Как это выглядит

Мы будем рассматривать типичную схему для офисов и для квартир, да-да именно квартир! Мало у кого есть собственный маленький сервачок дома под столом, но у большинства интернет дома раздается через роутер и в большинстве своём они тоже прошиты Linux.
Это типичная схема малого офиса. Когда к интернет подключен 1 компьютер(сервер), а остальные подключаются к интернет уже через этот сервер.

Поехали, потихонечку...

И так что же мы имеем:

• сервер с 2мя сетевыми картами и установленным на нём Debian Lenny
• имеющийся по умолчанию в Debian Lenny firewall - netfilter/iptables
• локальную сеть из N компьютеров, все соединены через коммутатор, в том числе и сервер

что такое NAT

Для начала нам нужно понять, что настраивать мы будем самый обыкновенный NAT(Network Address Translation). Для жаждущих, я в конце упомяну и о проксе сервере на примере squid. Как я уже сказал разжёвывать будем практически всё.
Что же такое NAT? На самом деле все просто, все компьютеры имеют физический (MAC) и сетевой (IP) адреса. Нас в данный момент интересуют IP адреса. IP адрес в пределах одной сети должен быть уникальным! А при нынешнем стандарте IPv4 уникальными могут быть всего-то 4 294 967 296 (2 32), что совсем не много и они практически кончились. но не переживайте вот вот вступит в широкое распространение IPv6, а там адресов навалом!
Но тут вы можете заметить, компьютеров значительно больше того числа, что позволяет IPv4 или скажете, что у друга дома такой же адрес как и у вас! И вот тут-то и заходит речь о NAT - он позволяет соединять компьютерные сети между собой используя единственный, свой IP адрес, действия фаервола при этом называется SNAT(Source NAT или подмена адреса источника). Т.е. в 99% случаев вся ваша контора выходит в интернет под 1 IP адресом, при этом внутри офиса у каждого он свой. О классах IP адресов вы сможете прочесть в интерне.

Теперь, когда мы знаем что такое NAT и для чего он нужен, можно приступать непосредственно к настройке сервера.

транзитный трафик

Все команды выполняются от имени root(суперпользователь). В Debian по умолчанию отключен так называемый транзитный трафик, т.е. по умолчанию предусмотрена работа только как единичная машина. Как вы уже догадались, без транзитного трафика нету и NAT. Для его включения достаточно изменить 1 цифру - $ echo 1 > /proc/sys/net/ipv4/ip_forward , но данная настройка слетит после перезагрузки, так что лучше поправить конфиг - $ nano /etc/sysctl.conf далее ищем строчку #net.ipv4.ip_forward=1 и убираем «решётку»(символ комментария) в начале строки и проверяем что значения равно 1! Теперь можно приступать непосредственно к конфигурированию iptables.

настраиваем iptables

В интернет, есть много статей о том как писать правила в iptables и что с их помощью можно творить, наиболее полным и приятным для чтения мне показалась .
И так приступим. Для начала очистим таблицы от лишних правил, вдруг там что было лишнего…
$ iptables -F
$ iptables -t nat -F
$ iptables -t mangle -F
Лишнее почистили. Очень важно понять и помнить, что правила в iptables применяются иерархически, т.е. правило стоящее выше выполнится раньше. Все цепочки по умолчанию имеют политику ACCEPT - разрешают всё. что не попало под правила данной цепочки.
Условимся, что интерфейс смотрящий в локальную сеть - eth0, а в интернет - eth1, локальная сеть имеет адреса 192.168.0.0/24, а провайдер выдал нам статический адрес 10.188.106.33(пускай и не «белый» - о типах ip адресов вы также можете посмотреть в интернет). И так пишем:
$ iptables -A FORWARD -i eth0 -o eth1 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A FORWARD -i eth1 -o eth0 -d 192.168.0.0/24 -j ACCEPT
$ iptables -P FORWARD DROP
тем самым разрешили ходить транзитным пакетам через firewall для нашего диапазона ip адресов, а всё остальное запрещаем.
Теперь сам NAT:
$ iptables -A POSTROUTING -s 192.168.0.0/24 -o eth1 -j SNAT --to-source 10.188.106.33
Этого достаточно для того что бы у вас заработал NAT.

по мелочам...

На клиентах указываем ip из выбранного диапазона и указываем в качестве шлюза ip адрес нашего сервера(обычно его назначают первым из подсети - я оставлю это на ваше усмотрение). Все сетевые настройки на сервере можно провести так:
$ nano /etc/network/interfaces в нём указываются настройки ваших сетевых интерфейсов.

доступ в недры сети через шлюз или DNAT

И тут вы поняли, что в сети у вас есть Windows Server к которому у вас всегда был простой доступ по RDP, а тут вылез это назойливый шлюз на Debian! Всё очень просто - надо всего лишь добавить DNAT правило в наш iptables.
Что за зверь DNAT? DNAT (Destination NAT или подмена адреса получателя) - сетевые карты работают в таком режиме, что они принимают только пакеты адресованные именно им, а зайти на наш сервер если ip под которым он выходит в интернет сидят еще десяток машин в вашем офисе? Как запрос дойдёт именного до него? На самом деле все запросы такого рода упираются в наш шлюз. И всё что нам надо сделать это задать правила для работы с такими пакетами.
$ iptables -A PREROUTING -i eth1 -p tcp -m tcp --dport 3389 -j DNAT --to-destination 192.168.0.2
Это простое правило будет переадресовывать все пакеты приходящие на шлюз из интернет на порт TCP 3389(именно его использует RDP протокол) на ваш внутренний Windows Server. И, вуаля, у вас все работает.

итак что там с любимым squid

И хотя сейчас все работает, у всех есть интернет и все работает, некоторым всё же нужен прокси сервер. Я не буду рассказывать о настройке squid, я покажу правило которое позволит сделать его «прозрачным». В сквид надо лишь прописать волшебное слово transparent в нужном месте и он начнём корректно обрабатывать свалившееся на него запросы.
Пишем $ iptables -A PREROUTING -d! 192.168.0.0/24 -i eth0 -p tcp -m multiport --dports 80,443 -j REDIRECT --to-ports 3128 .
И что же нам это даёт? Теперь все запросы на web страницы с ваших рабочих мест по http((80) и https(443) протоколам будут перенаправляться на порт который слушает squid. Вы получает контентную фильтрацию, информацию о том кто где был и что делал в интернет, пользователь ни чего не подозревая работает как и раньше…

немного безопасности

Следует хоть минимально защитить свой шлюз поэтому добавим еще пару правил
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j ACCEPT
$ iptables -A INPUT -i eth1 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
$ iptables -P INPUT DROP
Тем самым запретили любое общение непосредственно с шлюзом, кроме уже установленных соединений, т.е. те что были инициированы вами и вы просто получаете на них ответы. Не бойтесь наш DNAT до этих правил просто не доходит…

почему так мало?

Статья не резиновая и обо всем все-равно не расскажешь… Я привел минимальный набор действий и понятий что бы вы могли начать осваивать такую махину как шлюз на Linux. Здесь можно говорить очень и очень долго, обсуждая многие аспекты и возможности netfilter.

Итого

Как мы видим все действительно просто! Главное это понять принцип функционирования сети и не боятся настраивать и читать большие мануалы.
Надеюсь мне удалось собрать воедино информацию достаточную для начала вашей дружбы с программными маршрутизаторами на основе Linux.

Теги: iptables, netfilter, NAT

В Linux существует некоторое количество решений для настройки фаервола, однако многие из них являются на самом деле только фронтэндами для настройки iptables, и некоторые не совсем удачными. В принципе, неплохо, когда можно быстро настроить фаервол, но когда вы разберетесь с iptables, вы сможете это сделать быстрее и тоньше. Тонкая настройка iptables фронтэндам обычно недоступна.

Приступим. Начнем с простого, и потом будем усложнять конфигурацию. Здесь на сайте уже есть статья про автозагрузку правил iptables, поэтому мы не будем сейчас рассматривать загрузку правил, а сосредоточимся на самих правилах. Настраивается фаервол всегда под учетной записью root.

Сценарии сетевых подключений

Перед настройкой фаервола обязательно нужно иметь точное представление о том, какие сетевые соединения и как должны устанавливаться при работе системы, чтобы все сервисы могли нормально работать. Чем точнее у нас картина работы сетевых сервисов, как работающих на нашем сервере, так и на других серверах, тем более тонко можно настроить систему. Поэтому желательно всегда сначала описывать сценарии того, как всё должно работать, и только потом начинать настраивать фаервол. Сценарий можно написать в любом текстовом редакторе. Сначала описываем все внешние сервисы, с которыми работает сервер, а затем все сервисы, которые работают на сервере. Зачем это надо? Чтобы точно представлять сам процесс работы, без углубления в техническую часть. После написания максимально точного сценария можно приступать к настройке фаервола. Описание в сценарии должно выглядеть примерно так:

1) Все пользователи могут просматривать сайт. По умолчанию сайт на русском языке.
2) Если пользователи пришли с адресов <список-адресов-или-маска-подсети>, то им должен быть показан сайт на украинском. В нашем примере это будет, допустим, интернет-магазин с одним доменным именем, отображаемый на русском или украинском языке, и имеющий в продаже свой набор для России и Украины. У нас будет просто два сайта, один на русском, второй на украинском, и по адресу, с которого пришел клиент, будет определяться, на какой сайт он попадет. Пример взят из головы, на практике, конечно, такие вопросы решаются по другому. Можно также не разрешать просмотр сайта с китайских адресов из-за постоянного спама в комментариях на китайском.
3) Из офиса должна быть доступна почта, из других мест она не должна быть доступна.
4) Извне должна быть обеспечена возможность подключения к ВПН
5) Мы можем использовать только несколько DNS-серверов, которым мы доверяем. Все остальные сервера DNS должны быть недоступны
6) …..

И так далее. Думаю, достаточно для простого примера. Смысл в том, чтобы максимально точно определить картину сетевого взаимодествия. Любой сценарий имеет только одну цель — формализовать взаимодействие с пользователями и сервисами до составления описаний соединений, включающих порт, протокол, адрес источника, адрес назначения для каждого соединения.

Настройка iptables: Самая простая конфигурация

Если говорить про боевые сервера, то настройка фаервола на двух серверах может сильно различаться, в зависимости от задач, которые выполняют эти сервера. Поэтому я постараюсь описать общие принципы, которыми можно пользоваться при настройке фаервола для любых серверов. Это только база для дальнейшей настройки.

В первую очередь, необходимо очистить загруженные правила:

Iptables -F INPUT iptables -F OUTPUT iptables -F FORWARD

INPUT, OUTPUT, FORWARD — это три основные цепочки, по которым будут идти пакеты, входящие, исходящие и проходящие с интерфейса на интерфейс.

После этого необходимо задать политику по умолчанию. Их всего две — ACCEPT и DROP, принимать пакеты или не принимать. Для боевого сервера всегда необходимо выбирать DROP, а затем открывать всё, что необходимо и не более того.

Для задания таких политик необходимо предварительно разрешить соединения по SSH, будем считать, что мы не меняли стандартный порт (что обычно следует на боевых серверах делать сразу после установки SSH-сервера).

Iptables -t filter -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

И после этого уже можно приступать к изменению политик по умолчанию:

Iptables -P INPUT DROP iptables -P OUTPUT ACCEPT iptables -P FORWARD DROP

Для цепочки OUTPUT пока можно оставить политику по умолчанию ACCEPT, разрешающую исходящие соединения, к ней можно переходить после настройки цепочки INPUT, когда мы запретим входящие соединения. На многих серверах достаточно бывает правильно настроить цепочку INPUT, но мы рассмотрим позже также и настройку OUTPUT для более жесткой конфигурации.

Итак. В данный момент у нас открыт только порт SSH-сервера для входящих соединений, на все остальные порты соединения проходить не будут. Теперь надо добавить прием соединений на порты остальных сервисов, если они на вашем сервере запущены.

Iptables -t filter -A INPUT -p tcp -m tcp --dport 25 -j ACCEPT

DNS (обычно достаточно разрешить UDP, но можно также добавить и TCP):

Iptables -t filter -A INPUT -p udp -m udp --dport 53 -j ACCEPT

Iptables -t filter -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Iptables -t filter -A INPUT -p tcp -m tcp --dport 110 -j ACCEPT

Iptables -t filter -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Но это еще не всё. Порты открыты, сервисы доступны извне, но почта не работает и доменные имена не резолвятся. Дело в том, что при запросе DNS-серверов запрос отправляется с произвольного свободного порта из числа непривелегированных, точно так же, как и соединение с другим почтовым сервером. И ответ эти сервисы отправляют на тот же самый порт. А этот порт, как вы понимаете, у нас закрыт. Мы могли бы открыть этот порт, но мы не знаем, с какого порта будет исходящее соединение. Поэтому мы можем сделать самое простое, что может быть,- разрешить соединения с определенных портов удаленного компьютера:

Iptables -t filter -A INPUT -p tcp -m tcp --sport 25 -j ACCEPT

Iptables -t filter -A INPUT -p udp -m udp --sport 53 -j ACCEPT

Эти два правила разрешают входящие соединения с портов 25/tcp и 53/udp, поэтому, когда с этих портов приходят пакеты по соответствующему протоколу, они будут приняты. Если вы планируете обновлять систему, программное обеспечение или устанавливать пакеты, необходимые для работы, то вам придется разрешить соединения с 80 порта удаленных машин.

Вот теперь самая простая конфигурация iptables у нас готова.

После внесения правил в таблицы, необходимо их сохранить. Для этого можно воспользоваться, например, скриптом.

Обработка источника соединения

Идем дальше. соединение по определенным портам нам необходимо не со всем Интернетом, а с определенными машинами, с определенными IP-адресами. Поэтому мы можем немного усложнить правила, добавив в них адрес источника пакетов.

Iptables -t filter -A INPUT -s 123.123.123.123 -p tcp -m tcp --dport 22 -j ACCEPT

Данное правило позволяет принимать пакеты на 22 порт по протоколу TCP только из источника с адресом 123.123.123.123, на это указывает параметр «-s» (source, источник). Таким образом вы можете ограничить соединения с сервером по SSH одним определенным IP-адресом, либо определенной подсетью, если укажете маску подсети, из которой разрешены соединения вместо отдельного IP-адреса.

Если у вас всегда используется один и тот же почтовый шлюз, через который ваш сервер отправляет почту, то вы можете, например, ограничить соединения с порта 25/tcp, указав этот шлюз в качестве источника.

Правила для конкретного сетевого интерфейса или IP-адреса

На сервере может быть несколько сетевых интерфейсов. Обычно их как минимум два — внешний сетевой и так называемый loopback-интерфейс 127.0.0.1, доступ к которому извне невозможен, если отсутствует соответствующее перенаправление пакетов. У вас также может как минимум еще один IP-адрес, используемый совместно с алиасом сетевого интерфейса, или еще один физический сетевой интерфейс. И на каждом IP-адресе или сетевом интерфейсе могут работать определенные сервисы. Например, на одном веб-сервер Apache, а на втором сервер службы доменных имен bind9. И когда вы разрешаете соединения на определенный порт без указания этого сетевого интерфейса, вы открываете доступ к этому порту на всех интерфейсах. Поэтому есть два способа сузить область действия разрешения.

Первый способ — указать IP-адрес, для которого будет разрешен доступ.

Iptables -t filter -A INPUT -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT

Этот пример показывает, как можно использовать адрес назначения в правиле iptables. При этом также можно использовать адрес источника:

Iptables -t filter -A INPUT -s 123.123.123.123 -d 234.234.234.234 -p tcp -m tcp --dport 22 -j ACCEPT

В данном пример мы уже ограничиваем доступ двумя адресами, что позволяет получить доступ по SSH к серверу по адресу 234.234.234.234 с адреса 123.123.123.123, с остальных адресов доступ вы получить не сможете.

Второй способ — указать имя сетевого интерфейса. Этот способ также применим, когда внешний адрес может измениться. В случае, если изменится адрес на сетевом интерфейсе, с предыдущим вариантом вы потеряете доступ к серверу. Указание имени интерфейса осуществляется следующим образом:

Iptables -t filter -A INPUT -i eth0 -s 123.123.123.123 -p tcp -m tcp --dport 22 -j ACCEPT

Такой вариант разрешает доступ по SSH на сетевом интерфейсе eth0, на остальных сетевых интерфейсах доступ по SSH будет отсутствовать.

Всё, что мы только что рассмотрели — это только самое начало, в следующей части будет продолжение…