Category: it

Category was added automatically. Read all entries about "it".

gul

Об этом журнале

Я gul_kiev.
Это мой журнал для постингов на технические темы - про Cisco, Juniper, unix и прочее, что может быть неинтересно многим френдам моего основного аккаунта.
gul

Победа спамеров над мейллистами

СЯУ, что очередная интернет-технология становится историей из-за несовместимости с новыми стандартами, на этот раз это списки рассылки.

Введение в курс дела.
Письмо (email) состоит из заголовка и тела письма. В заголовке написаны отправитель, получатель, тема письма и ещё всякая информация о письме. В теле, соответственно, текст. При пересылке письма оно вместе с заголовком оборачивается в конверт (envelope), и между почтовыми системами передаются "mail from" (отправитель), "rcpt to" (получатель) и "data" (текст письма вместе с заголовком). Тут важно, что адреса отправителя и получателя на конверте могут не соответствовать адресам в заголовке. Такое часто встречается при переадресации (если письма для user@domain пересылаются на другой адрес, login@host, то в заголовке остаётся "To: user@domain", а на конверте получается уже "To: login@host"), а также в списках рассылки (в заголовке "To: maillist", envelope to "user@domain").

Борьба со спамом и фишингом.
Технология почты позволяет любому человеку отправлять почту куда угодно, и, мало того, от какого угодно адреса. Этим стали активно пользоваться спамеры, подставляя случайный адрес отправителя. Для защиты от этого придумали SPF. Владелец домена может в DNS указать список хостов, от которых может быть отправлена почта с этим доменом в поле "From", а если почта принята откуда-то не оттуда, значит, это спам. Механизм простой и эффективный. Однако не защищающий от подделки header from. Есть ещё callout check (встречный коннект на отправителя, проверяющий, принимает ли он почту), но он проверяет лишь существование адреса отправителя, а не его валидность, и имеет ряд других недостатков.

DMARC.
Поскольку спамеры продолжают активно рассылать почту с поддельным header from, а envelope from пользователю фактически недоступен, возникла необходимость защиты header from от подделки. Для этого разработали DMARC. Владелец домена может включить защиту DMARC, и сервера, поддерживающие эту технологию, не будут принимать почту с header from, отправленную другими сайтами. Но как отличить, это спамер отправил почту от чужого адреса, или это честный пользователь написал в maillist? К сожалению, никак. И вот списками рассылки ради борьбы со спамом решили пожертвовать. И что же они предлагают делать администраторам списков рассылки? А вот что:
1. Никак не модифицируйте письма, т.е. не ставьте хеш списка рассылки в тему письма, не дописывайте футер с информацией о рассылке и т.п. К сожалению, в таком случае получателю будет трудно отличить письма из списка рассылки от личных писем.
2. Добавляйте OAR header. К сожалению, это не поможет, потому что его никто не поддерживает, и нужен механизм доверия между сервером рассылки и почтовой системой получателя. То есть, например, если отправитель в @yahoo.com, а получатель в @gmail.com, то для использования этого способа необходимо, чтобы gmail.com доверял мне (как администратору списка рассылки). Выглядит не очень реальным. К тому же, реализованных механизмов для добавления и обработки этого OAR, как я понял, ещё нет, это просто концепция.
3. Заменяйте header from на какой-то адрес в своём домене. А чтобы получатель мог ответить отправителю, пересылайте почту на этот адрес оригинальному отправителю.
А что, если на этот адрес (светящийся в поле From списка рассылки) будет приходить спам, и он будет пересылаться оригинальному отправителю, какой сервер попадёт в blacklists? Тот, от которого приходит спам получателю, т.е. мой, а не тот, который использовали спамеры. Жизнь спамеров таким образом облегчается!

Обнаружил из-за жалобы, что письма пользователей @yahoo.com в спелеорассылке не попадают примерно половине подписчиков - пользователей почтовых систем, проверяющих DMARC.
Что в такой ситуации делать, не знаю. Нахожусь в некоторой растерянности.

UPD: Некоторые ссылки.
Yahoo breaks every mailing list in the world including the IETF's
dmarc and forwarding
DMARC overview
gul

Про паранойю при создании файлов в unix shell

Если вам в shell command line нужно создать файл, к которому никто, кроме вас, не должен иметь доступ на чтение, как вы это делаете?
Я обычно делал так:
touch filename
chmod 600 filename
после чего писал туда всё, что мне было нужно.

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

А как это делаете вы?
Я сейчас знаю несколько правильных способов.
Collapse )
gul

Программирование

Не очень сложная, но интересная задачка.
Есть односвязный список. В каждом элементе есть некое значение, ссылка на следующий элемент списка и ссылка на какой-то произвольный элемент этого списка.
Нужно сделать независимую копию этого списка.
Ограничения: время выполнения должно быть линейно от длины списка, количество дополнительной памяти (помимо старого и нового списка) константно, т.е. не должно зависеть от длины списка.
Никакими блокировками и параллельным доступом можно не заморачиваться (типа один поток).

