Yes and let me clarify.
If you read the rest of this discussion, all other emails, you would see that
has been said already.
On Feb 13, 2013, at 11:52 AM, "xenophon\\+freebsd"
wrote:
> khatfield@... writes:
>>
>> Please read the rest of the thread before criticizing.
>
> Let me clarify.
khatfield@... writes:
>
> Please read the rest of the thread before criticizing.
Let me clarify. Naïvely blocking ICMP isn't the only thing firewall admins
should avoid doing. I think that one should construct firewalls in such a
manner that for all prohibited classes of traffic, the firewall
khatfield@s... Writes:
>
> The less you do with the firewall (routing/blocking/inspecting) the
> better.
>
> Drop drop drop ;)
I think this is really bad advice. A firewall should return
destination-unreachable/reset packets for administratively prohibited
traffic types. Drops, null routes, et
Please read the rest of the thread before criticizing.
On Feb 13, 2013, at 9:58 AM, "Matthew X. Economou" wrote:
> khatfield@s... Writes:
>>
>> The less you do with the firewall (routing/blocking/inspecting) the
>> better.
>>
>> Drop drop drop ;)
>
> I think this is really bad advice. A fir
On Wed, 13 Feb 2013 09:28:00 +0100, Dag-Erling Smørgrav wrote:
> Ian Smith writes:
> > Dag-Erling Smørgrav writes:
> > > Slight correction: dropping *all* ICMP is a bad idea. You can get by
> > > with just unreach. Add timex, echoreq and echorep for troubleshooting.
> > rc.firewall, phk
Ian Smith writes:
> Dag-Erling Smørgrav writes:
> > Slight correction: dropping *all* ICMP is a bad idea. You can get by
> > with just unreach. Add timex, echoreq and echorep for troubleshooting.
> rc.firewall, phk@? has long recommended 3,4,11 as "essential" icmptypes.
> Are there any neg
On Wed, 13 Feb 2013 01:52:29 +0100, Dag-Erling Smørgrav wrote:
> Mark Felder writes:
> > Dropping ICMP is not a security method. Please stop doing this!
> Slight correction: dropping *all* ICMP is a bad idea. You can get by
> with just unreach. Add timex, echoreq and echorep for troublesho
Mark Felder writes:
> Dropping ICMP is not a security method. Please stop doing this!
Slight correction: dropping *all* ICMP is a bad idea. You can get by
with just unreach. Add timex, echoreq and echorep for troubleshooting.
For IPv6, you want unreach, toobig, neighbrsol and neighbradv. Add
On Sun, 10 Feb 2013 06:48:08 -0600, Janne Snabb wrote:
Please do not drop all ICMP unless you understand what you are doing. By
doing that you are creating a path MTU discovery blackhole.
I was coming here to say the exact thing
Dropping ICMP is not a security method. Please stop doing this!
On Feb 10, 2013, at 4:42 AM, James Howlett wrote:
> Hello,
>
>
>> I think you'll get some better input if you address some of what Kevin noted
>> above. What firewall (if any) is in place? What rules are currently in
>> place? What tuning have you done so far? Is polling enabled?
>
> 1. I
On Sat, 2013-02-09 at 19:57 -0600, khatfi...@socllc.net wrote:
>
> Deny all ICMP (drop I mean)
Please DON'T do this. ICMP is a required part of the TCP/IP suite.
It breaks Path MTU discovery, leading to oddball issues where some sites
can't load graphics, some file transfers break, etc.
It mak
Kevin,
> That's very helpful to know. So at this time are you doing NAT from the
> router or simply passing all traffic and allowing the switch to sort it out?
>
There is no NAT on my router. The setup looks like that:
ISP--switch--FreeBSD-router---switch---firewall (nat, etc)
THe switch is ba
James,
That's very helpful to know. So at this time are you doing NAT from the router
or simply passing all traffic and allowing the switch to sort it out?
You can google sflow for FreeBSD. There is an export tool for netflow which I
have used that exports as sflow via a bridge type conversion.
On 2013-02-10 03:57, khatfi...@socllc.net wrote:
> Deny all ICMP (drop I mean) and UDP except where specifically required.
Please do not drop all ICMP unless you understand what you are doing. By
doing that you are creating a path MTU discovery blackhole.
See for example the following sites for m
On Feb 10, 2013, at 4:06 AM, James Howlett wrote:
> Hello,
>
> Kevin, thank You for the information.
>
>> FreeBSD is fairly simple to harden against smaller DDoS attacks. Since I am
>> unsure of your connection I cannot recommend specifics. However, it is best
>> to configure polling, tweak s
Hello,
> I think you'll get some better input if you address some of what Kevin noted
> above. What firewall (if any) is in place? What rules are currently in
> place? What tuning have you done so far? Is polling enabled?
1. I use pf on the router.
2. My setup looks like this ISP---switch-
Hello,
Kevin, thank You for the information.
> FreeBSD is fairly simple to harden against smaller DDoS attacks. Since I am
> unsure of your connection I cannot recommend specifics. However, it is best
> to configure polling, tweak sysctl (buffers/sockets/etc), install pf or ipfw
> and do some
Luckily,
FreeBSD is fairly simple to harden against smaller DDoS attacks. Since I am
unsure of your connection I cannot recommend specifics. However, it is best to
configure polling, tweak sysctl (buffers/sockets/etc), install pf or ipfw and
do some straight forward deny/allow + source spoof set
Hi,
I have a router running BGP and OSPF (bird) on FreeBSD.
Are there any best practises one can take in order to protect the network from
DDoS attacks.
I know this isn't easy. But I would like to secure my network as much as
possible.
Even if I'am not able to prevent or block a ddos I would lik
19 matches
Mail list logo
