Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!

Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!




======================================================================






Hi, thank you. So as I said today, we'll learn about those, but not about what it is, because that's something that you all should know about. But we actually do this from the defenders side. Mostly we hear about it on the news or the media or whatever some Apte guys did indeed, or some viruses, some botnet. But we always hear just one side of the of the border, the defenders. Now, we learned today about mitigation of the dose or more specifically, how not to mitigate those. First of all, we doesn't walk. OK, excuse me. So first of all, we got some intro into details, what is this? What it is all about, something boring, just one slide about it, methodology of work, of our method of delivering this kind of service. We are actually we've been attacking now for three years. We added services to our customers that want to test our systems for this as mitigation or correctives mitigation. And guess what? Not all of them were so correct, as we figured out before afterwards, we talked about some ideas in the wild, what is exactly going on in the world, just some statistics against something boring. And then we've come to the ten most common from the book strategies that we figure that you should hear about at the end. Will will have some kind, of course. So myself. Etzioni I do security stuff. I know I'm managing a team of security researchers at Verint. We do something cool with defense, but except that mainly I'm experienced with penetration testing and ethical hacking. And for, as I said, from the from three years of hard work about details, we are attacking and providing our customers a service of those attacks. That's the end of the shameless promotion slide. I will never you will never hear about it again. So everyone gets visas, not in the correct sense of the word, because everyone meaning you, if you are an attacker, you will then maybe I hope that you will learn one or two tactics that you didn't know before. If you're a defender, you know what not to do or what
 is what are the most top 10 top top ten common strategies not not to do or to avoid from. And if you are neither an attacker or defender, you just kick back, relax and hear some good laughs over someone else. So the method, the method of delivery is somewhat complex because we want to have control over our botnet. We have a legitimate botnet. Of course, everything that I will mention here is legitimate and we are doing it as as legit as we can. We are we have our own botnet, a pretty vast botnet all over the world, all over the globe. And the living this kind of controlled mechanisms for those for us, for our customers have some extra edges like we view exactly what is happening. We log all the stuff. This is pretty hard to do actually, when we are talking about botnet with thousands of computers that we want to control each one of them and know what exactly we are missing. And on top of that, we have something, something more like a red team and a blue team. So the blue team is is incorrectly named blue, but you can see spoke with a blue T-shirt. So the blue team is is on site with the customer and viewing all the logs, not for mitigation, not for telling him what to do, just for taking notes for the red team. And the red team is is on the other side of the line attacking the customer with the with the botnet and together with the two spox. We have a complete image of what exactly is happening on the network or maybe in the computers of the of the customer. And through that, we can we can have a good recommendation, logistical recommendation. We know the site. We know exactly what happened. We can pinpoint it. We can we can analyze it. We can analyze our own botnet in terms of improvement if you want to improve it for the next time. So together, we have this visualization of the analysis and we can progress with the attack. Moreover, some in the world leaders use mainly maybe it's a shock for most of you, but mainly by science, most of the attacks are less than tw
