> I believe that these comments were more along the lines of 'servers
can
> better handle this that stateful firewalls', not ruling out the use of
> load-balancers, reverse-proxy caches, etc. as appropriate.
>
>
---
> Roland Dobbi
On Mon, Jan 11, 2010 at 12:26 AM, jul wrote:
> Martin Hannigan wrote on 05/01/10 16:50:
>>> I see two possible solutions:
>>> - Netflow/sFlow/***Flow feeding a BGP RTBH
>>> - Inline device
>>>
>>>
>>
>> - Outsource to service provider
>
> I want to add some stuff on this as I didn't see them
On Jan 11, 2010, at 12:56 PM, George Bonser wrote:
> One would probably have a load balancer of some sort in front of those
> machines. That is the device that would be fielding any DoS.
Yes, and as you've noted previously, it should be protected via stateless ACLs
in hardware capable of han
> > And I don't believe anyone is necessarily advocating exposing
> individual
> > servers directly to the internet either.
>
> Actually, some of us are.
That can be difficult to do when you have maybe 300 or 400 servers that
handle one service. Let's say you have a site called www.foobar.com an
Martin Hannigan wrote on 05/01/10 16:50:
>> I see two possible solutions:
>> - Netflow/sFlow/***Flow feeding a BGP RTBH
>> - Inline device
>>
>>
>
> - Outsource to service provider
I want to add some stuff on this as I didn't see them with a quick check
on the thread.
Local solution always
On Jan 10, 2010, at 5:40 PM, George Bonser wrote:
> And I don't believe anyone is necessarily advocating exposing individual
> servers directly to the internet either.
Actually, some of us are.
> There are other devices that
> can handle isolation of the servers and protect them against such th
> And I don't believe anyone is necessarily advocating exposing
> individual servers directly to the internet either.
some of us do that
takes all kinds :)
randy
> I certainly understand and agree with your position, in most cases,
but
> there are some instances when a firewall serves an excellent purpose.
> As an
> example, we manage hundreds of heterogeneous servers where customers
> also
> have administrative access to the devices. As such, we can nev
On 1/9/10 10:32 PM, "Dobbins, Roland" wrote:
>
> On Jan 10, 2010, at 1:22 PM, harbor235 wrote:
>
>> Again, a firewall has it's place just like any other device in the network,
>> defense in >>> depth is a prudent philosophy to reduce the chances of
>> compromise, it does not >>>eliminate it
> From: "Dobbins, Roland"
> Date: Sun, 10 Jan 2010 21:56:38 +
>
> On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote:
>
> > The only thing you've said that is being disputed is the the claim
> > that a firewall under a DDoS type of attack will fail before a
> > server under the same type > of
On Jan 11, 2010, at 4:55 AM, James Hess wrote:
> I don't agree with "You never need a proxy in front of a server, it's only
> there to fail".
Again, reverse proxy *caches* are extremely useful in front of Web farms. Pure
proxying makes no sense.
-
On Jan 10, 2010, at 11:55 PM, Roger Marquis wrote:
> The only thing you've said that is being disputed is the the claim that a
> firewall
> under a DDoS type of attack will fail before a server under the same type
> of attack.
It's so obvious that well-crafted programmatically-generated attack
On Sun, Jan 10, 2010 at 11:47 AM, William Herrin wrote:
> On Sun, Jan 10, 2010 at 3:48 AM, James Hess wrote:
>> there are a few different things that can be
>> done, such as the firewall answering on behalf of the server (using
>> SYN cookies) and negotiating connection with the server after t
> On Sun, 10 Jan 2010 08:54:09 CST, Joe Greco said:
> > The use of the words "intended recipient" are also extremely problematic;
> > by definition, if it is addressed to me, I can be construed as being the
> > "intended recipient." If I then turn around and forward it to you, you
> > are now also
> On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco wrote:
> > Putting a stateful firewall in front of that would be dumb; the server
> > is completely capable of coping with the superfluous SYN's in a much
> > more competent manner than the firewall.
>
> The trouble with blanket statements about "all s
Joe Greco wrote:
Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended
recipient.*destroy.*copies/siand be done with it.The
individual sender normally has no control over the matter, so their
only two choices are: (a) Post with the notice, or (b) Don't post at
all.
Wow, a
On Sun, Jan 10, 2010 at 12:47 PM, William Herrin wrote:
> Even if it does
> send an RST, most application developers aren't well enough versed in
> sockets programming to block on the shutdown and check the success
> status,
Sorry, I got that wrong. shutdown() will succeed without waiting for a
F
On Sun, Jan 10, 2010 at 3:48 AM, James Hess wrote:
> there are a few different things that can be
> done, such as the firewall answering on behalf of the server (using
> SYN cookies) and negotiating connection with the server after the
> final ACK.
James,
That's called a proxy or sometimes an
On Sun, 10 Jan 2010 08:54:09 CST, Joe Greco said:
> The use of the words "intended recipient" are also extremely problematic;
> by definition, if it is addressed to me, I can be construed as being the
> "intended recipient." If I then turn around and forward it to you, you
> are now also an "inte
On Sun, 10 Jan 2010 08:19:27 PST, Roger Marquis said:
> > Then you need to get rid of that '90's antique web server and get
> > something modern. When you say "interrupt-bound hardware," all you
> > are doing is showing that you're not familiar with modern servers
> > and quality operating systems
From someone who mostly lerks but has been in network engineering operations
biz for 17 years, the only OS that seems to always keel over under a ddos and
need a firewall is windows. Linux in its current incarnation can handle a
substantially larger attack before needing mitigation by firewall t
> > Then you need to get rid of that '90's antique web server and get
> > something modern. When you say "interrupt-bound hardware," all you
> > are doing is showing that you're not familiar with modern servers
> > and quality operating systems that are designed to mitigate things
> > like DDoS at
Dobbins, Roland wrote:
My employer's products don't compete with firewalls, they *protect* them;
if anything, it's in my pecuniary interest to *encourage* firewall
deployments, so said firewalls will fall down and need protection, heh.
Nobody's disputing that Roland, or the fact that different
Then you need to get rid of that '90's antique web server and get
something modern. When you say "interrupt-bound hardware," all you
are doing is showing that you're not familiar with modern servers
and quality operating systems that are designed to mitigate things
like DDoS attacks.
"Modern" s
> Actually that's not a great idea. A notice that the recipient is
> expected to handle information with unusual attention to
> confidentiality is required by law to stand out so that there isn't
> any ambiguity about the duties demanded of the recipient. Trade secret
> cases have been lost because
> Spam filter your inbox on /CONFIDENTIALITY NOTICE.*intended
> recipient.*destroy.*copies/siand be done with it.The
> individual sender normally has no control over the matter, so their
> only two choices are: (a) Post with the notice, or (b) Don't post at
> all.
Wow, are you implying
> Firewalls do a good job of protecting servers, when properly configured,
> because they are designed exclusively for the task. Their CAM tables,
> realtime ASICs and low latencies are very much unlike the CPU-driven,
> interrupt-bound hardware and kernel-locking, multi-tasking software on a
> ty
Hi!
I have try to check BGP traffic behaviors related to recent VISPA ISP DDOS.
For this task I have using BGplay and I need feedback about my analysis. If
you are interested check
http://extraexploit.blogspot.com/2010/01/trying-to-analyze-vispa-isp-outage_08.html
Thank you for your attention.
On Jan 10, 2010, at 3:48 PM, James Hess wrote:
> Firewalls do not need to build a state entry for
> partial TCP sessions, there are a few different things that can be
> done, such as the firewall answering on behalf of the server (using
> SYN cookies) and negotiating connection with the serve
On Fri, Jan 8, 2010 at 10:48 AM, Joe Greco wrote:
> Putting a stateful firewall in front of that would be dumb; the server
> is completely capable of coping with the superfluous SYN's in a much
> more competent manner than the firewall.
The trouble with blanket statements about "all stateful fire
30 matches
Mail list logo
