On Tue, Nov 08, 2005 at 01:56:41PM -0800, Lars Eggert wrote:
> On Nov 8, 2005, at 12:46, Marc Olzheim wrote:
> >Being on the wrong end of a distributed tcp syn flood attack atm.
> >on the
> >machine I'm mailing from, is probably enough to convince me of its
> >use.
>
> The change we are discus
On Nov 8, 2005, at 12:46, Marc Olzheim wrote:
Being on the wrong end of a distributed tcp syn flood attack atm.
on the
machine I'm mailing from, is probably enough to convince me of its
use.
The change we are discussing is not protecting you from SYN floods,
it is supposed to protect you f
On Nov 8, 2005, at 11:54, Mathieu CHATEAU wrote:
1/it can be set back if needed
It can be enabled, too, if needed.
2/95% of users will get benefits against 5% that will disable it
I'd love to see a source for those numbers.
3/over the time, i am having above 70 lines in sysctl.conf to get
Hi,
On Nov 8, 2005, at 11:23, Mike Silbersack wrote:
I'm open to discussing the change. I plan to revisit that and the
SYN causing a connection reset issue after eurobsdcon.
good to know, thanks!
However, I'm open to clubbing you over the head for not saying
anything throughout the enti
On Tue, Nov 08, 2005 at 11:02:25AM -0800, Lars Eggert wrote:
> Thus, I'd like to suggest that the default for
> net.inet.tcp.insecure_rst be zero for now. AFAIK, any other TCP mod
> came disabled be default in the past, too.
Being on the wrong end of a distributed tcp syn flood attack atm. on
On Tue, Nov 08, 2005 at 11:02:25AM -0800, Lars Eggert wrote:
> Hi,
>
> I came across the following in the release notes of 6.0 recently:
>
> "The RST handling of the FreeBSD TCP stack has been improved to make
> reset attacks as difficult as possible while maintaining
> compatibility with the
hello,
to start with, i don't want to raise a troll...
argue to keep it set:
1/it can be set back if needed
2/95% of users will get benefits against 5% that will disable it
3/over the time, i am having above 70 lines in sysctl.conf to get
FreeBSD secured and the network strong and fast.
4/the 5%
> On Fri, 4 Nov 2005 23:55:39 +0200
> Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
>
> [..]
>
> > I know. Please try what's in CVS now (I made three revisions
> > to ng_fec.c). I wonder, are you assigning an IP address to
> > fec0 or doing "ifconfig fec0 up" before confuguring the
> > bundle (addi
On Tue, 8 Nov 2005, Lars Eggert wrote:
Thus, I'd like to suggest that the default for net.inet.tcp.insecure_rst be
zero for now. AFAIK, any other TCP mod came disabled be default in the past,
too.
Lars
I'm open to discussing the change. I plan to revisit that and the SYN
causing a connec
Hi,
I came across the following in the release notes of 6.0 recently:
"The RST handling of the FreeBSD TCP stack has been improved to make
reset attacks as difficult as possible while maintaining
compatibility with the widest range of TCP stacks. (...) Note that
this behavior technically v
At Mon, 7 Nov 2005 14:13:13 -0500,
David Boyd wrote:
>
> Panics occur as often as every few hours (usually once or twice a day) on
> eight identical systems used as VPN devices in hospital radiology appliance
> maintenance network. System were upgraded to 5.4-STABLE because panic(s)
> was followe
(Apologize for possible duplicate messages)
Dear all,
This is an important announcement from the KAME project. I'm SUZUKI,
Shinsuke, sending this message on behalf of the project.
It is our pleasure to announce that the KAME project has achieved its
project mission, which was to establish the I
On Monday 07 November 2005 08:38 pm, Vaibhave Agarwal wrote:
> On Mon, 7 Nov 2005, John Baldwin wrote:
> > And even then it can't be used for any device interrupts since there
> > aren't any I/O APICs. On a UP machine without I/O APICs, it's actually
> > probably more optimal to just use irq0 and
On Fri, 4 Nov 2005 23:55:39 +0200
Ruslan Ermilov <[EMAIL PROTECTED]> wrote:
[..]
> I know. Please try what's in CVS now (I made three revisions
> to ng_fec.c). I wonder, are you assigning an IP address to
> fec0 or doing "ifconfig fec0 up" before confuguring the
> bundle (adding ports)?
I trie
problem:
IPMI will highjack packets to ports 623/664, so packets
which get assigned either port, will not get back to the application.
Question:
Is there a way to blacklist these ports?
thanks,
danny
___
freebsd-net@freebsd.org
15 matches
Mail list logo
