Илья

При использовании QinQ к уже тэгированному фрейму добавляется еще один тэг. Наиболее часто используется в провайдинге. Например, от клиента 1 все фреймы дополнительно помечаются тэгом 100, от клиента 2 - 200. Таким образом можно отличить фреймы во влане, например, 10, от первого (они будут тегированы 10 , затем 100) и второго (тегированы 10, затем 200) клиентов.

Private vlan используется, когда надо повлиять на 'видимость' хостов внутри влана. Пару раз видел у хостеров - есть, к примеру, /25 сеть и соответствующий влан, надо каждому хосту (один хост - это один клиентский сервер) разрешить видеть только default gateway и возможно служебный сервер для загрузки ОС. В таком случае порты, к которым подключены маршрутизатор и служебный сервер, работают в режиме promiscuous (в терминах private vlan, опять же), каждый клиентский порт - в режиме isolated (как участник isolated vlan). Двойного тэгирования здесь, как я понял, не происходит.

Вкратце, думаю, можно сказать, что QinQ - это технология мультиплексирования, Private vlan - технология фильтрации на уровне портов (т.е. мы можем указать, каким портам обмениваться трафиком, а каким нет, несмотря на то, что все порты находятся в одном vlan).

Да, для этого есть несколько способов.
1. редирект (При первом способе в браузере будет видна урл второго сервера, наверное не то, что Вам нужно)
2. проксирование (первый сервер обратится к второму, и отдаст контент клиенту)
В зависимости от вэб сервера реализации различные. Я вижу в теге nginx, по этому для него

server { ...
    location test.html {
         proxy_pass http://backend;
  }
}
upstream backend {
   server http://10.0.0.2
}

Буквально вчера занимался подобной проблемой на сайте знакомых с Joomla.

1. Зайдите по ssh и сделайте архив всего сайта, скачайте его к себе на машину.
2. Натравите на архив Касперского или Sophos (опыт показал, что они отлично выявляют зловреды, хотя и не все)
Все обнаруженные уязвимости вычистите прямо на сайте через vi. Если обнаружится, что eval запихали в EXIF картинок, то их просто надо пересохранить и залить обратно на сайт.

Пока антивирус делает свое дело, займитесь следующим:
1. Проверьте .htaccess на наличие левых редиректов. В моем случае все пользователи отправлялись на страницу phpinfo.php c какой-то порнухой.
2. Поищите код, который не найдут антивирусы:
2.1 В некоторых файлах встроена конструкция, позволяющая сохранить файл в произвольное место на сайте. В моем случае это находилось при помощи команды

find. -type file | grep php | xargs grep -l "<?php if (@"

2.2 Поищите и проанализируйте файлы, которые обращаются к exif

find. -type file | grep php | xargs grep -l exif_read_data

2.3 Найдите картинки с троянами

find. -type file | grep jpg | xargs grep -l eval

2.4 Поищите preg_replace, который потом выполняет код

find. -type file | grep php | xargs grep -l preg_replace.*\/e

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

find. -type file | grep php | xargs grep -l 2970d43d7bf4115cdc60e2453bf48b52
find. -type file | grep php | xargs grep -l security_code

4. Внимательно проанализируйте файлы, которые находятся рядом с файлами бекдоров, скорее всего именно в них и находится уязвимость.
5. Слейте дамп базы и поищите в нем eval, preg_replace и прочие прелести
6. После зачистки всей дряни снова сделайте бекапный архив сайта

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

На сервере, где хостятся мои знакомые есть только cvs, им и воспользуемся. Аналогичные действия можно сделать и при помощи git или svn.

1. Вышли в домашнюю директорию

cd

2. Создали пустую директорию для нашего репозитория

mkdir cvsroot

3. Заинитили репозиторий

cvs -d ~/cvsroot init

4. Перешли в директорию, где находится корень сайт. Пусть у вас есть такая структура /home/myusername/mysite/htdocs. Тогда

cd ~/mysite/htdocs

5. Делаем первичный импорт в репозиторий

cvs -d ~/cvsroot import htdocs initial_import initial

6. Сейчас будем удалять старый сайт и забирать его из репозитория

cd ~/mysite
mv htdocs htdocs.bak
cvs -d ~/cvsroot checkout www

7. Добавляем в .htaccess правило, защищающее служебные файлы

RedirectMatch 404 /CVS(/|$)

8. Что это нам дает? Возможно быстрой проверки измененных файлов

cd ~/mysite/htdocs
cvs -qn update

Если все было сделано правильно, то ответ будет

M .htaccess

9. Записываем наши изменения в репозиторий

cvs -q commit -m update

Далее, включаем в cron команду cvs -q commit -m update, да хоть бы и раз в минуту (если сайт сильно посещаемый), включаем лог файлы и ловим изменения, которые происходят в системе. Определив время и изменившиеся файлы, по логам смотрим что, кто, куда и как делал.

Потому что тут более чем на половину — неадекваты. Их over 9000!