Skip to main content

DOS/DDOS protection and EU regulations.

Some time ago I sent question to EU about DOS/DDOS protection because I believe ISPs could do a bit more to protect us:

Dear Sirs,

I found you are responsible of creating safe, reliable Internet. As you know most of EU companies already had or they will have problems with hackers. One of the attacks is commonly known as Denial of Service Attack or Distributed Denial of Service Attack (DOS, DDOS). 15 years ago one document was published, knows as Best Current Practice 38 (BCP 38 or RFC 2267). I don't know why it has not been widely implemented by ISPs during last 15 years. They complained it is very time consuming and difficult to manage. Let me explain how it works:

- every company or home user has IP address or range of IP addresses allocated by ISP (for example 7.7.7.7)
- every edge router is managed by the same ISP who allocates these IP addresses
- BCP 38/RFC 2267 says: block any traffic from network (company or home) where source IP is different from the allocated one
- with this rule the user is not able to perform DDOS attack because the first ISP router will drop it (during such attacks the attacker spoof his own IP and with this configuration all traffic will be denied on the 1st ISP router)
- it doesn't protect all EU against attacks as they are originated from different part of the world but we can stop most of them which are originated in EU
- there is one limitation - the network can't be transit (other institution/companies pass traffic through this one) but for all stub networks, single-homed users (with only one ISP) it is pretty easy.

I think that only EU regulation would force, oblige them  (ISPs) to implement it widely. Last 15 years proved that without any regulation they are not interested to do it. Another possible problem is - the interest conflict - as ISPs can sell, very expensive, DDOS/DOS protection. Such regulation means - less revenue.

I don't know exactly if I sent this message to the correct people. If no, please forward to them. I hope it will help us to have safe Internet.
I couldn't find Bodo Lehmann and Günther Oettinger email, maybe one of them is a right person.


Thank you
Hubert Wisniewski

They sent me respond with some arguments I can't agree with:





I replied with my contra-arguments:


Dear All,
thank you for your respond but I can't understand some of your arguments. I understand that privacy is very important but please look at the traffic with spoofed source IP as driving your car with fake number plates. You should use the original ones but from some reasons you have fake ones. Should we interfere in such matters? Of course the solution is valid only for home and SMB users with one Internet link (not for multihomed users) [and transit networks - I should add]
regards


Let's see what they say.



Comments

  1. Great informative post, thanks so much for sharing your thoughts on this,please visit once at https://www.ddoscube.com.

    ReplyDelete

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an

MAC Authentication Bypass

One of the method to control your network is using MAB feature. It is helpful in case you have devices without dot1x functionality. Today I will try to implement basic configuration and analyze log messages. There is only one switch SW1 and one device attached to port Fa1/0/2.   ! aaa new - model aaa authentication dot1x default group radius ! ! int Fas1 / 0 / 2 authentication host - mode single - host authentication port - control auto mab ! I haven’t configured ACS yet but let’s see what error message I receive:   SW1 ( config - if ) # mab - ev ( Fa1 / 0 / 2 ): Received MAB context create from AuthMgr mab - ev ( Fa1 / 0 / 2 ): Created MAB client context 0x1100000F mab : initial state mab_initialize has enter mab - ev ( Fa1 / 0 / 2 ): Sending create new context event to EAP from MAB for 0x1100000F ( 0000.0000 . 0000 ) mab - sm ( Fa1 / 0 / 2 ): Received event 'MAB_START' on handle 0x1100000F mab : during state mab_initia

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze the packet flo