On Thu, Dec 13, 2007 at 02:25:21AM -0500, Daniel Ouellet wrote:
Otto Moerbeek wrote:
I'm only talking about the tear-down. The three-way handshake happens
before that, both sockets are in ESTABSLIHED state. You have to read
half-close as a verb (action), and half-open as a description of the
On 2007/12/13 09:09, Otto Moerbeek wrote:
It's depening on the application if sockets staying in CLOSE_WAIT are
a problem or not: it might be intentional (in the hulp duplex case),
or it might be a program forgetting to do a close.
Does select() notify the application of FIN from the other
Hi!
On Thu, Dec 13, 2007 at 11:10:51AM +, Stuart Henderson wrote:
On 2007/12/13 09:09, Otto Moerbeek wrote:
It's depening on the application if sockets staying in CLOSE_WAIT are
a problem or not: it might be intentional (in the hulp duplex case),
or it might be a program forgetting to do a
On Thu, Dec 13, 2007 at 11:10:51AM +, Stuart Henderson wrote:
On 2007/12/13 09:09, Otto Moerbeek wrote:
It's depening on the application if sockets staying in CLOSE_WAIT are
a problem or not: it might be intentional (in the hulp duplex case),
Strange typo by me... that's a Dutch word,
On Thu, Dec 13, 2007 at 12:35:03PM +0100, Otto Moerbeek wrote:
On Thu, Dec 13, 2007 at 11:10:51AM +, Stuart Henderson wrote:
On 2007/12/13 09:09, Otto Moerbeek wrote:
It's depening on the application if sockets staying in CLOSE_WAIT are
a problem or not: it might be intentional (in
On Thu, Dec 13, 2007 at 12:35:03PM +0100, Otto Moerbeek wrote:
:
or it might be a program forgetting to do a close.
Does select() notify the application of FIN from the other side?
If not, that would explain things, it wouldn't be reasonable for
httpd to manually try and receive
I have to correct myself a bit: the socket is in CLOSE_WAIT after
receiving the clients FIN (and acknowledging it). The server hasn't
yet sent its FIN, so the connection is properly half closed, the server
_could_ send some data down the line as its part of the connection
is still up. Translation:
On Wed, Dec 12, 2007 at 10:11:05AM +0100, knitti wrote:
I have to correct myself a bit: the socket is in CLOSE_WAIT after
receiving the clients FIN (and acknowledging it). The server hasn't
yet sent its FIN, so the connection is properly half closed, the server
_could_ send some data down the
On 12/12/07, Raimo Niskanen [EMAIL PROTECTED] wrote:
* A httpd server socket enters CLOSE_WAIT when the client
closes (or half-closes) its end and sends FIN to the
server TCP stack that replies ACK and enters CLOSE_WAIT.
The socket proceeds out of CLOSE_WAIT when httpd calls
close()
Raimo Niskanen wrote:
Interesting for me too, and most probably for others. It became an
interesting discussion of my CLOSE_WAIT problem after all...
To summarize (as I see it):
* pf synproxy state does not affect these CLOSE_WAIT sockets since
the SYN proxy is only active during connection
knitti wrote:
The problem would be to forget calling ap_bclose() after ending a
connection, either because all data has been sent or the connection has
been aborted. What I can read with some confidence, is that keeping a
socket open beyond sending any data is not intentional, and there is
Subject: Re: rouge IPs / user
See, that requires trusting the other 'security experts' are actually
being honest and working for each others benefit... but that system
isn't secure, how do you distinguish 'security expert' from
'infiltrator'?
You *must* have decentralized systems/methods
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
Raimo Niskanen wrote:
Interesting for me too, and most probably for others. It became an
interesting discussion of my CLOSE_WAIT problem after all...
To summarize (as I see it):
* pf synproxy state does not affect these CLOSE_WAIT
knitti wrote:
* pf synproxy state does not affect these CLOSE_WAIT sockets since
the SYN proxy is only active during connection establishement.
But it is a good to use anyway since it prevents IP spoofing.
Why not? Just test it out. What happen if you get a DDoS on your httpd
as an example,
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
I am only
saying that using PF in front of httpd will reduce the possible number
of httpd close_wait you might see. By default httpd can only support up
to 256 connections, unless you increase it and compile it again.
I don't understand why
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
knitti wrote:
The problem would be to forget calling ap_bclose() after ending a
connection, either because all data has been sent or the connection has
been aborted. What I can read with some confidence, is that keeping a
socket open
knitti wrote:
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
I am only
saying that using PF in front of httpd will reduce the possible number
of httpd close_wait you might see. By default httpd can only support up
to 256 connections, unless you increase it and compile it again.
I don't
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
net.inet.tcp.keepidle
net.inet.tcp.keepinittime
net.inet.tcp.keepintvl
net.inet.tcp.rstppslimit
net.inet.tcp.synbucketlimit
net.inet.tcp.syncachelimit
nope, shoudn't apply, unless my TCP knowledge is wrong or there
is a bug, which makes
On Wed, Dec 12, 2007 at 10:42:23PM +0100, knitti wrote:
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
net.inet.tcp.keepidle
net.inet.tcp.keepinittime
net.inet.tcp.keepintvl
net.inet.tcp.rstppslimit
net.inet.tcp.synbucketlimit
net.inet.tcp.syncachelimit
nope, shoudn't apply,
Otto Moerbeek wrote:
I did not follow the complete thread, but I like to mention one thing:
there might be half open connections involved here.
A client might do a half close (i.e. shutdown(SHUT_WR)) after sending
a request. This will make the connection a half-duplex one. iirc, after the
knitti wrote:
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
net.inet.tcp.keepidle
net.inet.tcp.keepinittime
net.inet.tcp.keepintvl
net.inet.tcp.rstppslimit
net.inet.tcp.synbucketlimit
net.inet.tcp.syncachelimit
nope, shoudn't apply, unless my TCP knowledge is wrong or there
is a bug,
knitti wrote:
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
knitti wrote:
The problem would be to forget calling ap_bclose() after ending a
connection, either because all data has been sent or the connection has
been aborted. What I can read with some confidence, is that keeping a
knitti wrote:
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
I am only
saying that using PF in front of httpd will reduce the possible number
of httpd close_wait you might see. By default httpd can only support up
to 256 connections, unless you increase it and compile it again.
I don't
On Wed, Dec 12, 2007 at 08:57:18PM -0500, Daniel Ouellet wrote:
Otto Moerbeek wrote:
I did not follow the complete thread, but I like to mention one thing:
there might be half open connections involved here. A client might do a
half close (i.e. shutdown(SHUT_WR)) after sending
a request.
Otto Moerbeek wrote:
I'm only talking about the tear-down. The three-way handshake happens
before that, both sockets are in ESTABSLIHED state. You have to read
half-close as a verb (action), and half-open as a description of the
state of the connection.
Check the state transition diagram, and
On Tue, Dec 11, 2007 at 01:15:11AM +1300, Joel Wiramu Pauling wrote:
Tip.
Don't allow password challenge. Problem solved. Just use key'd ssh and this
problem disappears.
Bin there, done that.
You answered the wrong question.
I want to know if and what I can do (on the server side) about
On 12/11/07, Raimo Niskanen [EMAIL PROTECTED] wrote:
I want to know if and what I can do (on the server side) about HTTP
clients that put sockets on my httpd server in state CLOSE_WAIT and
thereby chew up all sockets for the server causing a kind of
denial of service state.
And yes, I have
Yep, synproxy in your answer for OpenBSD. For linux or freebsd, try
enabling syn cookies.
On Dec 11, 2007 5:43 AM, knitti [EMAIL PROTECTED] wrote:
On 12/11/07, Raimo Niskanen [EMAIL PROTECTED] wrote:
I want to know if and what I can do (on the server side) about HTTP
clients that put sockets
Raimo Niskanen wrote:
On Tue, Dec 11, 2007 at 01:15:11AM +1300, Joel Wiramu Pauling wrote:
Tip.
Don't allow password challenge. Problem solved. Just use key'd ssh and this
problem disappears.
Bin there, done that.
You answered the wrong question.
I think you got the right answer many
On 2007/12/11 09:40, Marti Martinez wrote:
Yep, synproxy in your answer for OpenBSD. For linux or freebsd, try
enabling syn cookies.
synproxy works at the start of the connection, not the end.
CLOSE_WAIT is the state where the network stack waits for
the application (httpd) to close the
On 12/11/07, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2007/12/11 09:40, Marti Martinez wrote:
Yep, synproxy in your answer for OpenBSD. For linux or freebsd, try
enabling syn cookies.
synproxy works at the start of the connection, not the end.
CLOSE_WAIT is the state where the network
knitti wrote:
On 12/11/07, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2007/12/11 09:40, Marti Martinez wrote:
Yep, synproxy in your answer for OpenBSD. For linux or freebsd, try
enabling syn cookies.
synproxy works at the start of the connection, not the end.
CLOSE_WAIT is the state where
On 12/11/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
[... snipped away a lot ...]
There is a lots that can be done, however, when you reach this level, an
answer doesn't fit all and is really dependent on your setup.
Hope this help answering your question.
It's not me having the problem, but
knitti wrote:
On 12/11/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
[... snipped away a lot ...]
There is a lots that can be done, however, when you reach this level, an
answer doesn't fit all and is really dependent on your setup.
Hope this help answering your question.
It's not me having
On 12/12/07, Daniel Ouellet [EMAIL PROTECTED] wrote:
knitti wrote:
HTTP keep alives have nothing to do with it. If the socket is in
CLOSE_WAIT, the TCP connection can't be reused, the server
has sent its FIN and the client its FIN/ACK, but the server doesn't
have yet sent its final ACK.
knitti wrote:
you tell me that there is some correlation between HTTP keep alives and
a socket ending up in CLOSE_WAIT for some time. That is the practical
observation. But I'm interested in whether this is by design or not.
RFC 2616 doesn't mention implementation details, and I can't see why
knitti wrote:
you tell me that there is some correlation between HTTP keep alives and
a socket ending up in CLOSE_WAIT for some time. That is the practical
observation. But I'm interested in whether this is by design or not.
RFC 2616 doesn't mention implementation details, and I can't see why
I have a related problem, but I am not sure if the source
IPs are nasty computers or just...
# lsof -ni:www
shows me lots of connections hanging in state CLOSE_WAIT
from some hosts (often in China). These used to eat all
sockets for httpd. Now I have a max-src-conn limit so
it is not a real
Tip.
Don't allow password challenge. Problem solved. Just use key'd ssh and this
problem disappears.
On 11/12/2007, Raimo Niskanen [EMAIL PROTECTED] wrote:
I have a related problem, but I am not sure if the source
IPs are nasty computers or just...
# lsof -ni:www
shows me lots of
badeguruji wrote:
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community 'fix' this
rouge hacker for ever, for everyones good.
Not sure that I
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community 'fix' this
rouge hacker for ever, for everyones good.
This hacker could be spoofing the IPs,
On Dec 7, 2007 10:03 AM, Daniel Ouellet [EMAIL PROTECTED] wrote:
badeguruji wrote:
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community
On 12/7/07, badeguruji [EMAIL PROTECTED] wrote:
Steve, you were able to understand my concern/wish.
Aren't all security experts, just building their own
islands with the problem [of unsecure space] remaining
as it always was? we should try to build a secure
'atmosphere' where 'clouds of all
, but I've got better things to do and really, it's quite harmless :)
--
View this message in context:
http://www.nabble.com/rouge-IPs---user-tf4963521.html#a14225107
Sent from the openbsd user - misc mailing list archive at Nabble.com.
On Sat, 08 Dec 2007 04:05:34 +0700, Unix Fan [EMAIL PROTECTED] wrote:
I think this is the second time you've posted something similar to
this... I have news for you
Everyone gets such traffic in their logs.. from DoS'ers and other
mischievous individuals..
There really isn't much
I think this is the second time you've posted something similar to this... I
have news for you
Everyone gets such traffic in their logs.. from DoS'ers and other mischievous
individuals..
There really isn't much you can do about it either, and if you report back to
each IP's abuse
STeve Andre' wrote:
The one time I did send mail to an ISP was when one little
vandal developed an inordinate fondness for the web server,
and hit it 110,000 times in a week. Fortunately the ISP did
do something about that one. But the lice, I don't think you
can do anything about, unless you
On Friday 07 December 2007 12:51:52 badeguruji wrote:
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community 'fix' this
rouge hacker for ever,
On Dec 7, 2007 1:03 PM, Daniel Ouellet [EMAIL PROTECTED] wrote:
badeguruji wrote:
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community
badeguruji wrote:
And seriously, 'anything' in self-defense is not
violence (or e-violence) - I am not going in hackers'
territory to teach him a lesson, i am only trying to
build a wall [by asking the experts] which can save
all those who are NOT-hacking into other people's
computers, and
On Dec 7, 2007 12:51 PM, badeguruji [EMAIL PROTECTED] wrote:
I am getting constant hacking attempt into my computer
from following IPs. Although, I have configured my ssh
config and tcp-wrappers to deny such attempts. But I
wish some expert soul in this community 'fix' this
rouge hacker for
Thanks guys.
Steve, you were able to understand my concern/wish.
Yes, I have posted the same issue earlier, that time i
was looking for a solution for 'myself', this time i
wish: if something can be done 'for everyone', so i
publicized the IPs hacker('net lice') was coming from.
I was adviced
52 matches
Mail list logo
