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 a
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 intenti
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 wor
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"
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
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 o
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 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 req
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
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
so
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,
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
shu
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,
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
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:
> 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
> > so
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 understan
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:
> 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
enBSD-Misc
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
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
noth
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 connecti
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
> clo
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
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
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
the
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
the
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 fi
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 t
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,
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, 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 t
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 conne
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 time
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
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
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) ab
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 c
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 probl
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
down and string 'em
up too, 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.
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,
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 muc
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 email
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
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 fo
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 c
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 comm
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 com
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 und
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, bu
52 matches
Mail list logo