[ТЕМА ЗАКРЫТА]
18.03.2009 12:33
twix
 
Цитата:
OlegON Ошибаешься, пакеты ходят и без установленного соединения. Именно в этом преимущество фильтров по пакетам, а не по соединениям.
а куда пытаются идти эти пакеты, если принимающая сторона их не ждет?
18.03.2009 13:11
OlegON
 
Цитата:
twix а куда пытаются идти эти пакеты, если принимающая сторона их не ждет?
Куда послали, туда и идут :) На низком уровне можно слать отдельные пакеты, не привязываясь к ограничениям вроде "соединение". Это не вилка с розеткой и проводом...
18.03.2009 13:15
twix
 
Цитата:
OlegON Куда послали, туда и идут :) На низком уровне можно слать отдельные пакеты, не привязываясь к ограничениям вроде "соединение". Это не вилка с розеткой и проводом...
ахха... берем в руки журнал ХАКЕР за 20хх год, и читаем все про сетевые атаки...
но, опять же, возвращаясь к проблеме скана портов от хостера:
если клиент не иницировал соединение, т.е. он и не ждет ничего и нигде, то нафига сервер ему пытается что-то отдать? О_о
да, и вообще, что за игры с их стороны с расстрелом клиентов?
опять же скажу, что ответ "сервер пытается что-то отдать" меня не устроил. он должен был отдавать туда, куда положено, а не куда бог пошлет
18.03.2009 13:28
OlegON
 
Блин, простой вариант. Закрываешь у себя верхние порты на входящие пакеты, но разрешаешь их в клиенте (проксе). Прокся говорит "дай" и выходит наружу по портам, фаер говорит "низзя" и вход обратно закрывает.
18.03.2009 13:36
twix
 
Цитата:
OlegON Блин, простой вариант. Закрываешь у себя верхние порты на входящие пакеты, но разрешаешь их в клиенте (проксе). Прокся говорит "дай" и выходит наружу по портам, фаер говорит "низзя" и вход обратно закрывает.
это не подходящий для данного случая пример.
вот, как оно выглядит на самом деле:
клиент за шлюзом просит соединения к olegon.ru:80
iptables на шлюзе шлет его на <шлюз>:3128
squid обращается к olegon.ru:80 с произвольного свободного порта
на этот порт он и получает ответ и все возможные и невозможные данные
-- здесь надо учесть, что iptables входящие пакеты не режет, так как соединение устанавливалось от локальной машины, которой выход разрешен с любого порта, и пакеты, ходящие внутрь по уже установленному соединению не режутся
squid отдает полученные данные с порта 3128 клиенту, который их просил

непонятной остается одна вещь - зачем сервер пытается пинать другие порты?
18.03.2009 14:00
OlegON
 
А теперь в свой рассказ добавь все таки "входящие пакеты на высокие порты блокируются". То, что сервер выходит остается незамеченным, ибо наружу ему все открыто. А когда идем внутрь по тому, что уже открыто, получаем по шапке. Речь идет о неправильной конфигурации.
18.03.2009 14:12
twix
 
Цитата:
OlegON А теперь в свой рассказ добавь все таки "входящие пакеты на высокие порты блокируются". То, что сервер выходит остается незамеченным, ибо наружу ему все открыто. А когда идем внутрь по тому, что уже открыто, получаем по шапке. Речь идет о неправильной конфигурации.
*200
так ты меня и не понимаешь...
1. сейчас нас твой хостер не бомбит... в прошлом это уже
2. по шапке на входе по установленным соединениям никто не получает - с этим все в порядке, и проблем не возникает. занусси
18.03.2009 14:19
OlegON
 
А я и не говорил о том, что у тебя проблемы :) Я говорил, что ты неточно понимаешь суть возможной проблемы, почему она может возникнуть :)
18.03.2009 14:22
twix
 