o gigabit per second. I mentioning that just to acknowledge that Deeds does not have to be so large as the media claims it claims to be. Of course, there are times that network bandwidth is the main main type of things. But if we hear about some details in the media, it doesn't mean that automatically it leaders by bandwidth by the network. We'll get to it later. Other than that, we have reflection amplification. This are two wars that we hear a lot. Reflection is the actual act of benefiting from a third party that we want to we want to communicate with. And the third party is communicating and reflecting the so to say to the actual site that we want to attack amplification is using some kind of asymmetric protocol or asymmetric behavior between the attackers and the defenders of the service. So the servers will have to work much harder in order to accomplish something. And that's amplification. Last most attacks that we hear about on the Internet and on the media does not require brains. You can leave your brain out and then just attack with some some kind of a tool. And because of that, most of them rely heavily on bandwidth consumption. My point here is that you don't have to be that lame. You can't you don't you don't require most of the like 90 percent of your brain, but you need a small fraction of it in order to to designate and amplify your attack without actually using so much bandwidth as proposed. So. Just just some headlines, headlines, as I mentioned, there is more than a front end will come together. We come to it at least once in the examples. But everyone is thinking of websites that's going down by diddles, by some kind of log into a bank or maybe the double double W's site for the bank. But it's not exactly if you can attack the back end and we will get it. Other than that, you have you have the the back end walk for you. The back end is actually doing something, not just presenting a cached page or something so you can actually amplify your attac
k by the back end. Keep it stealthy. They might be listening. The magic of sniffing. We all have heard about it. The sock team, the sock manager is online and checking his site all the time. He's there with the magic of sniffing and think of amplification in a general way. When I'm when I'm saying stealthy, I mean that use your own tools. Most of the attacks that you hear about and read or maybe even even if you have the source code for it, you can read the source code and then analyze by yourself what the attack does. And attacks are mainly these attacks are mainly very simple to comprehend because, you know, the small fraction in the distribution of the attack in order to complete it. So if you know what you're doing, you can easily believe me very easily write your own scripts. And by that you eliminate 90 percent of the signatures that are residing on idiocies and antidotes machines. So amplification on the general term, we refer to it as four pillars. We have the network attack that the usual suspect. We have the C.P.U, which is very limited in some some cases. And C.P.U was actually attacked by someone on 2083 three, which I forgot his name because it's not my native language. But some very professional guys devise a effective attack over C.P.U, presenting a single aget or post request to an HTP server and then evaluating the CPU up onto ninety nine percent of the system by using hashes. So C.P.U is again a very prominent attack that we choose to attack in the process. The other thing that we choose to attack mainly is the memory, memory, volatile memory. Everyone use it, everything uses volatile memory and we can use it to our advantage. Think of it everything that is done on the website. If you have, let's say, a form and the form is undergoing some kind of a multi-stage, you can actually do maybe part of the stages, maybe all the stages. And in memory, residents will be very effective indeed of. And last is the story itself, you have a some amount of storag
e on disk storage and even the IO buffer of the drives that are working very hard to complete the mission. OK, so last this is a true story. At the request of the survivors, the names have been changed, will never do shaming to any of our customers. You know what comes next out of respect for the dead, the rest of the rest have been left unchanged. OK, so very. Set the actual result as facepalm, so every one of these of the these stories will be presented by a facepalm ratio, will have a scale facepalm. You'll see it. And did I mention at the end and the number one, we go ten to one. Number one, I can promise you that all of you will do an epic facepalm. That's a promise. OK. Very. Number 10, number 10 was common. Actually, it's it's less common nowadays because everyone knows that mainly everyone network guys knows that that's rubbish. Limit the rate of incoming Puckett's. That's something that is meant magic for network people to say, yeah, yeah, yeah. We have Adidas like two gigabits of men with oh, no problem. We have one megabit megabit of bandwidth. So let's use only one megabit of bandwidth to upload. Then this way we can't even choke the bend the rest of the ninety nine megabits per second. So of course you are nodding all of you. I see the heads if you have an incoming package coming at you and this doesn't work and that's why the customer had to do this actually. And that's why he asked the ISP to ISP, told him please, please rate the limiting, limit the incoming packets into your service. That was the ISP talking. And so we did. And he believed that he is sufficiently mitigating the attack if we test him. And he requested the test. So we delivered and it was pretty simple liver, because if you have the knowledge of how the Internet works, so you have a get request or you have let's say I get requests, I get requests, something pretty easy in size, like, let's say level one killer bit or maybe one kilobyte, let's say. And you request a file from the server
. If the file is sufficiently large, you have, let's say, one megabyte of a file. You can go with the list, by the way. You can go with two hundred kilobytes. It will be an amplification factor of 200 times more. Think about it. So now we can use the minimum amount of data that we want. We want to upload in terms of and then get it from the download itself, meaning that effectively the servers are choking themselves. So the beauty of this, this tactic is that will work always, not only when someone will try to mitigate you. So the mitigation is, of course, Fagel, but say that the consumption by reflexion. But it's an implied facepalm, something that you all should know and say, OK, that's something stupid to begin with. So maybe it shouldn't be on this scale at all. So does Tommy Lee Jones. Number nine. That's that's a beauty. We have a vendor that monitoring the sites all the time, or maybe not the vendors itself, maybe the SOC in this case, in this story, as I said through a story, the monitoring was done by a third party. That was the only job was to monitor the site. Now, when you monitor anything you you come to after 20 minutes of an attention, your attention drifts away. And the thing about puppies or about your babies or about your friends or about I know what you ate for lunch and then you forget about monitoring because monitoring tends to be something very, very, very boring to do. So you look at a graph and if everything is OK, you live it as as this is it. But in this case, we didn't live it as as as I presented it. We actually we attacked the site and the site was down. Now, when was when the site was down, it was a surprise attack, meaning that the the the men that started the test was the was the security officer for this customer, for this organization. And he didn't let let know of the idea and the third party that is doing this kind of test. So when the site was down and you see this site is down, you don't have to be an expert to see that. And an
d then you just waited and waited and waited some more. Now you will ask yourself, wait a second, maybe an email, maybe a phone, maybe someone will pick up the line and say to I.T. or say to the stock, listen, guys, we have a problem, but no one did. Why? So? So because two things. It was pretty, pretty quiet. No one called it in. And we'll figure out why in a second. No one call it no one got an email about it. And the monitoring vendor wasn't aware of anything going wrong on the network. So what what what what went wrong exactly. So first of all, the vendor saw, as I said, the logging system and the logging system. And the logging system was looking a bit like that, you have a pic, you have something like a bot, the the I don't know about the colors, but the most of it are are susceptible as botnet. And it's it's in a relaxation somewhere. So first of all, that's the screenshots that when the security officer called the vendor and ask say, guys, do you see this site is everything is OK, so it's safe to him and send him the screenshot. That's the actual screenshot from the vendor. So everything looks, I don't know, suspicious. But let's say it's relaxed after this. Let's say that the problem is that, A, they didn't check the site actively. They all they needed to do is just click on the on their browser, apparently Internet Explorer, and then go to the site. And if you go to the site, you see the site is down. You don't have to be an expert or a soccer team to see the site is down. So they didn't do exactly that. Now, for this for the second question, why doesn't the IOC got any calls or emails? Because and that's in addition to this epic fail, the actual the bandwidth that's used for the banks servers. This customer service was used for the HQ traffic inside the corporate. So everyone that wanted to serve at the time, I'm talking about hours of of of no surfing and of no email for the corporate sites. No one could email and no one can can use the VoIP phones on th
e. So that'll be the fun and this kind of facepalm is having a face bomb is another rather that's easy and it's cute, right? Ah, OK. Going and going to number eight. OK, so I've mentioned it before back and servers are not important to be protected against leaders. Again, a very safe assumption we have to consider the heavily backend servers are not important, eh, eh, that's bullshit. And servers are always important. If you think that any servers are not important and don't use those servers, that's backup. So if. So if those servers are not are not needed to be protected against those, so they are somewhere and this notion of thinking was coming from the media, I guess. So everyone is reading about this kind of let's say, for example, supposedly Bank of America was attacked by Dido's. And the first thing that you hear about is everyone is tweeting about the login site for this bank. Why is not responding? So the media is responding accordingly. She's right. Login site for the site is down. Oh, man. But actually, what can happen is, is something much more vast than that. But you won't know it unless you are seeking the stock and know exactly what what went wrong. And maybe it is maybe most of the attacks do actually hit the front end. But it doesn't mean by that that the backend not unimportant. So in this case, we try to map the site, we as attackers want to tackle the back because of this notion, we want to attack it and want to know what to do, how to designate some kind of a backend server. So actually, that's easy because I don't know about easy that actually, but it's very common for us to do when when you check a black box site, you just go to a site and try to assume what is going on under under the covers and see what exactly is happening. But you can't really see because you're not a developer, you're just testing the site as a as a hacker, a penetration test. Now, when you decide to try to figure out where is the database, what is going on, and that's th
at's pretty easy. If you get a query for somewhere, some search supposedly is and ask you out and ask your server or anything like that, maybe a file even, but it is a data set. You can query it. You can you can do some work on it. And that's why this notion is pretty bad. So the conservers oh, excuse me. Some problems there, maybe someone is using me now. OK, so in this case, we have like to guess something and that's a pretty easy guess. If you have delays, if you have inappropriate delays between searches or between forms, you can assume that something is going on at the back and not in the front. And the front end doesn't think hard about something. That's the whole point. So if the site is thinking hard about something, that's the back end. So you hit gold and you profit from it when you do need us. And this facepalm. Is a kitten because you have to be a kitten to do that. That's so nice of you. OK, number seven, we had actually a pretty good customer in terms of relationships. And he really respected our work that we did with one of our leaders, and then he called us again, but this time he bought a shiny new box and this shiny new box cost a fortune, of course, but any any box does. And when you buy a very, very pricey box, you may be connected to all of your service. We said before that the backend servers are as important as the front end. So protect other domains, connect all your sites to it, connect to your corporate machines, your ionno, maybe your bank. I don't know everything that that he could figure out how you connected to this box. Now you can say to yourself, so what's the problem? So we get some extra stuff on that. What is really getting is protection from us against all of those domains. And when we did it, when we did the actual test, we tried to figure out what is the box is supposed to do. Now, we didn't have some issues of this new box that we didn't know before. It's name has to be, to be honest. And so the mitigation is pretty, pretty un
ique. They have like the strategy of of the the strategy of it is like thinking about what is going wrong. The box is just sitting there for 20 seconds when it suspects something and after 20 seconds after we suppose it's building some kind of a model for the attack and then it tries automatically to figure out how to deflect the attack. This this mechanism is usually preceded by something called draining of the lines. When you have all the lines that are susceptible, you just drain all the lines. You just drop it all and then wait for new lines. And then by the model that you built, the box can decide what is going what is going in and what is not going on. So when we try to attack it, we were we were very scary because always before the attack, before attacking the site, we we gather information about something. We try to assess what exactly is happening in mostly the customer does not need to respond to anything. We do not intrusively and try to figure out the technological benefits and technological traps that we want to overcome. So in this case, we just read the brochures and try to figure out some strategic spasticity the defenders could do and try to circumvent it. So we didn't have something really good, let's say, to be honest, when we started to attack. But exactly twenty seconds, twenty one seconds later, all the site went down from all of the old. Not only that, six minutes later, the guys from the blue team gets a call. Listen, guys, you have to stop the attack. Right now someone is very angry. Why? What is happening? You knew that this stuff is going on. We just. We just shut it off. It's OK. We take about two minutes to shut off and attack and started if we want to. So two minutes. Let's let's let's wait a bit. It took about one and a half minutes and then the attack attack was gone, but none of the servers was responsive. So so apparently they were very, very stressed about it, I guess. Not only that, you said you thought that at the end of the line
, not only that, is that not only the mean that we we thought that we are attacking was down. All the corporate network was down, of course, because all the main was was covered by the box and because of the behavior of this kind of shutdown, the complete shutdown of most of the computers that they are involved with, the Internet traffic, some back very back and let's say second to back end of the corporate side, it was trying to communicate to something very crucial to them without explaining exactly what. But let's say some something went very wrong on the corporate side and they lost some some hefty money about it when they were dealing with transactions. So that was pretty embarrassing. And you can figure out exactly what happened when the box was seeing all of it. By the way, I didn't mention monitoring. The monitoring itself was shut down because it was connected to the box. So everything went dark in a second and everyone was stressed, the phones were orange voice over IP, so they they were PSTN or dials and then they each other and said, OK, guys, let's stop it. And we stopped. And then I think it took like seven hours of actual mitigation, actual try to bring back the service to normal operation. This facepalm is like that. OK, No.6, that's a good one. I love it. It happens all the time, by the way. It's not. It's pretty common to encounter nowadays when you have many vendors that provide some kind of a cloud based dust mitigation. We don't trust the vendor. And that's what they are saying all the time. We don't give them certificates shamefully. That's what happens when when you rely on third parties that you don't really know. It's not nothing like the big five ional providers that provide some kind of a box or maybe cloud based mitigation. But you go with something, maybe a startup, maybe something in in its youth when you want to support them. And maybe it gives you for for free. Doesn't matter what, but it gives you some kind of another layer of securi
ty when talking about. So this kind of defense is is pretty awesome for us because if we know that this kind of operation is going on or we can assume because of the nature of the relationship with a vendor, we can say, OK, so https is not covert. So you go with steps and when we go it steps it it becomes even even better because you see, the hackers choice did a terrific research on renegotiation for SSL and renegotiation. SSL was approved by them to be so effective like 15 times more for the c.p.u of the server, harder that are harder than your own walk when you when you try to push your computer to the most. And it can be actually pretty, pretty simple to employ you with only two computers. But if we're talking about a very large you to do computers will not be enough. You need like 100. So if renegotiation is is present, we'll talk. We'll we'll attack with renegotiation and it will be done. It's really hard to counter this kind of thing unless you have https and you know what exactly is going on on the line and you can read it. And the second thing that not only the vendor can protect you, you can't see anything because you are not actually processing the data. Now, you can say and you will be right that you don't want to anyone else to see your data. Right. But the thing is my point is, if you are not trusting a security vendor, don't work with him. That's a that's a pretty simple advice. And that's fixable. They the first one is the walking with a security window that you don't trust, the second one is the visibility that you don't give yourself if https is not actually terminated by anyone. OK. We need big data. Collectors'. It wasn't just rank of some order. So we need big data. That's a big world, I don't know if you heard about it before. But big data is going to be a trend, I tell you. So we need the big data. Let's collected all like documents. We have big data. We have this we have this netballer device. We have this network división. And we want to co
llect it all. So that's great for you. But when you collect it all, you have one big problem. That's storage space. And let's be honest, some protocols like PCI tells you to save all the data. That's something that you have to do. So maybe it's not it's not only that you are wrong with their assumption of just collect the data, don't do anything with it, just collect it responsibly. And when it doesn't happen responsively, you have logs and overcoming some storage boom and Silow needed. The result in a complete lockdown. You don't have to do what you can do anything on the servers, it's very hard to operate without, let's say, Fourcade, for minimum, if you need something from the from the disk and maybe the IO itself is breaking down. But the most susceptible to those attacks are not servers themselves because servers can be cycled through their logs and most of the network guys knows how to do that. And infrastructure guys. But something that is overlooked many times is the networks and network switches and ideas, IP as firewall as well, and maybe the A.D.s mitigation machine that you have, or maybe the VPN. And in this case that I want to mention, it was the ISPs, the ISPs. I live the vendor, of course, alone. But the ISPs wasn't cycling through its logs and it over it, it got the storage boom and then it just disconnected the whole site. So even when they wanted to mitigate the attack, they couldn't because the ISPs was down and because the IP was down. No network can be reached to the site itself and they couldn't connect to the ISPs because there was no storage room on the IP. So they couldn't fix the problem and they needed to get to some bunker and press the button. I think the correct button. And that's a facepalm that is done by a third party. Number four. We are under attack and forced the OnDemand scrubbing service, first of all, there is no such thing. I don't know if you heard about it, but OnDemand scrubbing service, scrubbing service is something they
 need to learn about your traffic. You need to know what exactly to scrub unless you want to teach them. And that's pretty much impossible if you are talking about a dynamic changing site. But let's leave it. Let's say there is such a thing like OnDemand scribing service. In this case, we have learning mode, learning mode, something very beautiful that lets you just switch switch off this kind of responsibility or this kind of mitigation and just switch it on when when you want to mitigation to be actually occurring. Now, in this case, we had it was in Australia and it was an Australian customer and it's not his fault. And he used some kind of a OnDemand scribing service, such as say, and the attack was legitimate traffic. If you actually know how legitimate traffic looks like, you can mimic it pretty easily. If you use your own tools with other more robust tools, you can do that in a good way. And last, you have to read the manual. Please do. And they read the manual and and discovered that the manual itself of the vendor said that's no, no problem. We can learn on demand. I don't I don't really familiar I'm not familiar with with this notion, but let's say it's possible and we'll live it four minutes from now when the response was epic. Now, the story went like this. We had the the side of the customer. We actually attacked it. And then it was pretty OK, the we try to to make wrap up a ramp up of the attack so we can analyze what exactly is going on. So we wrapped up them, wrapped up to remember that. And then when we reach some kind of a limit, we said, OK, it looks fine. Do you want us to continue with the ramp up? And he said, no, I want to test the On-Demand streaming service. And in the second that he switched on the on demand service, I was all was shot and nothing can be accessed. And it was pretty impressive because not only that, it does like that he didn't have any kind of control over it. He can switch it off. You can you can maybe try to DNS the incide