UPD: Ни одного решения не дождался.
Эх... :(

[Решение]
На первом проходе из списка A->B->C->D делаем копию каждого элемента, и указатели next ставим таким образом, чтобы получился список A->A'->B->B'->C->C'->D->D', т.е. нечто вроде
for (p=head; p; p=p->next)
{
  p1=memdup(p);
  p->next = p1;
  p=p1;
}

(memdup() - это malloc() и memcpy(), по аналогии с strdup()).

Вторым проходом подправляем rnd-указатели (на произвольный элемент списка) для новых элементов - тот, что указывал на X, теперь будет указывать на X->next, который X':
for (p=head->next; p; p=p->next->next)
{
  p->rnd = p->rnd->next;
}

Третьим проходом делаем из одного длинного списка A->A'->B->B'->... два отдельных, оригинальный A->B->C->D и новый A'->B'->C'->D':
newhead = head->next;
for (p=head, p1=newhead; p; p=p->next, p1=p1->next)
{
  p->next = p->next->next;
  p1->next = p1->next->next;
}

Всё.
Три прохода, две дополнительные переменные - p, p1.
newhead - начало нового списка.

gul

Я знаю шутку...

Оригинал взят у bytebuster463 в Я знаю шутку...
1. Я знаю отличную шутку про UDP, но не факт, что она до вас дойдет.
2. Я знаю отличную шутку про TCP, но если она до вас не дойдет, то я повторю.
3. А кто знает отличную шутку про ARP?
4. А вы слышали шутку про ICMP?
5. Вам еще кто–то рассказывал шутку про STP?
6. Я подожду Антона и расскажу классную шутку про QoS.
7. Про MTU тоже есть кла
8. XML
9. А про FSMO роли шутить могут не более пяти человек.
10. Подождите все, я расскажу шутку о сети типа "шина".
11. Я бы рассказал отличную шутку про Token Ring, но сейчас не моя очередь.
12. Стой–стой, послушай сначала шутку о прерываниях.
13. Помню времена, когда шутка про модем пшшшшшшш.....
14. Только что, специально для сообщества пришла шутка про мультикаст.
15. Жаль, что шутка про Fault Tolerance не может состоять больше, чем из одного слова.
16. Настало время рассказать шутку про NTP.
17. Я сейчас расскажу отличную шутку про VPN, но ее поймет только один.
18. К шутке про SCTP вначале должны все подготовиться.
19. Из–за одного, кто зевнул, придётся заново рассказывать шутку про frame relay в топологии point–to–multipoint.
20. А шутки про HDLC обычно не понимают те, кто знает другие шутки про HDLC.
21. Про DWDM шутят сразу несколькими голосами.
22. Шутка про Е3 — это 30 одинаковых шуток про Е1 и еще две шутки, понятных только тем, кто в теме.
23. Лучшее в шутках про проприетарные протоколы это УДАЛЕНО.
24. Единственная проблема в шутках про Token Ring в том, что если кто–то начнёт рассказывать шутку пока говорите вы, обе шутки обрываются.
25. Все любят шутки про MitM. Ну, кроме Алисы и Боба, все.
26. идти Самое про BitTorrent — они могут порядке. в шутках лучшее в любом
27. Я бы рассказал шутку про CSRF, если бы ты САМ только что этого не сделал.
28. IGMP шутка; пожалуйста, передай дальше.
29. Нет… Нет ничего… Нет ничего забавного… Нет ничего забавного в шутках… Нет ничего забавного в шутках про определение MTU.
30. PPP шутки всегда рассказываются только между двумя людьми.
31. Шутки про RAID почти всегда избыточны.
32. Фрагментированные шутки…
33. … всегда рассказываются…
34. … по кусочкам.
35. Вы уже слышали шутку про Jumbo фреймы? Она о–очень длинная.
36. Самое клёвое в шутках про rsync, что вам её рассказывают только если вы не слышали её до этого.
37. Проблема с IPv6 состоит в том, что их трудно вспомнить.
38. DHCP шутки смешны, только если их рассказывает один человек.
39. Жаль никто не помнит шутки про IPX
40. У кого есть кабель? Есть смешная шутка про RS–232 и полусмешная про RS–485
41. Я сейчас всем расскажу шутку про бродкаст
42. У меня есть примерно 450 000 шуток про BGP
43. У кого есть пароли, приходите за шутками про RADIUS
44. Шутку про 127.0.0.1 каждым может пошутить себе сам
45. А что, шутки про IPv4 уже закончились?
46. Шутки про RFC1918 можно рассказывать только своим
47. Шутки про IPv6 плохи тем, что их мало можно кому рассказать
48. Шутки про SSH–1 и SSH–2 несовместимы между собой
49. Про Schema Master шутит только один в этом лесу
49. Шутки про MAC–адрес могут не дойти до тёзок
xx. Тут шутка про Banyan подросла
50. DNS–сервер не понял шутку про DDoS и ему её стали пересказывать сто тысяч раз в секунду
51. В шутках про IPSec надо говорить, кому их рассказываешь
52. И ГОСТ, и ISO согласны, что есть 7 уровней рассказывания шуток
52.1 Министерство обороны США понимает только четыре уровня шуток
53. Шутки про шутки про шутки часто звучат в туннелях
54. Шутки про 10/100/1000BASE–T вряд ли услышат с расстояния больше 100 м
Off: Шутки про TFT оставляют смазанное впечатление

gul

Cleanup juniper config

Лень всё же победила. :)
Вместо того, чтобы в очередной раз руками вычищать из конфига куски, которые перестали использоваться (policy-statements, firewall filters и т.п.) написал для этого перловый скрипт.
Ему параметром или на stdin даётся конфиг, он его анализирует, и на выходе выдаёт команды удаления неиспользуемых policy-statements, prefix-lists, community, as-path, firewall filters, firewall policers. Эти команды удаления можно потом копипастнуть в конфиг. Если используется dynamic-db, динамический конфиг можно дать вторым параметром - тогда скажет, что можно удалить и оттуда.

