Титла: NMAP интересен казус Публикувано от: victim70 в Aug 22, 2013, 00:06 На един отдалечен таен сървер имам SMTP анонимно за обслужване на едни устройства (postfix). Изведнъж устройствата извън мрежата спряха да си изпращат писмата, а в мрежата му продължават. Първото нещо което се сетих е да пусна един NMAP локално и от външна мрежа и резултатите са странни.
От външна мрежа Цитат dzver ~ # nmap име.на.сървера Локално на машината Цитат # nmap localhost Интересно е ако някой може да обясни несъответствието в портове 25/tcp filtered smtp - филтриран а аз не го филтра 135/tcp filtered msrpc - те такава услуга нема на сървера ?????? 139/tcp filtered netbios-ssn - те такава услуга също нема на сървера ?????? 8180/tcp open unknown - и такова нещо няма пуснато Някой има ли идея какво става? Титла: Re: NMAP интересен казус Публикувано от: gat3way в Aug 22, 2013, 00:41 Прилича на филтриране на този трафик от страна на доставчика. Специално 139, 135 и 445 доста често се филтрират, за да се ограничават разни гадости (така или иначе такъв трафик извън същият L2 сегмент рядко има особено легитимна причина). Що се отнася до smtp трафика, може би имат проблем с заразени уиндоуски машини, пращащи спам и затова са го резнали, предполагам временно.
Титла: Re: NMAP интересен казус Публикувано от: appmaster в Aug 22, 2013, 11:44 И на мен ми прилича на зомбиран/и компютър/и (с Windows), което е причинило проблем на мрежата и от там доставчика е пуснал филтрация заради бана, който е изял :D Думи нямам просто...
Айде сега иди се разправяй със съседите и доставчика >:D Титла: Re: NMAP интересен казус Публикувано от: Naka в Aug 22, 2013, 12:59 Доставчиците масово филтрират 25 порт на цели мрежи.
Предполагам е заради зомбирани win машини дето разпращат спам. Правилното решение би трябвало да е ако има филтрация по портове да я обявяват публично. Но ако някой поиска да му отворят порта веднага да го отворят без мрън-мрън. Обади се на съпорта, искай да ти отворят порта и в двете посоки. Ама гледай да говориш с някой админ от съпорта, а не с някоя офис кака. Ако не щат, ги заплаши с Комисията за защита на потребителите, че този доставчик не ти позволява да използваш e-mail, А това си е сериозно нещо. Как така доставчик ще ти спира ползването на e-mail. >:D И аз така бях. И след като набарахме един по-голям шеф и споменахме Комисията за защита на потребителите нещата се оправиха за 5 минути. В крайна сметка ако не се протестира ще си правят каквото си знаят. Титла: Re: NMAP интересен казус Публикувано от: kokoex в Aug 22, 2013, 14:16 А между SMTP сървъра ти и доставчика ти ти собствен рутер нямаш ли? Да не би там да ти е проблема?
И второ като позволяваш на външни машини да препращат през SMTP-то използуваш ли някакво удостоверяване? Иначе просто рано или късно ще влезеш в така наречените "черни списъци" за Open Relay и ще си имаш допълнителни главоболия. Титла: Re: NMAP интересен казус Публикувано от: Acho в Aug 22, 2013, 14:29 Виктим, а кой е там доставчика ?
Титла: Re: NMAP интересен казус Публикувано от: victim70 в Aug 22, 2013, 21:46 Виктим, а кой е там доставчика ?Собственика на сървера е доставчика. Ползва се за рутерите да информират по СМС когато се загуби сегмент. Между 2-те мрежи има няколко други доставчика, така че рутерите не са ми във владението. СМТП сървера не ползва автентикация само приема заявките от определени ИП адреси. За съжаление простите устройства не искат автентикация. Обясненията изглеждат логични. Не ми е ясно само ако филтрат SMTP-то защо от локалната мрежа с изпращането няма проблем? За сега не е в черните списъци понеже част от писмата се приемат на гугълски акаунт, които са от системата. Титла: Re: NMAP интересен казус Публикувано от: Acho в Aug 22, 2013, 21:56 Ако ти се играе колега, само една идейка. Добави SMTP да е на някой висок порт, примерно 8025. Аз така правя на моите мейл сървъри. Пускам да слуша едновременно на 25 и на 8025 портове.
И разни клиенти, които полват интернет от VivaCom home акаунти (с филтриран изходящ 25 tcp порт), им настройвам мейл-клиента да ползва за SMTP порт 8025. И всичко си минава и заминава. Поне за една проба, да се разбере това ли е причината за спирането. Или ако имаш SSH2 достъп до неизпращащите машини, направи един телнет до мейл-сървъра: telnet mail.server 25 и виж дали ще ти отговори SMTP-то. Титла: Re: NMAP интересен казус Публикувано от: victim70 в Aug 23, 2013, 00:16 Ако ти се играе колега, само една идейка. Добави SMTP да е на някой висок порт, примерно 8025. Аз така правя на моите мейл сървъри. Пускам да слуша едновременно на 25 и на 8025 портове. Дааа Разбира се че е изфилтрен порт 25 Като сменя порта няма проблем. Сега остава само един проблем. Възможен ли е следният запис в /etc/postfix/master.cf Цитат smtp inet n - - - - smtpd Целта е да слуша и на 2-та порта smtp-to. За да се рекунфигурира само част от устройствата edit: Проверих може и на 2-та порта да слуша утре ще тествам Титла: Re: NMAP интересен казус Публикувано от: gat3way в Aug 23, 2013, 08:41 Специално за рязането на smtp трафика не бих вземал толкова категорична позиция, преди доста години, докато работих на място където хоствахме уеб и мейл услуги, съм виждал какво става от клиентски уиндоуски машини, които ползват моя сървър в outlook-а, някои гадинки са написани изключително нагло и реално брутфорсват recipient-а на спама с максималната скорост, която могат, при което опашката на postfix-а за нула време се пълнеше брутално, страдаха други клиенти, дори само bounce-натите мейлове сами по себе си са проблем щото тъпчат файловата система. В най-лошите периоди не беше достатъчно да резна проблемните потребители да не могат да се автентицират пред сървъра, трябваше да филтрирам входящият трафик от цели мрежи. После бяха разправии по телефона с въпросните клиенти, които си били плащали и как съм можел да правя така. Ако доставчиците им вършеха тази работа, нямаше аз да се разправям като идиот.
Но пък при това положение трябва да се подходи по-селективно и "виновниците" да се уведомяват. Другото също е безотговорно. Титла: Re: NMAP интересен казус Публикувано от: Acho в Aug 23, 2013, 09:25 И аз бих бил много благодарен при забелязване на повишен изходящ трафик по 25 порт, от съпорта на някой доставчик да ми звъннат и да кажат:
"Колега, иди и ги погледни ето тия твоите клиенти. От снощи бълват здрав изходящ трафик от спамове или релейват чужд спам. Временно сме ги отрязали, но иди и виж какво става там. После пак да им възстановим изходящия 25 порт." Защото това се случва понякога, не е често, ама става. Никога нямаш 100% гаранция. Но това да ти се обадят и да те предупредят, е в идеалния скучай, никой от доставчика няма да си играе да те търси. РЪЦ, спират те и готово. И докато се усетят клиентите, че нищо не заминава навънка, то минал половиния ден. Титла: Re: NMAP интересен казус Публикувано от: kokoex в Aug 23, 2013, 14:37 Да споделя и моят опит :)
По принцип postfix-а се справя с флоода засега, но проблема ми е, че логовете му стават безобразно големи и /var се препълва а от там има и по-тежки последствия понякога. Стигъл съм до лог от 1 - 1,5 Gb за пет-шест часа. Какво направих - ами на рутера сложих една верига във филтрирането която брои и ако дадено IP примерно за 1 минута се опита да се върже повече от примерно 3 пъти - го дропи за период от 2 часа. След това го освобождава и ако се повтори - отново същата процедура. Имам и един списък от адреси които прескачат този контрол. Проверките ги пускам когато забележа че имам прекалено много отказани писма/конекции в логовете на postfix-а. Засега дава ефект. Разбира се ако ми остане време и успея да направя някакъв скрипт или нещо подобно за да може автоматично postfix-а да включва веригата ще е ОК, но за жалост абсолютно щастие няма :) Титла: Re: NMAP интересен казус Публикувано от: laskov в Aug 23, 2013, 23:43 Същото, което предлага Acho аз го правя така
Цитат iptables -t nat -A PREROUTING -p tcp --dport 1010 -j REDIRECT --to-port 25ПС Не съм сигурен, че има връзка, но имам и зареден модул conntrack |