Цитата:
OlegON А я и не говорил о том, что у тебя проблемы :) Я говорил, что ты неточно понимаешь суть возможной проблемы, почему она может возникнуть :)
эта проблема уже совсем выходит за рамки данного топика.
однако, с настройками проблем не возникло (%

как меня убеждает Dim, ты пытаешься сказать мне, что сервер отдавал запрошенные данные не на те порты, на которых их ждал клиент. но это, имхо, не есть правильно. к тому же, попытка "отдать данные", когда их никто не просил, попутно перебирая номера портов, и есть скан. а никак не кривая настройка фаера
18.03.2009 14:31
twix
 
короче, в попытках померяться п..ьками забыли про суть проблемы.
а она вот в чем:
зачем хостер слал пакеты на рандомные закрытые порты, когда к его серверу никто ни за чем не обращался?
и дело тут совсем не в том, что фаер выкручен на параноидальный режим, как у нас есть сейчас, а в том, что хостер не признает существования, хоть и в прошлом, проблемы, вместо этого отвечая невнятным "сервер отдавал данные".
18.03.2009 15:28
OlegON
 
Я же подчеркиваю, что возможна ошибка настройки фаера. В эту пользу говорит то, что кое-кто до сих пор жалуется на скан.
18.03.2009 15:32
twix
 
Цитата:
OlegON Я же подчеркиваю, что возможна ошибка настройки фаера. В эту пользу говорит то, что кое-кто до сих пор жалуется на скан.
в два ночи в офисе, как правило, никого нет. кому сервер пытался отдавать какие-то данные в это время?
18.03.2009 16:09
OlegON
 
Извини, хрустальный шар дома забыл ;)
18.03.2009 16:11
twix
 
Цитата:
OlegON Извини, хрустальный шар дома забыл ;)
вот-вот. на этот вопрос смог бы ответить только хостер. собственно, он, вроде как, отмазался
18.03.2009 16:22
OlegON
 
Нет, на этот вопрос мог бы ответить тот, чей фаер ругался :)
18.03.2009 16:26
twix
 
Цитата:
OlegON Нет, на этот вопрос мог бы ответить тот, чей фаер ругался :)
Олег, я понимаю, что ты уверен в своем хостере, и в кривизне рук клиентов, но спор это ни к чему не приведет.
я лишь констатирую факт: раньше скан портов от хостера был. сейчас его нет. и дело не в кривизне рук или в смене фаера, а в том, что хостер испытывал проблемы с безопасностью, но признаваться в этом не хочет
имхо, в любом случае каждый останется при своем мнении
18.03.2009 18:32
deucel
 
Цитата:
twix сервер отдавал запрошенные данные не на те порты, на которых их ждал клиент. но это, имхо, не есть правильно.
Не совсем правильная формулировка, их фаервол не пропустил по своим правилам. Например FTP соединение в активном и пассивном режиме.
С активным все понятно, а в пассивном мы не знаем по какому порту будет соединение.
Для этого есть:

Цитата:
Состояние ESTABLISHED говорит о том, что это не первый пакет в соединении. Схема установки состояния ESTABLISHED достаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние ESTABLISHED необходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения NEW или RELATEDбудет изаменено на ESTABLISHED.
Цитата:
Строя свой набор правил, вы можете позволить покидать локальную сеть пакетам со статусом NEW и ESTABLISHED, а во входящем трафике пропускать пакеты только со статусом ESTABLISHED и все будет работать прекрасно. И наоборот, если бы трассировщик продолжал считать соединение как NEW, то фактически вам никогда не удалось бы установить соединение с "внешним миром", либо пришлось бы позволить прохождение NEW пакетов в локальную сеть.
18.03.2009 20:06
twix
 
