PDA

View Full Version : DDOS on our websites



cpsundar
2009-08-26, 12:53
Hi,

Our websites are contantly being attacked with DDOS.Our Traffic has risen from 50000 PPS to 300000 PPS(Packets Per Second). We could see HTTP SYN and ACK being sent to the server and server keeps the connection established. We tried with SYN relay and Cookies mode where it did not bring any noticeable difference. With Network Quota the CP gets busy starts loosing all connections with RTOS to the whole network. We are using SPLAT with NGX R65.

Thanks in advance.

cps

arkonr
2009-08-27, 06:14
Hi.
Can you tell if there are certain specific IPs (or range of IPs attacking you) ?
one suggestion i can give is to use the "Template quota" capability, assuming you are using SecureXL/Performance pack.
you can see more about it on Check Ppoint support site - sk33239


Enjoy.

philuxe
2009-11-03, 12:11
hi
We have the same issue here, NGX R65 cluster with HFA_02, security policy is around 750 rules, and 200 NAT rules
4 cores at 3.2ghz, secureXL on, 12Go RAM, 300Mbps internet connection

A simple NMAP tcp (-p1-65535) scan to our DMZ's /24 IP blocks makes the cpu increasing to 100% and kills the gateway which stops processing packet

-> the real DOS :)))

the problem is actually smartdefense inspection occurs after the packets have been inspected by the rule base. Of course in my case only the last clean up rule matches the DOS packets meaning the firewall has to match every DOS packet against the 700 policies before getting dropped by the last rule !

not very effective... we are working with the CP support to see what could be done to improve the GW behavior under such attacks !


I have read the sk33239 , will see what CP suggests :/

if anyone has similar experience please dont hesitate to let me know what u did to solve that problem

lammbo
2009-11-03, 12:33
hi
We have the same issue here, NGX R65 cluster with HFA_02, security policy is around 750 rules, and 200 NAT rules
4 cores at 3.2ghz, secureXL on, 12Go RAM, 300Mbps internet connection

A simple NMAP tcp (-p1-65535) scan to our DMZ's /24 IP blocks makes the cpu increasing to 100% and kills the gateway which stops processing packet

-> the real DOS :)))

the problem is actually smartdefense inspection occurs after the packets have been inspected by the rule base. Of course in my case only the last clean up rule matches the DOS packets meaning the firewall has to match every DOS packet against the 700 policies before getting dropped by the last rule !

not very effective... we are working with the CP support to see what could be done to improve the GW behavior under such attacks !


I have read the sk33239 , will see what CP suggests :/

if anyone has similar experience please dont hesitate to let me know what u did to solve that problem


R70.1 + CoreXL + new IPS-1 engine

philuxe
2009-11-03, 13:02
well the solution is just more money then !!

i m very suprised, checkpoint is doing firewalls right ?

are firewalls supposed to resist to a basic TCP scan ran from a single internet host ???

boldin
2009-11-03, 14:08
If it's all coming from the same network or host, just pop in a Suspicious Activity Monitor rule - quick and easy.

I've heard that there is a SmartDefense protection for this, but have no familiarity with it.

You may also try tweaking your aggressive aging settings...




are firewalls supposed to resist to a basic TCP scan ran from a single internet host ???



-that's why it's called denial of service...

you throw enough traffic at any device and it will be brought down

philuxe
2009-11-03, 15:01
its easy with nmap to randomize the source IP address when scanning, in that case SD protections are useless

the problem is not the amount of data the attacker is sending while scanning it is the quantity of SYN packet, and each one has to be inspected by the 700 rules (in my case).

I'm wondering if we came (or not) to the limit of the checkpoint based firewall, the way they organize the rule base does that the clean UP rule MUST be the last one , when you have 700 or 1000 policies thats another story.
I think thats why other firewall vendors organizes the rules based on zone (cisco IOS) or matrixes (fortinet)

but thats right the solution is probably spending more money : coreXL and the new blade system.

Was SecureXL/Perfpack not supposed to solve performance issue ? or maybe they consider performances when it comes to legitimate traffic (accepted by the policy) only ?

northlandboy
2009-11-03, 15:56
It depends a bit on the structure of your network, but I would say that having a public-facing system with over 700 rules, as your first line of defence, is not the best option, particularly if you have large public IP blocks.

I would probably rather do some coarse filtering a step out from the firewall. Depends on what services you're allowing, but you could filter out addresses that don't have anything using them yet, and possibly filter down to port level if you've got systems that only accept say 80/443.

You could also look at the layout of your rulebase - e.g. put the inbound rules at the top, then drop anything else inbound, before your outbound rules. Depends on what your rulebase looks like - do you have a handful of inbound, and lots of outbound? Or do you have a large number of inbound rules?

lammbo
2009-11-03, 17:25
are firewalls supposed to resist to a basic TCP scan ran from a single internet host ???

DDOS implies DISTRIBUTED, so not just one host. DOS is a lot easier for an inspect engine to detect than DDOS. If there are 10,000 hosts infected with bots attacking you, how do you determine it is DDOS rather than valid traffic. In many cases, you will find that DDOS is simply a game of who has more resources.


I'm wondering if we came (or not) to the limit of the checkpoint based firewall, the way they organize the rule base does that the clean UP rule MUST be the last one , when you have 700 or 1000 policies thats another story.
I think thats why other firewall vendors organizes the rules based on zone (cisco IOS) or matrixes (fortinet)
Who says you can't write your rulebase in zones? Simply take your 'ANY to NAT' rules for that subnet and place them closer to the top of your rulebase. Then add a cleanup rule that is just for that subnet that is something along the lines of:
SRC = <NEGATED Encryption Domain>, DST = <Public facing subnet>, PROTO = Any, Action = Drop
Problem solved, you no longer have to let the traffic pass the entire rulebase because this rule allows other rules below this section to still process for your internal traffic, but drops public traffic because it's not in your encryption domain. If you're dealing with multiple sites then make a group that includes all site's networks and use that group as SRC. Many tend to forget or underestimate the power of a rule with a negated cell; this is especially true when dealing with rules where the SRC would normally be 'ANY'.



but thats right the solution is probably spending more money : coreXL and the new blade system.


Was SecureXL/Perfpack not supposed to solve performance issue ? or maybe they consider performances when it comes to legitimate traffic (accepted by the policy) only ?

SecureXL/PerformancePack are how old now? The method of attacks have not stopped evolving and neither has the technology to deal with them. Yes, CoreXL and new IPS engine are examples of how to deal with this.


I would probably rather do some coarse filtering a step out from the firewall. Depends on what services you're allowing, but you could filter out addresses that don't have anything using them yet, and possibly filter down to port level if you've got systems that only accept say 80/443

I second this! I have ACLs on my perimeter routers that drop all protocols I don't allow through my rulebase. It's very coarse but it keeps many packets from ever reaching the firewall at all. Granted, this method lets through all protocols to any IP if they are allowed to even 1 host, but the firewall then drops the rest of them. It is still effective as a first line of defense.

philuxe
2009-11-05, 05:05
agree with both of you

I need to reorganize the rule base and/or purchase CoreXL