Сначала подумал, не сделать ли его как junoscript (на commit или как op script), но решил, что это и писать сложнее, и использовать менее удобно.
Написан за час (может, два) на коленке, написан неправильно (парсинг конфига, если по уму, нужно делать совсем не так), сделан исключительно под мои конфиги, так что корректную работу с другими конфигами не обещаю. Но может и сработать. :) У меня отработал и на MX, и на EX. Ловит inactive-части конфига, использование firewall filters как input/output на интерфейсе или вложенные, либо как fail-filter в urpf, полисеры - используемые из фильтров или непосредственно на интерфейсе (input/output/arp), policy-statements - в конфигурации протоколов или вложенные.
Если кому предложит удалить что-то лишнее или наоборот - не предложит удалить то, что надо бы - пишите, поправлю. Это только самая-самая первая версия.

Надо будет и для cisco ios такое тоже сделать.

Или это я велосипед изобретаю, и оно такое давно есть стандартное?
gul

Ужасы spanning-tree

Давненько ничего сюда не постил, сорри. Материалов достаточно, просто руки не доходят.
Постараюсь не уходить так надолго.

Пока свежо в памяти, расскажу, что у нас приключилось совсем недавно (а точнее - позавчера).

Ничто не предвещало беды, когда port-channel из нескольких 10GE интерфейсов (между cat6500 и extreme x650) упал с сообщением

Jan 17 16:07:01.581 marmot: %PM-SP-4-ERR_DISABLE: channel-misconfig error detected on Po2, putting Po2 in err-disable state

при том, что последнее изменение конфигурации этого шеститонника было за три дня до этого. Потом (через полминуты) он поднимался по autorecover и через пару минут падал опять с тем же сообщением. Пересоздание этого port-channel ситуацию не изменило. В дебаге тоже ничего путного.

На поиск причин и методов устранения ушло около часа.
Как оказалось, один из клиентов начал слать странные bpdu, а поскольку он был включен в x650, на его порту bpdu не фильтровались, а проходили дальше на 6500. А 6500 при этом укладывал port-channel со столь странной диагностикой.

Открыл для себя команду "no spanning-tree etherchannel guard misconfig". Точнее, это sha90w мне её открыл (и заодно себе). Всем рекомендую.

Выводы:
1. STP - зло. Если его использование необходимо, BPDU должны ходить только в пределах собственной сети, и фильтроваться на всех клиентских портах в обе стороны (не лениться делать это через mac acl, где более простых способов нет). Хотя даже в этом случае нельзя быть полностью спокойным.
2. Реализация L2 в Cisco IOS мягко говоря странная.

Приведу ещё один пример, на этот раз гипотетической ситуации, демонстрирующей эти два вывода.
Допустим, мы купили L2-транспорт у стороннего оператора, q-in-q. И этот оператор (по нашей просьбе или по своей инициативе) прописал для нас туннелирование bpdu, "l2protocol-tunnel stp" на каталистах. Мы аккуратно прописали bpdufilter на клиентских портах и используем stp на этом линке.