Цитата:
deucel Не совсем правильная формулировка, их фаервол не пропустил по своим правилам. Например FTP соединение в активном и пассивном режиме.
С активным все понятно, а в пассивном мы не знаем по какому порту будет соединение.
неправда! как раз-таки знаем! если фтп-сервер стоит у нас, то в пассивном режиме он принимает соединения не только на 21-й порт, который по RFC ему и принадлежит, но и еще на нескольких, заданным администратором системы, находящимся выже "зоны" в 1024 системных порта. следовательно, при настройке фаера мы знаем, куда будет цепляться клиент в пассивном режиме.
а вот в активном режиме клиент из-за огненной стены подключиться не сможет, потому что в этом случае фаер будет блокировать соединения от сервера
Цитата:
Для этого есть:
это понятно и без русскоязычных мануалов (%
вопрос о существующих и создаваемых соединениях здесь обсуждался. сорри, если где-то непонятно изложился
19.03.2009 09:05
deucel
 
Цитата:
twix то в пассивном режиме он принимает соединения не только на 21-й порт, который по RFC ему и принадлежит
Опять ты не прав,
Цитата:
Протокол FTP относится к протоколам прикладного уровня и для передачи данных использует транспортный протокол TCP. Команды и данные, в отличие от большинства других протоколов передаются по разным портам. Порт 20 используется для передачи данных, порт 21 для передачи команд.

Цитата:
cat /etc/services
ftp-data 20/tcp # File Transfer [Default Data]
ftp-data 20/udp # File Transfer [Default Data]
ftp 21/tcp # File Transfer [Control]
fsp 21/udp # File Transfer [Control]
в пассивном любой непривилегированный инициализированный сервером в диапазоне 1024 - ~65000 или указанные в настройках для передачи данных, причем в пределах одного сеанса для передачи-получения нескольких файлов могут использоваться разные порты. Вот для этого и используется ESTABLISHED в iptables, чтоб фаервол не срезал соединение на других портах.
:p


Цитата:
8. CONNECTION ESTABLISHMENT

The FTP control connection is established via TCP between the user process port U and the server process port L. This protocol is assigned the service port 21 (25 octal), that is L=21.

RFC 959 October 1985
19.03.2009 09:38
twix
 
Цитата:
deucel Опять ты не прав,



в пассивном любой непривилегированный инициализированный сервером в диапазоне 1024 - ~65000 или указанные в настройках для передачи данных, причем в пределах одного сеанса для передачи-получения нескольких файлов могут использоваться разные порты. Вот для этого и используется ESTABLISHED в iptables, чтоб фаервол не срезал соединение на других портах.
:p
*200
в каждом посте одно и то же разными словами.
ну какая разница, на какие порты настроен ФТП для работы в пассивном режиме, если вопрос стоял: за каким чёртом сервер olegon.ru ломился на различные порты клиентских машин посетителей ресурса? даже тогда, когда к нему никто не обращался и не мог обращаться. ё-маё.
и дело тут не в том, что какой-то фаер был криво настроен. если бы сервер пытался отдать полезную инфу, но натыкался бы на дропы, то и клиент не получал бы никакой информации... логично? но клиент нормально обозревал ресурс. а вот что за соединения пытался установить сервер (или, если хотите, какие пакеты он слал) даже в то время, как клиент спокойненько спал дома, непонятно.

спасибо за информацию, кстати, но маны, факи и записи в блогах и вики можно почитать и так. (;
19.03.2009 10:10
deucel
 
Мои ответы были на
Цитата:
Сообщение от twix
сервер отдавал запрошенные данные не на те порты, на которых их ждал клиент. но это, имхо, не есть правильно.
соотв. если сервер действительно отдавал, значит кто то просил.
Из этого два варианта: неправильно настроен фаервол или фаервол отработал правильно, просто клиент не должен был получить данные (например потоковые типа интернет радио).

Цитата:
twix вопрос стоял: за каким чёртом сервер olegon.ru ломился на различные порты клиентских машин посетителей ресурса?
на это тоже был нормальный ответ
Цитата:
Сообщение от OlegON
Нет, на этот вопрос мог бы ответить тот, чей фаер ругался
для этого достаточно было посмотреть по каким портам были попытки соединения и сделать выводы. Может это были попытки проверки хоста при отправке почты сервером и т.п.
При постоянном соединении бывает провайдеры сканят клиентов для определения живости соединения.
19.03.2009 10:21
twix
 
*43
Цитата:
deucel Мои ответы были на
соотв. если сервер действительно отдавал, значит кто то просил.
Из этого два варианта: неправильно настроен фаервол или фаервол отработал правильно, просто клиент не должен был получить данные (например потоковые типа интернет радио).
т.е. получается, что фаер отругался, но данные клиенту отдал?
Цитата:
на это тоже был нормальный ответ
не было
Цитата:
для этого достаточно было посмотреть по каким портам были попытки соединения и сделать выводы. Может это были попытки проверки хоста при отправке почты сервером и т.п.
При постоянном соединении бывает провайдеры сканят клиентов для определения живости соединения.
какое соединение может быть живым в два часа ночи, когда почти все компы выключены, никого нет, и никто инетом не пользуется?
это явно была не проверка соединения по нескольким портам. живость хоста, кстати, можно проверить и простым ICMP пакетом, который тревогу поднимать не будет, если об этом не попросить. в данном же случае посылались TCP-пакеты на широкий диапазон портов с методичным перебором.

кто-нибудь вообще тему читал?
скан шел именно с данного сервера, т.е. OLEGON.RU. с остальными проблем не было.

[offtop] я не могу понять, почему все здесь пытаются выгородить хостера, который явно был подвержен каком-то заражению, либо был использован во всех смыслах из-за какой-то уязвимости? почему речь упорно ведется о каких-то вещах, мало относящихся к поднятому вопросу? почему все ссылаются на кривую настройку, пусть и попсового, фаера, когда он был настроен весьма грамотно, и адекватно реагировал на действия серверов и клиентов? почему нить разговора постоянно уходит в сторону, вместо того, чтобы целить именно в корень проблемы?
честно слово, руки опускаются... но ответ здесь так и не был озвучен.
19.03.2009 10:27
OlegON
 
Мне, например, пофик, что там хостер говорит. Я зацепился за твое непонимание сути происходящего :) Ты однозначно утверждаешь, что виноват хостер. Мы тебе говорим, что однозначностью здесь и не пахнет и твой вариант как раз менее вероятен.
19.03.2009 10:30
twix
 
Цитата:
OlegON Мне, например, пофик, что там хостер говорит. Я зацепился за твое непонимание сути происходящего :) Ты однозначно утверждаешь, что виноват хостер. Мы тебе говорим, что однозначностью здесь и не пахнет и твой вариант как раз менее вероятен.
вот об этом я и говорю. устал я уже с вами спорить... )8
если есть уверенность, что на том же сервере хостятся максимально защищенные сайты, не использующие доступные бесплатные CMS, и у хостера тоже все настроено максимально эффективно и безопасно, тогда вообще непонятно, что это было:
https://olegon.ru/showpost.php?p=34374&postcount=11
19.03.2009 11:43
deucel
 
