madoff: Хорошо iopiop давайте по другому, что происходит когда появляется такая запись в логе.
possible SYN flooding on port 80. Sending cookies.
Как вы эту запись рассматриваете,что по вашему мнению происходит.
скорее всего переполнена очередь коннектов
---------- Добавлено 04.01.2012 в 00:01 ---------- Предыдущее сообщение было 03.01.2012 в 23:55 ----------
myhand: И?
и это все что вы можете сказать? а как же хваленое
Проблемы (свежие) гуглятся на раз. Показать как?
ведь все что я просил - покажите же! ну вот не смог я найти, не смог. помогите.
myhand: И кто его помнит? :)
ну вот я помню. да и не только я, бо мужик был толковый и исключительно плодовитый.
а это при чем вообще, помнит его кто-то или нет? как это связано с темой разговора? факт остается фактом - линус не самый легкий человек в общении. который, кстати, очень не любит признавать свои ошибки. посему я вполне допускаю и третий вариант причины этого предупреждения.
madoff: А что по вашему делает сервер, с хостом который является не живой,отправляет в шеколадный глазик ? , вы уже совсем что-ли мозги пропили.
вы, пожалуйста, выражайтесь определеннее. что значит "неживой"? который подсунул левый IP, что ли? ну если хост по этому IP не отвечает, то сервер шлет один раз пакетик SYN-ACK, ждет, шлет еще раз пакетик SYN-ACK, ждет, потом идет чистить очередь.
а в чем вопрос-то был?
---------- Добавлено в 23:29 ---------- Предыдущее сообщение было в 23:22 ----------
madoff: Начнём с того что вы влезли в разговор, с своим геморроем который себе же и нажили, мы же дали совет TC что у него нет атаки, нехрен руками лезть куда не следует. сечёшь разницу ?
я прошу прощения, но почему бы вам самим не посмотреть кто и куда влазил?
меня заинтересовало сообщение от вас
С радостью отвечу на один из ваших вопросов, tcp это гарантированный протокол доставки (RFC), любые срабатывание в виде "reset" приводят к нарушению доставки.
в какой момент случается RST и кто его генерирует?
myhand: "Допускать" можете что угодно. Познакомьтесь с матчастью по другим источникам (начиная с вики). Проблемы (свежие) гуглятся на раз. Показать как?
вот! покажите пожалуйста, это все что я прошу (вики читал, да).
myhand:
Скандалы! Интриги! Расследования!
Вы уж совсем разработчиков линукс за малолетних долбоебов не считайте.
хе-хе, упертость товарища линуса хорошо известна, достаточно вспомнить скандальный уход одного из коре-девелоперов, который считал (о ужас!) что линух на десктопе должен быть более отзывчивым и предлагал новый планировщик.
madoff: Вам пишут, что это приведёт к проблемам, чё не понятно ? включайте раз хотите, а я буду включать тогда когда надо его включать.
И почитайте историю этой функции, хватит тут поверхностно обсуждать.
в том-то и дело, что на одном заборе одно написано, а на другом - другое.
вот вы высказали мнение что син-куки ресеты шлет почем зря. вы можете подтвердить свое утверждение фактами какими-то? потому что я смотрю в алгоритм и не вижу где там RST может вылезти - просветите пожалуйста.
собственно, я не вижу подтверждения вообще по всем трем "пунктам обвинения"
1) грубо нарушает работу тсп - в чем? любая не син-куки имплементация тсп может выдать абсолютно такие же пакеты
2) деградирует производительность - прошу прощения, производительность уже деградировала, сайт под атакой
3) проблемы с смтп-релеем - тут загадка. это когда у меня на сервере релей стоит? или когда ко мне стучится релей? или когда сервер стучится к релею? 20 страниц гугла молчат... хотя вполне возможно что я плохо вопросы задаю гуглу.
а может что просто был какой-то смтп-сервер в 1996 году, в котором была бага не позволяющая работать с куками. теперь эту багу пофиксили (или сервер в лету канул), а предупреждение осталось. может такое быть? я допускаю что может.
а может быть просто изначально не разобрались в чем проблема была, а теперь стыдно признаться? может такое быть? я вот вполне допускаю, исходя из того что пишет автор син-куков.
Видимо, отсылка к штатной документации как обычно осталась втуне. Процитирую ее:
угу, как в 1996 году это написали, так оно там и висит. вот только почему-то никто не может объяснить, а в чем, собственно, заключается этот "violate". в аппроксимации MSS? в невозможности использовать большие окна? если сайт под атакой, если он просто дропает попытки соединения, буду ли я задумываться об оптимизации соединения? забавно, не так ли?
syncookies по умолчанию выставлены в ноль не потому что это хорошо или плохо, а потому что неизвестно как будет использоваться сервер. если сервер будет использоваться как стандартный веб-сервер, то включение кукисов не окажет никакого влияния на тсп, зато поможет при syn-флуде. а вот если сервер будет фтп или стримить - тогда надо выбирать, либо неоптимальная работа тсп (причем только во время атаки), либо syn-флуд (т.е. отказ в обслуживании). как по мне - пусть сервер хоть как-то, но работает, чем в даун уходит.
---------- Добавлено в 03:07 ---------- Предыдущее сообщение было в 03:04 ----------
madoff:
С радостью отвечу на один из ваших вопросов, tcp это гарантированный протокол доставки (RFC), любые срабатывание в виде "reset" приводят к нарушению доставки.
в алгоритм syn-cookies вообще не заложена отсылка RST
TheStig: На форуме стоит движок phpBB3, никак не могу избавиться от спама: пробовал все виды защиты (3 вида капчи, ставил логический вопрос (разумеется, не "какой год/введите число 12") ), но толку мало, каждый день кучу ботов. ничего не подскажите?
Добавьте не только в форму, но и в саму базу NOT NULL поле в таблицу юзверей чтобы в обход формы нельзя было регистрироваться
Хорошо iopiop давайте по другому, что происходит когда появляется такая запись в логе.
possible SYN flooding on port 80. Sending cookies.
Как вы эту запись рассматриваете,что по вашему мнению происходит.
скорее всего переполнена очередь коннектов
---------- Добавлено 04.01.2012 в 00:01 ---------- Предыдущее сообщение было 03.01.2012 в 23:55 ----------
И?
и это все что вы можете сказать? а как же хваленое
ведь все что я просил - покажите же! ну вот не смог я найти, не смог. помогите.
И кто его помнит? :)
ну вот я помню. да и не только я, бо мужик был толковый и исключительно плодовитый.
а это при чем вообще, помнит его кто-то или нет? как это связано с темой разговора? факт остается фактом - линус не самый легкий человек в общении. который, кстати, очень не любит признавать свои ошибки. посему я вполне допускаю и третий вариант причины этого предупреждения.
А что по вашему делает сервер, с хостом который является не живой,отправляет в шеколадный глазик ? , вы уже совсем что-ли мозги пропили.
вы, пожалуйста, выражайтесь определеннее. что значит "неживой"? который подсунул левый IP, что ли? ну если хост по этому IP не отвечает, то сервер шлет один раз пакетик SYN-ACK, ждет, шлет еще раз пакетик SYN-ACK, ждет, потом идет чистить очередь.
а в чем вопрос-то был?
---------- Добавлено в 23:29 ---------- Предыдущее сообщение было в 23:22 ----------
Начнём с того что вы влезли в разговор, с своим геморроем который себе же и нажили, мы же дали совет TC что у него нет атаки, нехрен руками лезть куда не следует. сечёшь разницу ?
я прошу прощения, но почему бы вам самим не посмотреть кто и куда влазил?
меня заинтересовало сообщение от вас
в какой момент случается RST и кто его генерирует?
"Допускать" можете что угодно. Познакомьтесь с матчастью по другим источникам (начиная с вики). Проблемы (свежие) гуглятся на раз. Показать как?
вот! покажите пожалуйста, это все что я прошу (вики читал, да).
Скандалы! Интриги! Расследования!
Вы уж совсем разработчиков линукс за малолетних долбоебов не считайте.
хе-хе, упертость товарища линуса хорошо известна, достаточно вспомнить скандальный уход одного из коре-девелоперов, который считал (о ужас!) что линух на десктопе должен быть более отзывчивым и предлагал новый планировщик.
Вам пишут, что это приведёт к проблемам, чё не понятно ? включайте раз хотите, а я буду включать тогда когда надо его включать.
И почитайте историю этой функции, хватит тут поверхностно обсуждать.
в том-то и дело, что на одном заборе одно написано, а на другом - другое.
вот вы высказали мнение что син-куки ресеты шлет почем зря. вы можете подтвердить свое утверждение фактами какими-то? потому что я смотрю в алгоритм и не вижу где там RST может вылезти - просветите пожалуйста.
собственно, я не вижу подтверждения вообще по всем трем "пунктам обвинения"
1) грубо нарушает работу тсп - в чем? любая не син-куки имплементация тсп может выдать абсолютно такие же пакеты
2) деградирует производительность - прошу прощения, производительность уже деградировала, сайт под атакой
3) проблемы с смтп-релеем - тут загадка. это когда у меня на сервере релей стоит? или когда ко мне стучится релей? или когда сервер стучится к релею? 20 страниц гугла молчат... хотя вполне возможно что я плохо вопросы задаю гуглу.
Может потому что ничего не изменилось?
может конечно.
а может что просто был какой-то смтп-сервер в 1996 году, в котором была бага не позволяющая работать с куками. теперь эту багу пофиксили (или сервер в лету канул), а предупреждение осталось. может такое быть? я допускаю что может.
а может быть просто изначально не разобрались в чем проблема была, а теперь стыдно признаться? может такое быть? я вот вполне допускаю, исходя из того что пишет автор син-куков.
хочется таки понять где собака порылась.
Видимо, отсылка к штатной документации как обычно осталась втуне. Процитирую ее:
угу, как в 1996 году это написали, так оно там и висит. вот только почему-то никто не может объяснить, а в чем, собственно, заключается этот "violate". в аппроксимации MSS? в невозможности использовать большие окна? если сайт под атакой, если он просто дропает попытки соединения, буду ли я задумываться об оптимизации соединения? забавно, не так ли?
а между тем син-куки добавляют в IPv6 ...
syncookies по умолчанию выставлены в ноль не потому что это хорошо или плохо, а потому что неизвестно как будет использоваться сервер. если сервер будет использоваться как стандартный веб-сервер, то включение кукисов не окажет никакого влияния на тсп, зато поможет при syn-флуде. а вот если сервер будет фтп или стримить - тогда надо выбирать, либо неоптимальная работа тсп (причем только во время атаки), либо syn-флуд (т.е. отказ в обслуживании). как по мне - пусть сервер хоть как-то, но работает, чем в даун уходит.
---------- Добавлено в 03:07 ---------- Предыдущее сообщение было в 03:04 ----------
С радостью отвечу на один из ваших вопросов, tcp это гарантированный протокол доставки (RFC), любые срабатывание в виде "reset" приводят к нарушению доставки.
в алгоритм syn-cookies вообще не заложена отсылка RST
На форуме стоит движок phpBB3, никак не могу избавиться от спама: пробовал все виды защиты (3 вида капчи, ставил логический вопрос (разумеется, не "какой год/введите число 12") ), но толку мало, каждый день кучу ботов.
ничего не подскажите?
Добавьте не только в форму, но и в саму базу NOT NULL поле в таблицу юзверей чтобы в обход формы нельзя было регистрироваться
И я так рьяно настаиваю на размещении потому лишь потому, что сайт мне нравится, из тучи того, что представлено на серче
Кстати напрасно, т.к. сайт будем палить как гуглу, так и яндексу, пока Илья не вернет долги.
Вор должен сидеть.
не получится если больше 2 неуникальных значений, edogs правильно написал последний вариант
вернее получится, но через вложенный селект
SELECT id, hach FROM tbl WHERE hash IN (SELECT hash FROM tbl GROUP BY hash HAVING COUNT(*) > 1);