MagMike

я не оператор, а лишь владелец AS. в октябре 2020 пришло офиц. письмо от ркн с требованием передать инфу в виде xml. заполнили, загрузили, сняли скриншоты. в феврале повторно присылают офиц-ое письмо - вы не предоставили. отвечаем, что сами вы дураки, вот скриншоты. 15 марта звонят из территориального ркн - почему на письмо от самого руководителя не отвечаете, мы вам на email выслали в феврале. при них лезу в логи почтовика - там даже намека нет на письма от них. "хорошо, значит повторим". в среду пришло письмо на электронку. ни электронной подписи, ни сопроводиловки на оф.бланке: нате вам приложение1, заполните, пришлите мне в ответ. вот еще новая инструкции по РАНР и настройке чебурнет-DNS. "Прошу продолжить работу" в приложении всякие данные просят сообщить, которые и к ПДн относятся, и доступ по snmp сообщить к бордерам. я такое письмо могу на коленке составить и представиться любым хреном с горы. насколько вообще это вписывается в их приказы? в 221 вроде как указано, что "8. Посредством личного кабинета на Сайте обеспечивается:" о взаимодействии посредством e-mail, без подтверждения ЭЦП, без офиц. писем - про это вроде нигде не сказано. Кто-то пытался уже посылать их с такими обращениями?

коллеги, вопрос к тем, у кого GGС установлен и кто уже выставлял счет raiden-у за размещение... выставили счет, скажем, на 1000$. они отправили платеж в 1000, о чем прислали письмо-уведомление. но на счет в банке пришло 985$. по swift-овке в поле details of charges (71А) указано SHA. т.е. плательщик оплачивает комиссию своего банка. а комиссии банков-посредников и банка-получателя, связанные с платежом, оплачивает получатель. изначально, ожидая перевода, мы заявили банку, что будет платеж на 1000, но сейчас, когда на счет пришло лишь 985,валютный отдел банка начал выносить нам мозг и грозит выставить штраф за пропавшие 15$. Есть подозрение, что это просто инициатива упертого сотрудника банка, и надо просто ткнуть его в нормативный документ, в котором расписано как поступать в таком случае. Были у кого-то прецеденты?

при использовании CLIPS DHCP, когда SE использует внешний dhcp-сервер, в radius-пакете с Acct-Status-Type="Start" отсутствует атрибут Assigned-IP-Address. Но он приходит в последующих пакетах Interim и Stop Проблема в том, что Interim-интервал может быть достаточно большим и радиус еще достаточно долго может не знать какой ip выдан на сессию. Но вроде как есть команда aaa accounting event dhcp которая, согласно документации: "Enables accounting messages to be sent whenever a DHCP lease is created or released" Т.е., как я понимаю, при создании или освобождении dhcp-лизы, SE должен посылать account-пакет на радиус-сервер(-ы). но у меня ничего не приходит. Эта команда будет работать, если SE использует внешний dhcp-сервер? в документации об этом не написано

есть подозрение, что крон запускает новое задание (скажем, в 10 минут), когда не закончилось выполнение предыдущего (запущенного, скажем, в 05 минут) php-скрипт реентерабелен?

2 экстрима объединенные в MLAG, смотрят на 2 таких же, тоже объединенных в MLAG. мультикастовые пакеты с выставленным CFI начинают ходить по кругу с одной пары на другую, образуя петлю. откуда они появляются - выясняем, но как бы то ни было - получается, что можно "кривым" пакетом положить сеть. Запрос передан в TAC экстрима, но пока с ним разберутся...

Есть Extreme Summit X460G2-48t-10G4 15.6.2.12 Надо зафильтровать пакеты ethertype 802.1q (0x8100) с уставленным битом CFI (5й бит в байте по смещению 14 ethernet-заголовка). согласно мануалу по ExtremeXOS в ACLах можно матчить только src, dst, vlan-id и ethertype. вопрос - как все-таки зафильтровать по ethertype + определенный бит?

