So the next talk in our schedule is DDoS Attack and Defense. It will be presented by our speaker Craig. Craig has been working on the hosting business for the last 11 years. And as hosting providers, they receive a lot of DDoS attacks. So his talk will be about this and how they handle this and from the hosting provider perspective. So the stage is yours, Craig. And give him a warm applause, please. Thank you. Yeah, so this about me. So like he already said, I'm in the hosting business. So my perspective is from that side. So the environment I'm working in, we have several BGP routers, we have transits, we have dark fiber. So that's the environment. I mean, so there's also the Twitter link if you want to ask some questions later. So the agenda for now, I'll introduce you to some basics. We'll talk about technical details about some of the most common attacks. I'll talk about detection, what to do for defense, and a little bit of a fun part is aggressive network self-defense. So what is denial of service? This is the total basics. So you want to access a website and you enter it into your browser. Can we start? And you see this. So the site is unavailable. Good morning, everybody. Sorry, I think there's some issue with the sound. Yeah, there's background noise. Okay. Oh. I'm the background noise for the other stage right now. Sorry about that. Okay, is it fixed or? No. You see how it was always on the way. Yeah, the Herod is on the way, so. Can you still hear me? Okay, I think it's fixed. I can't hear the other stage anymore. Oh, okay. Is it okay? Okay. So you want to visit a website and you see it's unavailable. So that's the denial of service part. The service is denied to you. But what is DDoS? DDoS is distributed denial of service, which means that your server is attacked not only by one attacker, but by lots of systems. So for example, by a botnet. Why are people doing that? Well, it works. They have different reasons. So I'm just going to talk about the technical side now. So all of these attacks, they exhaust some resources. It can be CPO, IO, RAM, the connections per second that your system can handle, the total connections it can hold, or the bandwidth, for example. There's also some artificial limits sometimes. For example, default settings in Apache, or there's a license issue. Some firewall vendors have a license that only allows a million concurrent connections, for example. There can be operating system limits or your partners are limiting factor. For example, if you have a one gigabit uplink and the uplink is full, well, you can't do anything about it. So some of the classic attacks are layer three attacks with IP or ICMP. You just get flooded with those until your pipe is full. Like for example, if you have the one gigabit link, it's full and you can't serve content anymore. Or the other requests aren't arriving at your system. And it's very common to spoof this kind of traffic. So you don't really see who's attacking you or if it's one attacker or several ones. Another classic attack is via layer four, via TCP. And so to explain this, I have to introduce you to the three-way handshake. So the client sends a SYN packet to your server. The server answers with a SYN ACP packet and then the client answers again with the ACP packet. And then only then the connection is established and then you can share data over this connection. So what the attack does, it sends lots of connections that are spoofed to your server. And the server tries to answer it even several times because if an SYN ACP packet gets lost, he resents it. But as these connections are spoofed, there's never an answer to it. And the server is just overloaded at some point and can't take new connection requests anymore. Okay, the next protocol that's often used for attacks is UDP. So it's a stateless protocol, there's no session in the protocol itself and it's used for amplification purposes. You've probably heard about this in the media already. It works like this. For example, you have two servers that can spoof traffic. So they send lots of packets to DNS resolvers, for example, but those packets are spoofed with a source address of the server you want to attack. So all these servers answer with a packet that's bigger than the one that was sent.  So this is a band with attack, a reflected band with attack. Some of these reflection factors are really, really high. So if you use DNS for this and you have, let's say, a reflection factor of 30, you'll send out traffic with one gigabit per second and the receiver gets 30 gigabits per second incoming traffic. This is an example, NTP monoliths. So this is a feature that was in the NTP daemon. You could ask it who's currently querying it. So you can see this is my address from the Congress network. I've been querying this NTP server. And for example, you can see here in this line how many or how often this IP already requested an NTP packet. So this is a Chinese IP that's currently being DDoS'd. Okay, now to layer seven attacks. The example here is slowloris, which was also in the media. So this establishes a full layer seven TCP IP connection and then it sends the usual headers. But then here where the three dots are, there's a pause and then it sends the next header and the next header and the next header and so on. So it just keeps the connection open. So if you do this a couple of times, and for example, Apache in the default settings can only handle maybe a thousand connections, then you'll fill up the connection queue of the server making it unavailable. There's lots of variations for layer seven attacks. So for example, you can use slow downloads to exhaust connections. So for example, you open a thousand connections and just download with one byte per second. All the connection queues are full or use fast downloads to exhaust the bandwidth of the server. Or you try to exhaust the backend servers, for example, by putting in variables into form fields or searches so that the backend servers are really, really busy and just can't answer anymore. Another example is, or an example for this is the WebLog that actually was used by anonymous to attack some of our servers. So you just open a URL in your web browser.  And this just starts flueing the server from your browser. So there's no extra software you need to download. And lots of people like this kind of thing because they don't have to download any program. There can't be a backdoor in it or things like that. So let's look into this, what this is actually doing. So you can see there's some characteristics here of the query that are really easy to analyze or to use to filter. So the request is always like this because it's just hard coded in the WebLog JavaScript code. And the message part here is also hard coded, but you can use your own message. And this number here is a Unix timestamp with a little bit, with three extra numbers behind it. And the referrer is always the same. So it's really easy to filter this DDoS attack in your load balancer. If an attack has these parameters and this referrer just dropped the connection. However, it's a browser you're using. So it will follow HTTP redirects. Which means I could just reflect this attack to someone else. So for example, I could just give you redirect if you have these parameters and send you to fbi.gov or something, right? So yeah, there's also layer seven amplification. It's been a little bit in the media a while ago. For example, WordPress has the pingback feature and Humla also. And so this is what this will look like in your logs. You will just, you can query WordPress and you can make it request a URL from a different server. So if you do this on a large scale and use all the WordPress installations for it, it's, yeah, you can exhaust the server pretty easily because there's a few hundred thousand WordPress installations on the web. And as far as I know, they still didn't remove the XML RPC PHP PHP file for this. So if you're hosting WordPress, take a look. Also SSL and TLS is pretty important because the handshake performance of SSL or TLS is asymmetric. So the server has to do more calculation than the client has to do. So there was a tool called THC SSL that was exploiting this. It was using lots of renegotiation requests. That's the asymmetric handshake. So the asymmetric handshake will occur lots of times and this will cause high CPU load on the server that you're requesting this from. Also RSA is really CPU intensive. So if you're hosting a server, ECC is a better choice and all modern browsers can handle ECC. There's also the IoT botnets right now that have been in the media a lot. There was a Cloudflare blog post about this. So there were about 50,000 cameras that were attacking them. And they did about 1.75 million HTTP requests per second. So these botnets are pretty huge. And OVH, it's a little bit hard to read here. OVH also got attacked by about 150,000 cameras and DVRs. And this botnet was able to generate 1.5 terabets of traffic per second. So in summary, there's different parts where it is possible to attack the systems you're hosting. So for example, in the router or already in the uplink, people can try to fill it. You can use the session, you can exploit session limits. For example, in load balancer or in a cache or you can cause something that causes your servers in the back end to have high loads. So how is it possible to detect DDoS in order to block it later? You can work with anomalies. For example, packets per second that you're getting for a specific service you're hosting. You can just have a look at your bandwidth. And people often use tools for this that base on NetFlow or SFlow. That's Sflow as packet sampling. NetFlow will send complete flows to an analyzer so you can look into this. Or usually people already have Libre NMS or a Singer where you can see bandwidth limits, for example. There's also some products. Fastnetmon is open source. I can really recommend this one. There's Andresoft Wangot, for example, and there's different appliances, which I'm going to talk about in a bit. Or you can use something self-written, Rafaana, or an ELK stack where you just put in all the NetFlow data you're getting and you're writing custom rules. So counter measures. Usually you try to filter in different layers. So in the first layer, for example, you would throw away all invalid packets, spoof packets that you can detect, things like that. And then you have different filters, and in the end you hopefully only get the good track. So the first thing you really need is a competent experience team. You should be doing workshops and get to know DDoS tools, just have some test runs, have playbooks that say if we get attacked, we do this, we do that. And you, of course, always have to have someone on call. You also should take care of protecting your meta services. DNS, protect your APIs. If mailing is important for your company, also take care of protecting that. So what you shouldn't do is don't block single IPs manually against layer three and layer four attacks. This is very ineffective. If you start something like NetStart, you look like, oh, which servers are connected, and you just cut and sort and things like that, this will not be effective at all. Especially if it's spoofed attack, what's the point in even blocking a spoofed IP? The next packet will come with a different spoofed IP. So that's not good at all. Don't put code on your web server. Like, for example, put some stuff in your PHP file is also very ineffective. Tuning individual TCP IP settings for Linux is also not really helping usually. And try not to focus on individual tools. I've mentioned the web log before. Well, maybe the next day someone will come with a different tool or with a tool that's just behaving differently and you can't filter it anymore. So in order to explain some of the countermeasures, I need to quickly talk about BGP and the internet. So for example, let's say you're here, one of the internet users, we're an ISP, we're not an ISP, but we're a hosting provider. So we get upstream from different providers. So it can take different routes. For example, with this tier three network provider, traffic can come in here or we are also peering with a different provider. And for example, also have transit with a tier one ISP. So the traffic could also come from this direction or it could come from here. So these systems are one provider is running one AS and these ASs and these autonomous systems are interfacing with each other. Can we do the questions in the end? Okay. So best practices for this is filter out Martian packets. It saves a few persons on incoming DDoS already. This is because most providers, if they have a packet, they don't look at the source, they only look at the destination. So they forward it and you get lots of traffic that you can't even answer. So this is already helping a little bit. What you can do, this is an easy fix. You can just black hole the service that's getting attacked. That could be okay if your SLA says, for example, you have 99.9% that you need to keep this website online per year.  But usually that's not the case. So what you can do on premise or in your DC or if you're hosting in the cloud what you could do there, take care that you have at least a little bit of bandwidth. So at least 10 gigabit, increase the performance so you can handle this bandwidth. I've seen this a couple of times. People have a very small firewall that can just handle a million connections per second and this is very easily exhausted. You can also put Adidas appliance in your data center or a rent one. So in order to filter out some of these attacks. What you should do is block layer seven attacks early. So if you have a load balancer that can detect this kind of attack, for example, the WebLog, you could have an API or an interface to your firewall that blocks the packets, the malicious packets before they arrive on your load balancer. So if there was a client that was doing a thousand requests per second, you can just firewall it off very early. What you need to do is probably horizontal scaling. So if you have multiple uplinks, for example, 50 gigabits, it's very expensive to buy a 50 gigabit firewall. So just split the traffic on your router on different systems. Maybe your systems are weaker and can only take five gigabits per second. So split it to more systems and if one of these systems fails, if you have 10, you lose 10% capacity, but if you only have one big system, of course that's not a good idea. On premise, you could run a private cloud. For example, if you have an issue with SSL, you could run a Kubernetes cluster and terminate all SSL traffic there. And if you get more traffic, it will automatically expand or it will shrink again if you don't have that much traffic there. I found SunCookies to be ineffective on premise. But there have been major improvements in Linux. In XDP, for example, if you're interested in building your own appliance or on firewall, you should really look into XDP for this. Okay, now let's talk about appliances. They're often sold as magic or the vendor says, of course, we can handle every kind of data's attack, but we'll see if that's true. Often against Sunflot, these appliances will play some TCP IP games, kind of. So the device is in the middle here in front of your server. So it terminates if there's a Sun packet, it receives it and the mitigation device sends the Sun packet, not the server. So the server is still idle and doing nothing, right? And afterwards, the connection here, after the packet, the connection is established, but then the mitigation device sends an RST to reset the connection. And only then, only for the second connection, the client is allowed to connect to the actual server. So this is a good way to mitigate spoofed Sunflots. There's a different way. This is the out-of-sequence hack. So again, a client sends a Sun, the mitigation device blocks this or intercepts this and answers with the hack with the wrong sequence number. So of course, the client sends an RST because it doesn't have a connection for this, but on the second try, the appliance also allows the connection to go through. This is also a very effective way. There's a third way which hardly anyone implements. I'll come to that later. So this is the Sun proxy. The client sends a Sun packet to, of course, the mitigation device intercepts this again. It answers with a Sun hack and an hack, but only when the connection is established here, then it'll establish the connection to the server. And after this, the traffic can flow between the client and the server so the data can actually flow. I've been looking into different vendors and these are some of the options that you can find in the interface. So you can, well, often these are not very well explained and you have to read up on them, but yeah, you can see these are some standard methods. So for this vendor, I was testing the resilience against Sunflot, but it doesn't have any, they don't want to implement state in it. So it has no Sun proxy and they're using some kind of shaping in order for you to stay online and those TCP IP games that I was mentioning, but this has some problems. Some firewalls, when they see you're sending an out of Sun hack packet, they will just drop it. So it won't be answered and behind several firewall vendors, you will have lots of collateral damage. So this can, for us, this was up to maybe 20%. So this is clearly unacceptable. I mean, it's better to stay online for 80% of our clients than to be offline, but still this is not a working solution for us. A different vendor we're testing, they also do TCP IP and for layer seven, they are using CAPTCHAs to defend against this. So the website presents you with a dialogue, maybe a little bit like Cloudflare and you have to enter in the CAPTCHA to prove that you're a human, but the CAPTCHA was broken in the latest Chrome version. They didn't provide a patch for it for about half a year. So of course, it was unusable too and they had a bad performance for small PPS. They were good for some other things, but yeah. So in summary for appliances, you can say they fail at different things. Don't buy before you've extensively tested it. You should have a test checklist for your evaluation and you need to be very careful with the licensing terms because some appliances have 10 gigabit uplinks, but the license is only for two gigabit, for example, or there's limits and they can only, well, they can handle 10 gigabits of good traffic, but only one gigabit of bad traffic. Some other countermeasures that you can take is work together with your transit provider. I mean, why not? You've already established trust with them, so they can put in some ACLs for you. For example, for GDP amplification, it's really easy to have ACLs for your transit provider because why would I need UDP traffic on my website, all right? So just give them a filter list and when traffic, wherever traffic enters their network, they will already drop it. You can work with blackholing that's region-based. For example, if you're having software for an election in your own country and there's a DDoS attack, well, just keep it online for your own country or if there's mostly interest for your website in your own country, like 99.9%, well, then this can be an effective method. Of course, some of the transit providers are renting out their DDoS appliances. You can buy DDoS mitigation services from them. Some of them have their own security operating center that you can call 24-7 and they will take care of filtering DDoS for you, even layer seven attacks. Yeah, and some of those also provide proxying. So your own IP space, you don't use your own IP space, they have their, they just proxy traffic towards you, like, yeah, with a reverse proxy. For layer seven, like I mentioned before, you can show a capture, you can use a redirect, for example, a 301 redirect and then your clients will check if the attacker or the client is following the redirect and if it's not, it's probably not a valid HTTP client so it get blocked or you can use a proof of work. For example, that's a cryptographic puzzle that the client needs to solve. I think Cloudflare is already implementing this. So what I would recommend is combine local defense and the partner. You can use something like cloud signaling, for example, if you have a local appliance and it detects that's their DDoS attack that you won't be able to handle anymore. For example, you only have 10 gigabits of uplink and the appliance detects that 9.9 gigabits are already in use so it can do some cloud signaling and some other, well, the provider will start announcing your BGP prefixes, for example, in the internet so that they're taking a different route and they will terminate the traffic there and clean it and return and send the clean traffic only towards you. You can do this via DNS also. That's the usual setup for Cloudflare. They will host your DNS. They will run a reverse proxy for you and they will take care of this. And finally, there's also FlowSpec, which hardly anyone implements because it means that you can dynamically send firewall rules to the provider that they will implement. Okay, and there's different ways of setting this up so you can have on-demand or always on. Always on is usually a lot more expensive because they have to have the capacity to forward your traffic all the time. Some other countermeasures could be to move to the public cloud. I've also done this and this works very well. Just use AVS, buy a cloud balancer, use auto-scaling and use this to terminate traffic. OVH is mostly known as a hoster but they also have very good DDoS defense. But, well, the question is if this is very cheap, if you use auto-scaling with AVS, this can cost very, very, this can cost very, very high costs. The proper way or the best way to defend any DDoS is using anycast, so this is a map from Cloudflare. Anycast means that you're announcing your prefixes at lots of points of presence. So, for example, if there's a DDoS attack starting in Tokyo and you see that it's really hard to see, there's a little dot and you also have a presence in Tokyo, then the traffic will be terminated there already. So, this means, so let's say we have a one terabit per second attack, the attack will split on different data centers if you do this. So, you don't have to have equipment that can handle one terabit everywhere. You have equipment maybe for 50 or 100 gigabits at different locations. And then you terminate the traffic there already and only forward the clean traffic. Well, yeah, of course, for countermeasures, use a competent DDoS provider. Cloudflare is one of the good ones, I guess. It has a free tier. You can use the professional one as only 200 bucks per month. Akamai is really expensive, but they're, well, they're the biggest player in the market, I guess. And yeah, that's also Prolexic. But take care, if you're running behind Cloudflare, for example, it's a full layer seven proxy that's in front of your devices. So, this can mean leaking data as it has happened before. There was currently like two weeks ago something in the media about the web cache deception attacks. It's an interesting read too. Or those providers may ignore headers that you're sending or there can be random connectivity issues. So, for example, maybe 1% of the traffic gets dropped and you're having a really hard time finding out why that happens. And yeah, you have to take care also of the outgoing traffic because it's going, completely going through them. So, if they modify some headers, for example, pragma no cache for some web form, that's not a good thing. Also, it's important not to leak origin IPs. This is something that happened sometimes. So, you enable Cloudflare, but you forgot that your MX record still points to your original IP. You need to check that you've modified this after migrating behind any DDoS provider, usually. Or the best way to do this is to get a direct connection with the DDoS provider. Well, countermeasures that you should take is to implement BCP 38. This means you don't allow outgoing traffic to be spoofed. So, if one of your servers gets hacked, it can't be used for outgoing spoofing. You could also try to build your own Anycast network. This is a very high investment. You will need an advanced skill set. It has very high monthly costs, and if you read some Cloudflare blog posts, how they're troubleshooting, and how their network works, you will probably get discouraged really quickly. So, in summary, you can say, well, layer seven is difficult, and layer seven defense is also very difficult, and it doesn't always work. There's some caching issues. For example, for form fields, these can't be cached. HTTP Post is often a problem. It's often not being cached by those providers, and if you set specific cookies, well, you don't want to cache some data that a logged in user only sees. Well, that's, of course, a problem. So, what do you think? Is this an actual DDoS, or did we have an important event? Who thinks this is DDoS? Okay, now for the next slide. What about this one? Okay, the first one was the DDoS, but this is actual real traffic, so this was a valid thing. There's also counter-measures. For example, at DEF CON21, there's been a presentation of how to circumvent Cloudflare. They could even bypass the captures, the redirects, and things like that. The key point to this is behaving like a regular browser, and then it's probably, well, it's not that big of a problem to circumvent some of these methods I've mentioned before. True mitigation would require to do a proof of work, so it's a client puzzle in JavaScript. For example, you make the client calculate a cryptographic hash that has certain, yeah, that looks in a certain way, and only then it can access your website. So you need to do a cost, it needs to cost some resources on the client side. There's also some bad apples in the DDoS, anti-DDoS market, so one of our customers decided that they wanted to work with this specific provider. It looked like a cheap copy of Cloudflare, and when we checked, they only had three employees. I'm wondering how they do their 24-7 shifts. The contract was if we felt you don't pay a type of contract, so basically they could do nothing, and then we just would pay nothing, okay? One of their partners used to sell bullet-proof hosting, and when we set up with them, where we had a dedicated link to them, they had some routing issues, and they were usually sending traffic on our public transit, and not on the private interconnect we had caused. Okay, what do you think? A DDoS happens? Will this work? Well, of course not. They implemented filtering based on TTL, so they just blocked everyone that had a certain time to live in their TCP IP packets. They couldn't defend against the two gigabit DDoS attack. Of course, we had some downtime, and the DDoS report on this only arrived a few weeks later when we continuously asked about this. Then there was a second DDoS, and it showed that they didn't detect layer seven attacks at all. So the slide before, the first slide, I mean, where I ask you if this is a DDoS attack, well, this was a DDoS attack behind an anti-DDoS provider. It just went clearly through. It was four Chinese IPs that were requesting a huge video file, so, yeah, choose your provider wisely. So, okay, now to a little bit, to a fun part. I call this aggressive network self-defense. Don't do this at home. Don't do this at work, okay? It's probably illegal. Okay, this is just some theory, okay? So let's say we're getting a layer seven attack. 1,000 people decided that they want to run the WebLog. We have a bandwidth of 50 gigabits per second, and currently, well, maybe let's say our normal traffic is one gigabit in, one gigabit out, so we have 49 spare gigabits per second. For one gigabit per second, you can send 1.448 million packets per second. So if you calculate it, we could send 71,000 packets per second to every attacker that's taking part in this. And if you have a very cheap router at home or your internet pipe is not too big, this is enough to disable this complete attack.  If you're, well, there were attacks by IoT botnets, but there were some anti IoT DDoS botnets bots. One of those is called Bricker Bot, and the author said he regarded this as kind of an internet chemotherapy, and this Bricker Bot would actually try to access your device and delete all the block devices it finds. It will take great, well, it will try to make the device unavailable, so, and it will reboot it, so it's just offline. You can't access it anymore. You can't easily refresh it, so you basically, well, non-technical people would basically throw it away, and these bots killed about two million devices. Yeah, there have been the very big attacks in 2016, and yeah, some of some IT people were really shocked about this, so they decided to do something about it. So, if you're attacked by UDP and char again, it's just, you connect there, and it just send a random characters to you for testing purposes, and there's also this UDP service called Echo. It just echoes everything back, so if you get attacked by this, you can connect the two attackers, and they can attack each other, okay? Of course, when you get attacked, you can try to find a malware sample, you can find the command and control center, and just kill it, so, like I said, if you have 50 gigabits outgoing traffic, well, in theory you could even rent some servers and just use it to kill it. This was actually used against Mirai, and yeah, this is very effective, of course. Well, okay, and now a little bit less aggressive. Well, I have Twitter, if Anonymous announces an attack on our website, clearly I'm going to see this, so I'll get access to the tools because they say, hey, use this and that tool, at this and that time, so I exactly know when they're going to hit, I exactly know what tool they're going to use, it's usually very easy to analyze and block this kind of thing. There's also the OpenResolver project. This is an initiative to mail people or to mail providers that are hosting OpenResolvers or other open DNS servers, for example, the NTP servers, and just to notify them that they should close those. You can also do automated horse lookups, you can do automated mailings, contact the ISP, contact the upstream, and for example, if you get attacked by 100,000 WordPress instances, you could just hand over the data to a cert and let them handle it, yeah, they will try to contact the owners, they will try to fix this. Well, sometimes it's required by law to hand over locks, so if people take part in a layer seven attack from their home internet connection, that's not a very wise thing to do, please don't do this. Okay, and finally, something about what happens when you're in the news, when you're getting DDoS'd. Well, we were in the news and we received continuous marketing calls. You should at least have some idea what to tell the media, it's not a good thing to say we're not commenting on this because then they will make something up. Lots of shady anti-DDoS providers called us and of course, everyone is promising, yeah, of course, we can help you, we can fix everything we've seen with this other provider that one of our customers used that this is not true, and there's also some kind of ransom DDoS, so sometimes we had a call or we had a short DDoS for a few minutes and then we had a call from one of these shady providers that said, oh, I just tried to access your website and saw it was unavailable again. Hmm, maybe you could work with us and then this won't happen again, so yeah, it's a bit weird, timing is weird sometimes. Okay, what's next for the following years? Well, people get more and more banned with, we'll see larger volume attacks, I guess, also larger layer seven volume attacks and we'll of course have more IoT trouble. And that's it, thank you, okay. So, thank you very much, we have time for questions. Yes, yeah, please use the mic. Thank you very much for the presentation. I'm very interested in peer-to-peer networks and the problem with these is that they're probably often very open, so they accept a lot of messages. And these systems use different methods also to try to mitigate too much network coming in like proof of work in a Bitcoin network. Do you think that it's only possible to do something at this highest layer, which might be very ineffective or do you think there's in like very open peer-to-peer network in which anybody can send the message to this public place to share information that there might be other ways to mitigate this? Okay, yeah, it's a little bit of a problem because you want to be open and if you have a very complex way or a very complex proof of work that you need to do in order to take every message, right? Yeah, you would have to check a lot. I don't think this is easily solvable. Okay, because it's interesting, like in the past eight years I don't know if this is true, but I don't think there has been a big DDoS attack at the Bitcoin network. So that's a good sign, hopefully. Well, the Bitcoin network gets also attacked. They don't attack the block cipher and the blockchain directly, but I think the network still gets attacked sometimes. Okay, thanks. More questions. We have plenty of time. Please. Yeah, thanks for the talk, very interesting. You were mentioning a number of games, like the TCP games or they have seven games that looks to me like this tar pitting in email where you try to stop spam senders with crappy client side implementation. Isn't that just a matter of time until attackers also implement whatever game you like to play? So isn't just that buying some, just a little time until they keep up with that? It depends. For the layer four attacks, for example with the TCP with the RST packet or the out of soon, this is a kind of method to authenticate a client. So just to make sure it's not a spoofed connection. So afterwards, if the client answers in a certain way or reestablishes the connection, then you know it's a valid client and not a spoofed TCP IP packet. Okay. So this still works, but for the layer seven, yeah, like I mentioned, and also with this DevCon talk, yeah, sure, it's circumventable, yeah. All right, thank you very much. Any more questions? Well, oh yeah, something in addition. If you have a very high skilled attacker that has a botnet, well, it's really, really hard to block this. The simple attacks or rented attacks are usually easy to block, I would say, but a high skilled attacker will be a lot of trouble. Okay. Please go to the mic. Thank you for your talk. The question is this. Yeah, this is a bit analogous to the stopping of spam and email. And there also is some kind of a weapons race from like the gray listing. You connect me again, and then it worked for me for a few years and then they start to recognize this and they come again after an hour and they go through. That's something like you have in slide 43 with this intermediate stage. The only way to really make sure that the attacker is not hitting you too often is to make it cost money. Because there are the ideas that email, if you let email cost money, it simply sticks more expensive to send you so many emails. And the idea you had with the client puzzle is a kind of charging money, if I understood that correctly. Because he has to do some work and that's work costs him time and does money. So he cannot do that for every person he tries to attack. Now the idea is this. Could you make up some kind of a blockchain technology for this so that every time you have a connection there's some payment to be done so that it's hard to have so many connections. Well, if you have a blockchain for this, then do you want to set up a peer to peer network that everyone has to take part in? Like this would be a very specialized technology you have to use. So, but with this, if you implement a puzzle in JavaScript, every browser can solve it. So you don't need additional software or anything. So I think this is a method that's working. I don't think a blockchain will tell you. It's not that you can do it tomorrow, but it's like, you know, we never solved the problem for email, how to make cost money or virtual money. Therefore, it's never implemented. But if you have a kind of special service that you only provide to that many clients, you can say, okay, I do not want to see the others at all. So these clients will pay and the rest will not be allowed to connect. Was it possible or is it not possible? I don't think it's possible in a way you're thinking about it. Okay, thanks. Can you ask in front of the microphone, please? This is for the recording. Hi, just a quick note. You have initiatives like 21.co that try to implement at least this idea or this vision. Not saying it's very effective, but there you have to pay them money and once they receive Bitcoin and their accounts, they redirect your message to your preferred account. Okay, well, this is extra software you need to use. Like my grandma, if she wants to access my website, for example, then this won't help at all. I have one more question I'm asking for a friend. Do you have an overview over the DDoS market, so to say, who's making more money? The attackers or the defenders? I think the defenders, like if you have a very big provider, let's say Cloudflare, well, they get paid by all of their clients all the time. And usually if an attacker sees all they're using Cloudflare, he already knows that it will be really hard to attack them. And I think often they just, they don't even try. I think there's lots of money in the anti-DDoS market. Okay, and the defenders, I mean, they profit from the existing of the attackers. If there would be no attackers, there's no need for the defenders. Do you see a lot of, I mean, you've talked about the shady DDoS providers, but is it reasonable to assume that there's a certain connection between attackers and defenders to just raise the bar more and more for both sides to make more out of it? Well, I wouldn't say that for the professional ones. I wouldn't expect any of these to do something, but with the shady providers, I'm pretty sure, yeah. For example, if you read up on Brian Kreep's blog about Mirai and the articles, there's some, well, weird stuff going on. For example, some provider that was being attacked all the time, that was hosting Minecraft servers. Also the big attack against OVH was a Minecraft server. So there's a market for Minecraft stuff. And if, well, if you're hosting a Minecraft server and it gets attacked all the time at this provider and then someone says, well, I'm hosting mine at the other provider and then they can defend me, that might be an incentive to move over too. So there's some stuff going on there, I guess. Okay, all right, thank you. I have a question, I think it's illegal also, but what about the good clients to have like a JavaScript to strike back to the badass people? Oh, yeah, that's a funny idea, actually. Yeah, that could work, but it's totally illegal, of course, yeah. One concern that I have with Cloudflare, their free option is, well, the paranoiac within me thinks, well, if you don't buy your product, you are the product. So how do they get this for free? I'm thinking, well, do they sell your data off to some government organization or company or whatever, do you know about this? I don't think they sell any data because it would ruin their business completely, but, well, of course, when you join them, you want to set up in a certain way and maybe at some point you want to have better visibility for your log files. Well, the free version they have is very limited. You can't do certain things, like I think some kind of redirects. I'm not sure if, well, SSL is included now, but I think it's just like, it's the first free shot of heroin to the addict, right? And then you notice, oh, this is really cool and really helps keeping my website online, but I want this tiny little feature and it's just 50 bucks per month, so I'll enable it. So it's just to make it easy to use and just make the transition easy.  Okay, so you have concern that they, well, like, for example, here's only the past or other organizations have some deal with three letter organizations or whatever. Well, it's Cloudflare, they're based in the US and you have to decide for yourself what you do. Thanks. Yeah, another thing about this, well, if you're hosting a website, it's intended to be online, of course. Well, yeah, they could analyze the logs, for example, who's accessing what, maybe that's interesting, but yeah, decide for yourself. Any more questions? We still have time, all right. So then I will close the session. Thank you very much, Greg, for this wonderful talk. Thanks.