nt. He tried to call the vendor and now usually we do it overnight because we want we don't want to hurt customers that are actually using the site. True. This is harmful to us because we want to actually mimic a true and not off-peak, but but on peak hours when we want to actually attack during Christmastime, I say but in this case, of course, it was a large customer that didn't want to actually hurt the customers. So that's negligible. So he picked up the phone and called the vendor. The vendor has a twenty four seven hour someone that is picking up the phone, that someone picked up the phone and looked and and heard about. He he was going on like someone that actually woke up from sleep. We would imagine that you were if you didn't have any kind of communication with him except his voice. So he said to the vendor, listen, I have I have to have your help. My site is down. We are six hours to, uh, to, uh, to actually the mall. We six hours for morning. And when the morning comes, the customer will try to to exercise and no one can currently. No one can. But it's again, it's it's controlled. So the vendor says, wait a second, I have to consult with someone. He consulted with someone and in half an hour passed. And then he called back to him and said, OK, OK, we'll we'll try to figure it out another hour. And then the unstrapping service was down. But the aptness about this is the answer, the complete answer of the vendor. The vendor said when when they were asked, why didn't you actually told us that we want we need to calibrate the, uh, the I know describing service that that was the the thing that he said. He said another thing next time by our service of calibrating your site. That's a good friend. And that's. A triple facepalm, why a triple, because Fehling had protection working with a vendor and the pool vendors answer. We are approaching number one, number three, so what Sydney's is not dynamic, let's enable its citizens is the distribution network is pretty 
popular nowadays in protecting against those. And that's pretty cool because it actually works if you have a spread out a city and you can actually mitigate network based, maybe even other other based attacks to your system. That's cool, right? But Sydney, as a culture, it's called static and dynamic and it's usually marketing, but most of the citizens are static. Static means that it can pull off some requests for your site from static data, not something like searchable queries and stuff. And then you can you can cache those data, those data, this data on the CDN and via that other customers can benefit from the no lag at all from the sit in. Now, when a citizen tells you that it's not dynamic's, which is good, which you should know about, and you use your site, which is dynamic on this CDN, it can be very, very devastating. Now why? Because the thing is that it works like that. If you have a citizen and a citizen is is getting a request from an attacker or just just a regular user, it asks for some kind of a landing page. Let's say if the landing page is on is was visited by someone else in the vicinity of the and it will know how to respond and then respond from its own cache. If it's not was if it wasn't asked by someone at that a given time, it will ask itself. It was a request for the origin. The origin is the actual domain that no one should access except the city. And it will ask the origin about this request. Get it back and then get back. Get back to the to the customer, to the user. And attack tracker will do the same. But that does not know. We'll get to it in a second. Does not know where the origin is and how to ask it directly. You need to ask the citizen about something in the DNS that the NSA is issuing is giving him the closer to the end that he can need to think about when he's talking about the site. So in this case, we have an origin that is getting so many requests. So that's wrong if you're using dynamic. The thing is that dynamic is pretty e
asy to deduce because if it's not dynamic, say the end, meaning that he will need to issue each and every one of the requests if it's a different parameter or value for those for those parameters, it will need to issue each and every one of that. All we need to do is just requesting from the see the end data with parameters that didn't know the same page, other parameters, sometimes even parameters that doesn't exist in the site. But it doesn't matter. He will issue a command and issue a request for the site because it doesn't know the correct you URL for that and it doesn't have it on cache. So one of our customers did exactly that user sedan on a dynamic site and we easily they just deduces machine. And other thing about citizens, which is not exclusively for dynamic but for dynamics, is much more devastating, is that if you monitor your origin, many of the citizens does not give you actual uses for monitoring like traffic, like did you have your own machine and you monitor that as good as you can and maybe some some kind of tools that you get from the vendor of the sedan. And actually, when you try to mitigate it on your sites, you actually many times can't because you can see the actual attacker and you can't blacklist the attacker or something. You just see request from the citizen. And if you block the city in itself, that's good for us. OK, and that's deserve a distributed collage of facepalm. Number two, again, city is pretty exciting for me because no one knows how to protect students. And when someone searches the Web in this case, some obscure site name, Google will use it for finding how to protect protected in origin. That's the best phrasing that we can. We could walk out and the the first one after the one, which is advertisement, you have the how to protect your city in origin. So let's click on that what you say. OK, we clicked on that and that's magic. And then we have several recommendations how to mitigate and how to protect your city and your ci
tizens origin. And just magnified for you, this is a simple trick and it is also the best solution, create some random long set of alphabetic characters and use that as a subdomain even more. So can it be guessed? Yes, but highly unlikely. Can it be linked? Yes, but again, highly unlikely. There was much rejoicing reading those lines. Why so? Let's talk about it. So the tactic is like that find other subdomains dance that translated to Ipis scared the hell out of it. It's a serious sless, 20 for 16. Good, good chances, but it's not bulletproof. You can you can actually miss a lot of of those origins from the actual name. But something that is much more probable to find out is the who is this? Who is Elvis never forgets means it is forgetting because who is this dynamic? But you have who is history's online and you can check who is history or history domains. And then when you check it, you figure out and we figure it out in this case that the if we want to solve some of our customers actually but this kind of service and try to protect against it and we figure out how we can know what is the origin, who wanted to attack the original. Everything is static. It's pretty hard to to attack static sites unless we have a subdomain or unless we have another origin that we know that will will be hurt by that by our attack. And we can just attack some some obscure subdomain. We need to know what we are attacking to some extent. Of course, because of the backend that doesn't really determinists isn't really deterministic all the time, so we never forget. So we look online. In this case, I'm just giving an example for a malicious infected site named Big Dot Com. And this site is covered with who is history that you can pull off from View DNS in this case. But there are many other services for who is Esrey. And then we actually thought about it when you bastardy and you don't actually change at the last IP of your site, you just giving it out to the actual content provider. And 
then if you look up the who is history the last one or maybe one or one before that, you actually hit the jackpot because this is the IP of the origin. And that's exactly what we did. And that's exactly what happened when the site went down and the customer said to us that he doesn't see anything on the Syrian. That's around. No one. OK, that's something personal because in this case, the again, the the actual the actual person that bought the service from us was the security officer of the organization, a big organization in Israel in this case. And this organization was very, let's say, politically savvy. So it was very vicious in their attempts to block the attack. So as I said during this week of research before the attack, which is nonintrusive, we try to figure out how the mitigation works from low, low impact attacks and stuff without actually impacting anything. We try to figure out what is going on. And we saw that the mitigation that they they invented was amazing. Like we have one server and we are taken from this server. And that's and from this on, the blacklist is not following just on on our servers, but all of our servers worldwide or just a branch of our service in some place in for instance, in this example in the United States. And we try to figure out why. Why is that? If you are taking from one source, how come you can mitigate all the sources from this area and the the susceptible answer? And in this case, the correct answer was that the mitigation walked like that. If you see an IP, if the sea rises up and alert and then an IP is raised, then it doesn't block only the IP. Remember, he wants to block us, not an attacker. And he knows that we are limited with our with our resources because because, as I said, we are legitimate as possible. So when he tried to mitigate us, he said to himself, OK, you have some botnet that released or bought somewhere and that this will be some kind of a cluster of vipers, which was correct in this case. Most of o
ur servers do like that. So it didn't just block us. He blocked the whole 16 site. I'm hoping that you are not cheering for him because. So, for example, in Germany, you have like one hundred sixteen million IDPs in Israel. It's much, much smaller, but you can extrapolate. So if you have 160 million IDPs, you have about roughly, of course, one hundred thousand eight hundred class ranges. Right. So if we have only hundred IDPs that we need to hit and we can, let's say, spoof the scene, we can actually block all of the customers nation if the nation is deplorable, customer in this case, insurance is Proval to to come from customers from this nation. And in this case, Israel, as I said, is very small. And so we told them a bit so. So think of a monkey just typing high fees like crazy, and then it just blocks on the nation by itself and he can do anything about it because 50 minutes after after the the actual attacks have started, it's inflicted by all the nation. And before the 15 minutes of light, like half the time of that, he blocked himself so he couldn't see the. And now you can see why it's my favorite. Now, remember what I told you about the mega fund that will give me remember? So that's the one. But I don't see you face palming, so I brought my own picture. And actually, I think it's kind of a tradition, so if you may find yourself for a second. That's OK, right? Right, let's say it's OK. OK, so I thought about it, maybe the most important one is test. Don't be afraid to test. Many of our customers didn't know that such services is is in existence. And we are not the only one that providing this kind of service. We know. So there is no magic pill. You have to be an architect to understand that. It implies not only the front end of the place, all your network, all your computers, maybe even more than that, maybe your phones and emails. But test it and and you have all the money and all the toys. If you just deploy it without thinking, it will fail you. So pleas
e be responsible about it. And one less promise. If you wanna do that, you can be evaluated to this presentation in the future. Thank you. We now have about 10 minutes for Q&A. So, as always, police line up at the microphones or use the Internet to ask an ISP or Twitter. We have a person reading out your questions here. And if you leave, as always, please be very, very quiet because the talk is not over. It's going to go on for ten more minutes. So please be very quiet. Microphone. No, no, no. You're not hearing is not hearing. Any questions? OK, the Internet. You need to switch on the microphone. Should I ask my ISP before it does or not? Oh, that's so if they wanted us is included in the. So that's partly a legal question and partly a tactical question, let's say, for your sake of evaluating your security. I won't touch the legal sections because I'm not a lawyer. And for the legal section, you have to consult your law department if you have so if you have such a department department. For the other part, it depends on what is your focus on the testing. If you if you are focusing on testing the system as a whole, if you are looking at the army to get all the mitigation factors that you put into place, in my opinion, it's important not to notify the ISP if possible, but if it's not possible, of course. Notified. Microphone number three, please. Hey, so there are techniques that, for example, CloudFlare has this project called Railgun, where they def the websites and sort of not request the full website. I don't know really how they do it, but does this have any impact? Can you see this when you did? Does this help at all or is this just. Yeah, OK. This, um, usually we test with blackbox. It means like testing. We don't really know what exactly is happening on the other side except what what the blue team is being fed also or seeing by the customer. Such examples as CloudFlare and others are examples of of partly participating factors into the attacks and the testin
g, because they they didn't provide us with much of the explanation that we want to. Actually, I'm not talking about and not talking about CloudFlare, because actually we're not going to figure that we've never tested something with with CloudFlare in mind. Not not that I know of. It wasn't effective, actually. And let's say other vendors similar to CloudFlare has approached us and and usually put up some difficulties. I'm not talking about technical difficulties, more political difficulties. Let let me know when you are doing it with the legal stuff is not correct. You can do it and you have only ten minutes of time and something like that. So something like well done and similar is not employed by it. Haven't been employed in our testing yet. I hope it, uh, it answers your question. Microphone number two, please. How often do you find your customers were protected when you get there the first time? Let me let me put it that way. We are when we conducted tests. It is important to say that I'm not I'm not continuing these tests anymore. Like two months from now, I'm I'm off. When we conducted these tests, we actually did we took a length spend four to six hours from the customer. And through these four to six hours, we actually provided usually one one attack per hour. We tested some some kind of attack that we have in Stasch that we actually prepared before according to our research and evaluating by overnight. If we have whatever a number of attacks that we have a night like a real attacker will do. But on an on a very lengthy, a lengthy span, we have more than 95 percent of success. So most of the attacks, unfortunately, are not well protected. That that answers your question, yes, OK. And now the Internet plays. You said you just scanned the whole 20 for 16, even word IPV six, make it better. Think of a whole 56 and random IPS. That's quite something to scan. Yeah, this is good. This is great. But I am I'm not familiar with any bank that is working with us or an
y bank at all that is moving to IPV six as a whole is just using IP before and the IP is on top of that. Number three, please. So given that a lot of things are on shared infrastructure with Amazon and CloudFlare and stuff like that, how do you make sure that whatever you're detoxing doesn't cause any collateral damage with people who are just innocent bystanders? It does. It does. And it's probably if you're referring to to to not not customers of the front to to actually customers or clients of the customer. So, yeah, give it like someone on Amazon dossing like them for something and like something on Amazon GhostTown. OK, so should infrastructure as a whole is a whole different ballgame. We have to consult legal and the SLA with Amazon and Azure and others are pretty different from one another Azure that we do stuff if you let let them know in advance. Amazon, as far as I as I know of, doesn't let you do anything. It's pretty strict in terms of testing. Think about it. It's pretty massive not to test your own site, but again, it's considerable when you're thinking about the shared infrastructure, when you have Amazon or so others. So it depends on the on the host. And what what are the SLA with? Number one, please, so thank you for the nice talk, but can we change the rules? So I would like to to hear you a bit elaborating about what you would do if you have to run mission critical infrastructure and how you would protect it. I'm not a genius. So for starters, I won't presume that everything that I will say will be holy. It will be holy in another term. But I know that everything I will do, I will try to architect not just design and mitigation, architecture and mitigation and redundancy, as much as others know nowadays how to back up and how to help something, it's pretty much the same when you are talking about redundancy and things that need to be standing by and how much like the time that you can you have because this can occur. It doesn't. It isn't. There i
s no magic pill. As I said, nothing that I will provide you with, with a complete architecture will not be failsafe, but it will be epic, fail safe. And and and on top of that, test your systems any time you want, you can be the greatest developer. You will actually test your obligations. Right. So that's the same thing. If you architect something tested it to test. Thank you. OK. And once again, the Internet, please. Are there any particular solutions or products recommended or that are particularly bad? No. Number four, I'm home. So, first of all, the photo was not really appreciated. I mean, we're not here for your amusement or anything. It's it's kind of bad, Norm. And now moving on to the question, have you given any thought to to saturate the link without sending any package to the target? First of all, how to, like, legally do that and if you've ever had to do it or it was never necessary because the sites are done for other reasons. Let me put it again. If I if I understand correctly what your question is, how can you actually do some damage without going on and on and on with the traffic? Yeah. So you can be sending traffic to sites ipis actually that Syria link with your target so that your target does not observe any traffic and so that you do not actually do with any of them. But so I mean they do not get tons of traffic individually, but the whole link that they share will be saturated, which would be nice to have because then you could see how your path actually how resilient your path is to those attacks. I mean, it's been described in academia, but I don't know if you use it in practice. OK, we didn't we didn't do something like that before. Personally, I it's hard to think about something that we can deliver such an attack with without anything unless we have an exploit for that. Like like a like I said, 2083. There was an exploit exploiting many Web application servers through the hacking mechanism. But unless we have an exploit, a designated explo
it and we talked about generalized stuff, not exploits a pair of Web application servers, I don't think that's possible. But maybe it is in some in some situations when you have a database that is working very hard and crunching something and you can do pretty much the same, which is the equivalent of XPoint as an expert as I see it. Not exactly. So you're sending traffic to piece that they're not related to your target, except that they're being hosted in the same data center, say, oh, that you saturate the link, but your target doesn't seem to traffic. Oh, you mean so excuse me. You mean that another subdomain and through that is is impacting the actual one that I wouldn't call another IP. Yeah. It doesn't have to be related at all to your target. Yeah. That happened a lot and that happened a lot when we, when we got confirmation from the from the customer of course, to attack other domains just for a second to test if the infrastructure was shared for any means, you have to have some kind of a shared infrastructure, of course, maybe the same host, maybe, maybe it's networking on some sites. And the one example that I said about the shiny box, it was in the U.K., that's exactly exactly what what happened on the tier two back and the tier two was attacked. It wasn't our target, but it was attacked. So it is possible through other subdomains, by by definition in the. And unfortunately, we are out of time, so please, once again, thank Delmar's.