Пытаюсь поднять защищенную bgp-сессию между cisco и quagga, добавив в описание нейбора neighbor Х.Х.Х.Х password 123 но сессия не поднимается. исходящий от quagga пакет содержит md5invalid 10:30:29.857716 IP (tos 0xc0, ttl 64, id 23422, offset 0, flags [DF], proto TCP (6), length 68) 192.168.0.151.45406 > 192.168.0.149.179: Flags [s], cksum 0x9fa6 (incorrect -> 0xe8c8), seq 351740525, win 29200, options [nop,nop,md5invalid,mss 1460,nop,wscale 9], length 0 при этом на cisco в логе появляется строка обратная ситуация - когда пакет идет с cisco в quagga: tcpdump показывает, что данные корректны ("cksum 0xb9a3 (correct)" и "md5valid") 10:30:12.923628 IP (tos 0xc0, ttl 255, id 26104, offset 0, flags [DF], proto TCP (6), length 64) 192.168.0.149.27775 > 192.168.0.151.179: Flags [s], cksum 0xb9a3 (correct), seq 3191805702, win 16384, options [mss 1460,md5valid,eol], length 0 но в логе линукса появляется строка Jan 15 10:30:12 kernel: [2109873.240975] TCP: MD5 Hash failed for (192.168.0.149, 27775)->(192.168.0.151, 179) пытался уже и отключать все оффлоады на сетевой карточке - не помогает rx-checksumming: off tx-checksumming: off scatter-gather: off tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: off generic-receive-offload: off large-receive-offload: off rx-vlan-offload: off tx-vlan-offload: off ntuple-filters: off receive-hashing: off Весь инет уже облазил. гуглёж не помогает. Есть какие-то идеи? Заранее спасибо! информация о системе: bgpd version 0.99.23.1 Linux 3.14.17 $ gunzip < /proc/config.gz | grep MD5 CONFIG_TCP_MD5SIG=y CONFIG_SCTP_DEFAULT_COOKIE_HMAC_MD5=y CONFIG_SCTP_COOKIE_HMAC_MD5=y CONFIG_CRYPTO_MD5=y