Цитата:
twix устал я уже с вами спорить... )8
https://olegon.ru/showpost.php?p=34374&postcount=11
Да, пора заканчивать.
Для размышлений поищи по форумам, например




Цитата:
Это у тебя сервис какой нить пытае(простите за глупость)(простите за глупость)(простите за глупость) достуча(простите за глупость)(простите за глупость)(простите за глупость), а керио перекрывает порты, посмотри на этой клиентской машине че за проги стоят. У меня такое было при установке баз по законодательству и при попытке их обновления. Решалось все открытием для этой базы 2 портов.
Цитата:
Обычно керио так ругае(простите за глупость)(простите за глупость)(простите за глупость) при некоторых неудачных попытках подгрузить баннер при просмотре сайтов с большим количеством баннеров
и необязательно большим И ещё это связано с немного криво настроенным правилом блокирования БАННЕРОВ!
Цитата:
Еще так бывает если кто-нить из локалки что-нить качает из инета (особенно в много потоков (ReGet и пр.))... куски которые уже скачаны продолжают "досыпаться" из инета, а Керио их уже получил, и клиенту отдал. А тут "приход".
Так что пугаться не стоит, надо смотреть какие порты сканятся. Атака обычно ведется не по случайным портам, а по потенциально "уязвимым" - это до 1024 и "троянские" всякие.
Я за ЗДОРОВУЮ паранойю
и т.п.


Опции темы


Часовой пояс GMT +3, время: 01:35.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.