И тут один из наших клиентов прислал нам туннелированный bpdu-пакет (а фактически, произвольный пакет на мультикастовый мак 01:00:0c:cd:cd:d0). Этот пакет прошёл наш bpdufilter, потому что это не bpdu, и ушёл в этот транспорт. Тамошний каталист, туннелирующий bpdu, обнаруживает уже туннелированный пакет. Вместо того, чтобы его дропнуть, он что-то не очень внятное сообщает в лог и закрывает порт по err-disable, хоть там 8*10GE и 1000 виланов. И не сообщает, в каком вилане ему пришёл вызвавший такую его реакцию пакет. И этот errdisable не отключается.

Фактически имеем примерно то же самое, что в реальном позавчерашнем случае: незащищённость от активности с клиентских портов, крайне скудная диагностика свича и сложность диагностировать проблему вручную, укладывание всего порта (в т.ч. port-channel) из-за одного неожиданного пакета по err-disable вместо того, чтобы просто дропнуть этот пакет, на cisco ios (другие вендоры за этим не замечены).

Как-нибудь при случае расскажу ещё о всяких интересных граблях на mstp (из-за чего мы сейчас используем только pv-stp).
gul

JunoScripts

Публиковать скрипт на 50 строчек, конечно, смешно, но учитывая, что это скрипт на SLAX, надеюсь, что не засмеёте. Потому что пользователей JunOS по моим представлением гораздо больше, чем тех, кто пишет скрипты. Ну и написание/отладка существенно сложнее, чем perl или bash (по крайней мере, для меня).

В общем, скрипт - выводит "show bgp sum" в несколько другом формате и с дополнительной информацией. Формат - по одной строке на каждый пир (после поднятия IPv6 обычный "show bgp sum" стал рисовать пиров в две строки, из-за чего не получалось использовать "| match ..."); кроме того, для каждого пира пишет его группу и description. Длина выводимых строк около 100, соответственно, желательно, чтобы у терминала тоже строки были длиннее 80 символов. Может, кому пригодится. Скрипт.

Скрипт надо положить в /var/db/scripts/op/ и в конфиге прописать "set system scripts op file show-bgp-sum.slax", после чего будет работать команда "op show-bgp-sum".

UPD:
ver 0.2 - Process groups inheritance, support route-instances (заменил первую версию на эту)
ver 0.2.1 - Show advertised prefix count - Cougar 20100513
ver 0.2.2 - Added local interface name
ver 0.3 - Get additional info by "show bgp group", not from config (based on 0.2.1)
ver 0.3.1 - Add local interface information

Если информация о локальных интерфейсах не нужна, версии 0.3.1 и 0.2.2 использовать смысла нет, лучше вместо них брать 0.3 или 0.2.1.
Версии 0.3 и 0.3.1 не требуют прав чтения конфигурации пользователем. Соответственно, корректно отрабатывают случаи использования commit-scripts. Но при этом не показывают информацию про route-instance (только bgp group).
Версии 0.2.1 и 0.2.2 работают чуть медленнее, чем 0.2, т.к. делают дополнительный запрос (get-bgp-neighbor).
Версия 0.3.1 работает несколько медленнее, чем 0.3 по той же причине.
Что быстрее - 0.2.x или 0.3.x - в разных случаях по-разному.

Выбирайте наиболее подходящий для вас вариант. :) Лично я у себя использую 0.2.2 с выброшенной оттуда работой с bgp instances (для ускорения, я их не использую).
gul

Это заговор

Человеку для определения чего-то естественно последовательно уточнять, а не наоборот. Город, улица, дом, квартира. Или час, минута, секунда. Или сотни, десятки, единицы. В общем, оно понятно.
При этом некоторые пишут/читают слева направо, некоторые справа налево, как у кого повелось, тут "интуитивно понятного" нет, это традиция, как есть страны с левосторонним и правосторонним движением. Арабы и евреи пишут справа налево, европейцы и американцы - слева направо.

Так вот. Почему интернетовские доменные имена имеют вид firma.kiev.ua, которые, чтобы было интуитивно понятное последовательное уточнение, нужно читать справа налево? Почему не ua.kiev.firma (как в иерархии конференций usenet, в фидошных эхах и во многих других местах)? Кто из авторов DNS был евреем или арабом? Ведь даже для резолвинга разбирать домен нужно последовательно справа налево (сначала ua, потом kiev.ua, потом firma.kiev.ua), что совершенно нелогично для английского языка.

Я уже молчу про интеловскую архитектуру с хранением чисел "левый байт самый младший" - такой записи нет ни у евреев, ни у арабов, насколько я знаю. И ведь каждый раз при приёме или отправке таких чисел в сеть нужно переставлять байты местами, а при получении - менять обратно, потому что в сети, благо, принят нормальный порядок (сначала старший байт, потом младший). В чём же фишка перевёрнутого порядка байт? Чтобы можно было записать четырёхбайтное число, а потом по тому же адресу прочитать двухбайтное, и, если число было небольшим, получить правильный результат? Как-то это несолидно выглядит в качестве аргумента.