Уже закончилось ;) твиттер на попытку открыть страницу эккаунта mksenzov [https://twitter.com/mksenzov] выдает: "К сожалению, такой страницы нет!"

как это выглядит? в логах что-то пишется?

А может кто подскажет по опыту - есть ли какие-то тонкости в тюнинге системы, имеющей большое кол-во ppp-интерфейсов? кроме самого увеличения интерфейсов вырастают косвенные затраты - например, время выполнения программ типа ip, tc, которые при большом количестве интерфейсов "мешают" друг другу блокировками. сейчас имеем около 3500 pppoe-сессий на одном Xeon E5-2620. при этом в сторону пользователей идет около 220 kpps, поток - менее 2,5 Гб/с

Сегодня, 09.04.14 в 9:33 MSK наблюдал резкое увеличение исходящего трафика. пик пришелся примерно на 9:37, после чего пошел на спад и около 9-43 поток пришел в норму. зеленый график. тут время MSK+2, т.е. в 11-33 К сожалению, всплеск увидел только только через 2 часа, поэтому не смог отследить природу происхождения. на MSK-IX этот момент тоже отразился: Интересно, что это было... Может кому-то удалось зафиксировать это событие в реальном времени или есть возможность увидеть в нетфлоу?

Eсли кому интересно, вот как это выглядит со стороны abuse-сервиса провайдера. письмо от abusereports(a)gameservers.com Recently, we have detected a DDOS attack from X.Y.Z.191:53. Based on the source port number, this likely indicates an open DNS resolver on your network. Open resolvers are very commonly abused to conduct DDOS attacks. Please see http://openresolverproject.org/ or http://www.team-cymru.org/Services/Resolvers/ for more information. We would ask that you either limit access to this resolver to prevent it from being abused, or implement one of the patches described on http://openresolverproject.org/ or http://www.team-cymru.org/Services/Resolvers/instructions.html . If you are not sure how to do this, we have some instructions available at http://abusereports.gameservers.com/#dns You can confirm this host is vulnerable by running the following command: dig example.com @X.Y.Z.191 If you see a valid response, this is proof that the machine is vulnerable and actively being used to conduct DDOS attacks. Please note that it's possible this machine has rate limits to help prevent abuse. We're unable to confirm if that's the case, but we can tell you with certainty this machine has been involved in an attack against us. Our detection systems automatically merge duplicate log entries, however we have the following records: [2014-01-03 04:39:22 GMT] IP X.Y.Z.191:53 > 68.232.171.217:49765 UDP, length 16687104, packets 4096 [2014-01-03 04:39:50 GMT] IP X.Y.Z.191:53 > 68.232.171.217:57669 UDP, length 16687104, packets 4096 [2014-01-03 04:43:14 GMT] IP X.Y.Z.191:53 > 68.232.171.217:13753 UDP, length 16687104, packets 4096 [2014-01-03 04:44:52 GMT] IP X.Y.Z.191:53 > 68.232.171.217:8915 UDP, length 16687104, packets 4096 [2014-01-03 04:47:15 GMT] IP X.Y.Z.191:53 > 68.232.171.217:14126 UDP, length 16687104, packets 4096 [2014-01-03 05:23:19 GMT] IP X.Y.Z.191:53 > 68.232.171.217:15168 UDP, length 16687104, packets 4096 [2014-01-03 05:24:22 GMT] IP X.Y.Z.191:53 > 68.232.171.217:11805 UDP, length 16687104, packets 4096 [2014-01-03 05:25:41 GMT] IP X.Y.Z.191:53 > 68.232.171.217:5844 UDP, length 16687104, packets 4096 [2014-01-03 05:25:42 GMT] IP X.Y.Z.191:53 > 68.232.171.217:11655 UDP, length 16687104, packets 4096 [2014-01-03 05:26:27 GMT] IP X.Y.Z.191:53 > 68.232.171.217:10339 UDP, length 16687104, packets 4096 [2014-01-03 05:27:29 GMT] IP X.Y.Z.191:53 > 68.232.171.217:62734 UDP, length 16687104, packets 4096 [2014-01-03 05:27:41 GMT] IP X.Y.Z.191:53 > 68.232.171.217:5206 UDP, length 16687104, packets 4096 If you have any questions about this report, please let us know: abusereports@gameservers.com ========================================= The recipient address of this report was provided by the Abuse Contact DB by abusix.com. abusix.com does not maintain the content of the database. All information which we pass out, derives from the RIR databases and is processed for ease of use. If you want to change or report non working abuse contacts please contact the appropriate RIR. If you have any further question, contact abusix.com directly via email (info@abusix.com). Information about the Abuse Contact Database can be found here: https://abusix.com/global-reporting/abuse-contact-db abusix.com is neither responsible nor liable for the content or accuracy of this message. получил около десятка жалоб на своих пользователей. просканировав их, обнаружил, что у всех - микротики. просканировал других пользователей. выцепил 20 микротиков и только у двух был закрыт dns. Намечается плохая тенденция - микротики ставятся или кухарками, или руко>|<опыми админами. IMHO, надо пинать вендора.

1. C7606 и С6509. показания датчика температуры на входе (INLET) и на выходе (OUTLET). INLET - можно считать, температура в серверной рядом с "холодной" стороной оборудования. 2. UPS-ы APC (RT 6000 RM XL). Имеет датчик температуры батарей. тоже вполне близок к температуре воздуха. Плюс с одним из UPSов шел родной выносной датчик. Я его разместил в области крышки стойки - в районе 2 м над полом. там температура примерно на 5 градусов выше, чем температура батарей. Для контроля проблем с кондиционированием вполне хватает - в случае проблем температура за 30 минут вырастает с обычных 22 градусов до 30. тут-то заббикс и начинает бить тревогу.

на msk-ix, кстати, этот всплеск виден: http://www.msk-ix.ru/network/traffic.html

Апну тему. сегодня в 12:12 MSK опять наблюдался резкий всплеск загрузки внешних каналов. Вначале решил, что это все кинулись смотреть прямую линию с солнцеликим, но: 1. загрузка коснулась как входящего, так и исходящего канала с примерно одинаковой интенсивностью. 2. через 5 минут загрузка упала. исходящий от пользователей трафик преобладал. Трафик был похож на p2p.