 Hello and welcome to Attacking and Defending Blockchain Notes, where we're going to learn about variety of risks and mitigations that we can implement to defend a very core component of the blockchain systems. We'll try to do a live discussion during the talk while we ask a question, so feel free to join DefCon's Discord on BCV General Text Channel and I'll try to ask questions and respond live. In case we haven't met, my name is Peter Kaszaginski. I'm a blockchain security engineer at Coinbase, where I spend most of my time breaking a variety of different blockchain systems and smart contracts. I'm also a writer for the Blockchain Thread Intelligence newsletter, where I try to cover all the latest news, events, hacks, scams in the blockchain security ecosystem. Last year you may have also participated in the Capture the Coin competition, which I helped organize. My background before deep diving into the cryptocurrency world was as a malware reverse engineer at FireEye, where I looked at a whole lot of APT malware and a penetration tester for the Federal Reserve system, where I was breaking Finance 1.0. So just some idea, give you an idea of what we're going to talk about. We're not going to drop any old days today. What my goal here is to educate, to share knowledge, to also learn from you. With the goal of just discussing how can we secure node infrastructure. So we'll start with a simple exercise on how do we know, what is the state of truth that tells us how many coins we actually have. We'll go through a variety of examples of how nodes break and we'll discuss a few of the ways that they could break in the future. Finally I'll introduce a solid node security threat model for generic nodes, which you can apply later on for a specific node implementation. And most importantly, discuss a top 10 list of security defenses that you can implement today, whether you're a standalone operator or you're working for an exchange and share lessons learned from trying to secure nodes of my own. So with that, let's talk about how many coins you have. So what is, if you're running, if you wanted to at any given moment tell me how many coins of any given asset that you have, how do you go about that? So well, you will probably have piece of software on your computer on your phone or hardware wallet maybe, which has some specific logic dedicated just for a specific asset. So if you have a Bitcoin wallet or Ethereum or Monero or some other coin, sorry if I didn't list here. This particular wallet communicates with a wider network somewhere to the cloud and ask a question, hey, how much coins do I have? What do I actually own? In case of Bitcoins, you try to enumerate how many outputs that you have unspent. Ethereum is different in the sense that it's a count-based system, so you have to look up how much of the asset that I actually have on the network. The thing is it gets a little bit more complicated. So if we start getting a little bit more granular, we're going to see that, in fact, we don't communicate with just some unknown entity, abstract entity. We actually communicate to specific nodes for that specific coin. So Bitcoin wall is communicated to Bitcoin nodes, Ethereum to Ethereum and Monero to Monero and so on. This introduces some complications because we realize that there are a lot of third-party components involved. So if we just want to manage our assets, we have to communicate to a whole bunch of software which is maintained by third parties. So just to give you a few more very simplistic threat model here, let's talk about components of a friend's coin, just the imaginary coin from the Mario Friend's Lend. So you have your wallet communicating to a node, communicating to the overall gossip network of some sort, trying to propagate blocks. You also have your developers who are contributing to the GitHub repository, so you have to rely on maintaining the repository, compiling the node, maybe, or downloading binaries there, and so on. And this all works really well and until we start thinking that, well, how can we be sure that all the software libraries, all the standalone software infrastructure does not act maliciously, does not drop, modify, or craft transactions to steal your funds? So let's see how this could happen. So we have this Mr. Robot character trying to attack a variety of different points of this threat model. So we'll start left to right so we can see that we can attack the network connection between your node and the cloud. So if someone could start dropping blocks, try to eclipse attack your node so basically to isolate it to make sure it's not communicating to the rest of the network properly. The same character can also attack your node directly if there are some unknown weaknesses that they can exploit to run, to do some kind of code execution or crash it. They can prevent you from accessing the network. At last, we also have to think about developers. The bad actors out there, they can go after developers like the Toad over there. They can make them commit that code. And I'll cover a few real-world examples where this does happen. So the idea is that it's an invitation to start thinking about the node security as a holistic ecosystem. So there are a variety of different components which are involved. So the examples that I just mentioned, they're not theoretical, they're practical. They're based on real-world incidents. So for example, in May 2014, someone attacked the BGP network used to eclipse attack Doge and Bitcoin minor pools. So this was, in case you're not familiar with BGP, hijacks. It's a way to effectively isolate whole large swaths of network blocks in order to make them route traffic to unexpected directions. This is something that happened a decade ago, I believe, with YouTube where all the traffic was redirected to Pakistan, I believe. And it keeps happening again and again. This is a thread that we have not observed within cryptocurrency world for a while, but it's something that we have to be aware of and build threat models around. On the EOS side, after the release of the Node software, they published a bug bounty and, oh boy, did they receive a lot of good finds there because there was immediately a code execution flaw that was discovered and for a while at least, they kept on getting one after another of high value bounty submitted to them, which included denial of service, code execution, and similar. Finally, in 2019, Monero website was compromised. The binaries for the wallet were backdoor to steal clients' funds. So this is an example of how we have to look out for the developer. Where are you getting that software? How trustworthy is that resource? What can you do to verify it? So this was just over the few years, but I just want to instill in you that this is an ongoing problem. These are all the different things happening this year. So in March, we had, on the testnet, but we still had a flaw discovered in the way Solana was processing transactions where it was not doing sufficient validation. So it resulted in 500 million Solana getting stolen. Filecoin, again, had a nasty inflation bug. Fortunately discovered on testnet, exploited also on testnet, but it resulted in 9 billion Filecoins minted when only 2 billion could have existed in first place. Inflation bugs are particularly nasty because these are the attacks not against individual users, but against the entire coin ecosystem. Tendermint is a library behind a variety of projects. It's a consensus mechanism used in projects like Cosmos, Oasis, and others. A denial service vulnerability was discovered there when parsing especially crafted invalid blocks, which basically crashed the nodes. So if this was successfully executed in the wild, Cosmos was likely not vulnerable to this because they didn't upgrade just to that particular vulnerable version. But if that was the case and the vulnerability was maliciously discovered, then it would result in a network halt. The last example, and probably the most critical and interesting one, both from the impact and the way that it was handled, is Ravencoin. Ravencoin had an inflation bug discovered just last month in July. The inflation bug vulnerabilities basically allow someone to print money out of thin air, which is extremely dangerous because it allows an attacker to profit and sell value to exchanges and it basically impacts every single user of the coin. What's interesting about this particular vulnerability was that it was actually maliciously introduced. It was introduced back in January through an account which was seemingly making adjustments to the way the comments were made on the debugging views were made. The core developers unfortunately missed that until the point that someone reported them, a third party which was building a blockchain explorer for Ravencoin. There's something we are going on in your network and we're observing someone minting a whole bunch of RVN and also, by the way, selling them on exchanges and profiting from it. The Ravencoin team was able to issue an emergency patch, worked with the miners, but it's still 300 million RVNs were minted and exchanged for some other coins. Something that we have to learn from. Before we go into a section on how to secure the nodes, how to look out for those vulnerabilities, let's first think about all the different ways that we can break the nodes. Just to define the scope right away, we're not going to talk about the features of a node which are documented and designs of the nodes. If something implements proof of work, then we'll say we're not going to deep dive into 51% attacks, reorts, other protocol design issues, we'll accept them as is. What we're more concerned about is if the node promises to do something correctly and it fails to do that, that's what we need to pay attention to. Key management is also outside of this, so you should probably running nodes on a variety of tiers, so if you just want something which replicates the state of the network, you should probably keep your keys on a separate system. Incorrect usage. I assume that if you're running a specific node that you read the documentation, you read everything that is known about it, so you don't necessarily make mistakes. A good example of that is Ripple's TF partial payment flag where if you do not implement that particular flag correctly, then whenever someone sends you some payment with that flag said, it may appear that you actually receive those funds, but in reality, it's an IOU, essentially that I will send you those things eventually, but not right now, so a lot of exchanges were exploited as a result of that. Finally, we're not going to focus on the layer. Two vulnerabilities, such as smart contracts, DeFi, and so on. What's InScope? What's InScope are the implementation flaws, so protocol, software, flaws, attack resilience, can the nodes stand up to sustained attacks? Infrastructure. We're not looking at nodes as just this one thing and we're protecting just the node itself and don't care about anything that it's built in. We're worrying about underlying OS, we're worrying about the network stack and anything that goes around it. Finally, management. Human factor always will be the weakest link in the security chain, so we will discuss access management, we'll talk about configuration, source control, and all other ops type of things. With that, just before we dive into the exercise, just wanted to establish some terminology so we're all on the same page. The threat model, and this is taken from OASP's excellent threat modeling cheat sheet if you want to review it and build your own threat models. Threat model itself is a process to identify potential threats. We want to enumerate all the different ways that things can go wrong. We can assess those threats. What is the risk coming from them? Are they basically going to result in me losing money or is it just a denial service or some other maybe less critical impact? Also, later on, we'll use that to prioritize mitigations. Why would we spend hours or weeks trying to address a risk that is not really that impactful? An important thing that we're going to do next we'll define the attack surface. In attack surface, think of it as all the different ways that someone can access, can attack your note or note infrastructure, and the threat agents, which are the entities which have enough skill, opportunity, and interest to attack your notes. Let's begin with just a really basic system. It's not interacting with any other notes. It's not managed by anything, just like a really basic core software. We have the note itself, which all it does is it's processing the packets. It's processing the transactions, blocks, does verification. It stores blocks in some kind of storage system. It parses configuration files so it knows how to properly look at those things. It may also include a VM interpreter process where it can interpret smart contracts or anything like full-blown, turn-complete, Ethereum-style smart contracts or something a little bit more locked down like Bitcoin script. Now, let's add some more components to that. In order for a note to be useful, it needs to have some kind of management interface. Most notes implement some kind of RPC network client. We have to think about the threats coming from that. Who can access this thing? What is it that you can do? Of course, note administrators themselves who are managing the machine, they can shut them down, they can bring it back online. They can reconfigure them and maybe introduce some flaws that I will cover in a moment. Also, these are just humans. Can they be attacked on their own with malware or maybe any other social engineering? Finally, notes need to communicate to other notes to figure out what is the state of the network. This is where a whole bunch of different things are coming into play like network infrastructure, other notes that we need to talk to, and miners. Network infrastructure includes basically underlying layers of communication for the notes. Think of BGP and DNS services and just basic routing like TCP connections, UDP, all of that is in scope and needs to be secured as well. Finally, notes are just not appearing on your machines out of nowhere. They must come from somewhere. Unless you are the developer, you probably are relying on third-party repositories, which also in turn rely on third-party dependencies. So this is something that we need to be aware of because, as I mentioned with Ravencoin, someone was able to backdoor the assets through a very sneaky code change and something that we will also need to consider within our threat model. So with that in mind, join the BCV General Text on the Defcon Discord channel and I'll ask you questions to just brainstorm together on how we can break notes. So the first thing we're going to attack is the core. This is the note software itself. This is what processes the blocks, the transactions and needs to verify them correctly. If you are this sneaky Mr. Robot character and you wanted to attack this, how would you do it? So look in the channel for your responses. So I have one comment of software supply chain attack. So this is something that we're going to cover in the software repository attack, but I'm talking about the core itself. That's the piece of software that does the actual blockchain logic. BGP attacks to create an eclipse. So again, so this is something that we have to worry about on the network connectivity side. Let's see. Yeah. So a denial of service against the nodes to crash with the bed blocks, now form block headers. So that's exactly that. So we can craft a packet, think of a tendermen flaw which basically crashes a node or maybe executes some kind of really nasty code execution attack. So just to give you some background, this is how I created the model. So there's a title, protocol vulnerabilities, severity. So if you can crash or do code execution and note the severity is high, probability I would say medium is just harder to find, harder to exploit. It requires dedicated time to discover those things. But the impact is that anything that is not properly passing blocks, transactions, what is the correct fork, messing with the governance and so on, inflation vulnerabilities, this is all in scope for this and it will have a severe impact on the node. However, I want you to consider it's less sexy of an attack. So we're not trying to find some kind of O-day within blocks and transactions and consider that nodes actually run all sorts of third-party software. So for example, Parity nodes, they run or open the theorem out, they run web UIs to manage the thing. A bunch of node software relies on third-party database libraries and standalone databases to store blocks. So all of that are fair game to attack as well. So if you are Mr. Robot and you wanted to attack your node infrastructure, I'm not going to spend time trying to find O-days for the way that you parse packets. It's a lot easier for me to find out what is the weakest link, what is the common of the shell software that you're running, such as if you're running Nginx and for some reason it's a vulnerable version. I'll try to attack that instead because it probably has more eyes on it and more vulnerabilities discovered so far. So consider those as your first line of things to lock down and the probability is definitely higher than finding a very directed attack in the way you parse blocks. So let's continue in the same style. So software repository attacks. So someone in the channel already mentioned that the supply chain attack. So whether you're attacking the software repository itself, so you can, like a Ravencoin example or Monero example, if you can compromise the software repository itself, then you can introduce arbitrary changes which are maybe different degrees of how hidden they are, depending on how many eyes are looking at the repository. And again, this can result in fund staffed or money printing type of vulnerabilities. However, what I want to invite you to also consider is not just the main software repository but also software dependencies. So an example, not exactly a no vulnerability but I believe it was Trinity Wallet which had a, it was backdoored on the source code level but the way that it was backdoored was not through the main repository but through one of the dependencies. So someone figured out what is the weakest link in the supply chain to that particular piece of software, they backdoored that and then they were able to introduce code that was stealing keys. So again, probability is high on that as well and severity is also extremely high. I mentioned this before, you know, human factor is always the weakest one. So node administrator, how can we attack that? Yep, phishing, send phishing email with some kind of malware. You know, the impact is very high. They can reconfigure the node, they can introduce a set of nodes which they essentially creates an eclipse attack where you only communicate to something that is controlled by the attacker. Certain blockchains, they have a switch you can flip which basically allows it to accept all blocks and transactions without doing any verifications like a debugging mode almost. There are a variety of things that administrator can do in a variety of ways that administrator can get attacked through phishing, malware, social engineering, you name it. You get the gist of how we're going through different components. The last one I want to cover is the network attack. So correct, so BGP attacks to create an eclipse. So exploiting the network infrastructure you know, all you know, a lot of nodes the way that they're built is that they need to first boot up. When they first come online, they need to communicate to something hard coded to figure out what is the network truth? What are the basic trusted infrastructure that I can use to start getting an idea what is the current block state? A lot of them use protocols like DNS in order to find out what is the first set of nodes that I need to connect to and if your underlying DNS infrastructure is compromised they can again try to do some kind of clips against you. Same with denial service if your nodes can never communicate over those protocols then they will never be able to connect to the network in the first place. BGP routing attacks those are extremely damaging and something that then used to be considered. I'm putting the severity as high on these but probability lower just because it's a lot harder to do a targeted attack to figure out what is the exact node that is owned by your company or by you individual so it would most likely be an attack against the entire the entire node network but it's still probable. We can keep going through all of these individual components and try to go through what are the main threats. Luckily I went through this exercise over the last few months and I built a node threat model which applies to generic nodes out there. If you take a Bitcoin node versus let's say Ethereum nodes they will have all these core issues all these core threats plus whatever makes them unique from each other. I mentioned that for example Open Ethereum has an extra web server in there so you'll need to slap in a web server into this model and consider what are the threats there as well. Some more terminology so we can interpret the grid that I'm going to show you in a bit Stride is a common acronym used for threat modeling it stands for simply just a variety of bad things you can do which is spoofing tampering, repudiation information disclosure denial of service, elevation of privilege it's just a guide to help you think better about what is the impact there. It is also important to consider the likelihood what is how likely is that the threat event is going to occur where is how likely is that the threat actor not only has an opportunity but also the expertise to exploit something the weakness. This will become useful later on as we talk about mitigations and how to prioritize them. So overall in the threat model we already went through the 11 components I showed you in a few slides ago the total of threats that I identified were 14 and the total number of critical threats for a generic node is 5. So again depending on what how your ecosystem looks like you know if you're running a larger set of nodes and you have doctorized images and all that your threat model will continue growing. This is just to get you started somewhere and provide you foundation. This is just a small glimpse into what the threat model looks like we have the threat name so node software generic vulnerabilities the stride, impacts of elevation of privilege, denial of service, severity, probability description most importantly a variety of different mitigations that you can implement to address this threat. So a key thing that we need to do when considering mitigations and the risk is to consider the cost. The cost, probability and severity. So the cost is how much time is it going to take you, how many resources you need to invest to address something. What is the severity and probability of this threat? So in order to prioritize a variety of threats I came up with this five level I guess a criticality grid where most critical flaws are the ones that are both have high impact but also high probability of happening. Severe threats are the ones that have high impact but maybe slightly lower probability of occurring. So think of your generic web survey getting exploited which is running on your node versus some esoteric block parsing vulnerability that needs to be discovered to be exploited. And all the way to low where these are the threats which we can address at one point but only after we're done with the top two or top three at least. So of all these mitigations I in the model I created about 41 mitigations that one could potentially implement. There could be probably more that we can think of but I'll share the top 10 ones in a bit. Of those mitigations they're addressing 22 critical threats. What's interesting is that half of those mitigations for critical threats are in fact very low cost. This is something that you can implement in a day and will significantly bolster the security stance of your nodes. So yeah, you can start building fuzzers, you can start looking for every line of code of your nodes to make them secure and they will make them very secure. But you can also do a bunch of things which are very low cost that will not completely make your nodes completely secure but they will also by the order of magnitude make them resilient to some of the attacks that I described. So this is just a different view that in the top bar of the critical vulnerabilities the ones in light blue you can see that half of them are basically low cost solutions that you can implement and then you have just if you really want to push it through this like it's 99.99% secure you can continue on that on the trail and but that will be a little bit more costly. So with that let's talk about into node security top 10 defenses that you can implement. So the first one and the most critical one I think is secure handling of where is the where's the node software coming from? The repositories the binary distributions and so on. One key thing that we do at Coinbase and something that you could consider as well is repository pinning. Repositories can get compromised but if you make sure that you pin to a specific non-good version that you will work with and you will stick to until you go through some kind of process that okay I'm going to switch to the latest release instead of just downloading whatever is the latest one every time you deploy a node that's something you could consider and could partially mitigate the risk of backdoor repos. Another thing is verification of signatures. So if you're relying on either source code that you're downloading or binaries that you're downloading make sure you verify all the signatures that in the case of Monero if the binaries were signed and the attackers did not have signed signatures correctly then you'll be able to detect that in the case of source code if you can at least verify like who is committing to the repository is it coming from am I accessing your website and it's the TLS is not breaking, no one is in the middle of me trying to download the source code again this is something that could make your nodes more secure we continue on that train of thought we can also make sure that we build all nodes from source code I know this is a big ask but this is something that you could consider and the reason for this is again the Monero example where only the binaries of Monero were backdoor the source code remained intact and the reason why both could have been compromised but if you consider how binaries for nodes are built so there's a software repository with a lot of eyes and then there could be a flow where one single developer with malware and their machine downloads that source code builds the library up close to the binary back on the website there are a variety things that could break along the way same goes with the CI automation of some sort which builds binaries automatically there are a lot more components which could be attacked and compromised which is why in case again lesson learned from that one incident is that if you just stick to the source code it may still be backdoor but at least you have like one point of failure as opposed to a most of others which are required when building binaries secure node configuration so every single node that I looked at has a whole variety of different levers that you can pull to make them secure some things that you should generically consider is make sure that you can diversify the number of connections that your node can make and to which nodes it can make it can connect to so an example would be things like Stellar I believe they need to be manually configured to distribute which nodes that you connect to so make sure that if you configure nodes like that you select as wide of a node selection as possible others they restrict the number of connections total so you want to see like what is a reasonable number of connections you want to maintain throughout the network this will help you with eclipse attacks making more resilient against forks and so on another important key on configuring nodes securely is locking down your RPC interfaces so I believe last year there was mass scanning of Ethereum nodes that were looking for open RPC interfaces to basically steal private keys so locked down your RPC interface there's no reason why those should be exposed to the rest of the world so make sure you configure whatever IP or interface that RPC is listening on make sure it's configured to something local to your network or just local host restrict node access so not everyone needs constant access to your nodes not everyone needs to be able to modify arbitrary things within your node so at Coinbase what we do is we create a consensus mechanism with no configuration changes no nodes no one can bring up and down nodes just arbitrarily it requires a consensus of people the more critical your infrastructure is the more people it requires so you can implement it through variety of ways through get up through some kind of two factor pings that you can send to people to approve any given action define and enforce administrator roles again this is something to restrict to security nodes in larger environments but you can apply this to individual nodes as well make sure that there are some specific roles set up for the node that you can either configure nodes and deploy them or shut them down but not everything at the same time so you can get very granular there but it depends see how appropriate it is for your specific environment finally restrict node access as in the network traffic node access both ingress and egress so on one side it makes sense that you restrict your RPC interface already so make sure those are firewalled off that you cannot access nodes from anywhere and externally you also have some kind of restriction set up as well on the other side nodes could be an excellent points of entry for the attacker who found some kind of vulnerability into the rest of your network so make sure that your nodes cannot communicate to the rest of your network as well because they could be used as stepping stones monitor and log node activity so this one is probably the most interesting one and there's a lot of things you can do there anytime your node loses internet connectivity make sure you do some basic verification am I getting something with BGP or am I getting my DNS going down, am I under attack am I getting eclipsed so make sure you investigate those am I in the right fork, am I not seeing sufficient traffic all of that applies you can do node specific verifications too not just generic network monitoring such as periodically check like am I in the right fork what is the block height what is the current block hash do other nodes in my system or externally or on blockchain do they still see the same thing so in case of the recent ETC experiment incident you would have been able to quickly diagnose like oh okay so there's something going on with nodes because there's some kind of forking happening finally log all access you may not be as essential during the normal operation node but when something goes wrong and you need to investigate and figure out what happened, who accessed it, what were the network events that led up to the attack those logs will be highly instrumental for the investigation lockdown base OS so definitely you cannot build a secure node software if your underlying layer is insecure if again if you want to go after the weakest link then your node is very well configured and firewalled off but your underlying OS is outdated version of Linux which has like exposed ports and they're easily attacked the attacker is just going to go after that and going to skip all of the other mitigations you build so you can do things like dockerize your nodes run SE Linux or similar toolkits so there are a variety of things you can do to lock down the OS and there are guides for that but something to consider as well Harden node nodes network connections so going up the stack a little bit, not just protecting what connections can be made or what we're monitoring, make sure that if you configure DNS server for your node make sure it's a secure one it uses DNSSEC, if you're using ISPs make sure that whatever BHP connections that it uses are done in secure fashion, if your nodes need to communicate to some kind of HTTP resources, make sure you configure your nodes properly so you're not getting them in the middle Denial service protection is critical, again it's potentially hard to determine I want to attack just one particular node for one particular user or organization but it's proven to use something like Cloudfare to have a layer of denial service protection so you don't have to worry about that node specific threats node and protocol specific threats this is a catchall basically be mindful that all nodes are unique in their own different ways I mentioned before that stellar you have to manually configure what are the trusted nodes you have to manually calculate what is my threshold for it's a BFT network, what is my threshold that it can get attacked so make sure that I'm not going to be vulnerable to that other protocols like EOS they implement debugging modes that you have to watch out for so read the config file completely make sure you understand what are the implications of all the variety of settings and have a good secure configuration specific for that node verify node functionality before deployment so that's a much harder one because sure, you pin the repository you are pretty confident, okay so it probably was not modified but I'm not 100% sure that whatever I downloaded is working as it's supposed to there are no backdoors there how do you verify that it still works as intended well ideally you would run a set of tests like hey if I transmit this transaction it shows up on the network or if I see a transaction coming from the network my account gets properly credited and that's a big ask to implement for every single node so one project which aims to solve this problem is Coinbase Rosetta project which creates a kind of middleware for a variety of different nodes to be able to speak the same API so instead of implementing a variety of different calls to transmit a transaction get a current block current block hash and transactions in it Rosetta creates a kind of middleware for a variety of different nodes that you can just use a single API call and it automatically translates to whatever is specific for that node now what's interesting about the Rosetta project also includes a Rosetta Validator which exercises the node and make sure that it passes a variety of very specific tests from transaction verification blocks and signing and so on to make sure that it works exactly as intended not every project supports Rosetta interface but for the ones that do you can implement it in a pipeline to make sure that the nodes that you deploy are acting as expected and you notice that we're slowly ramping up the difficulty level this is probably the hardest one this requires you to examine the source code examine the alerts that you're getting and this is the basic static analysis of basic security static analysis of node software so give me now a need to go through the actual source code but you can observe a variety of different alerts reported by tools like Salis so this is another coinbase tool which we use internally and it's an open source tool you can use as well to quickly run through a variety of node source code packages and it gives you a nice report of what are the high critical vulnerabilities within that so you can examine them just get a general sense it's hard to say which ones are false positives without actually looking in the source code but you can see if I suddenly see a hundred or so or this really sneaky report maybe I should investigate more or report it or ask the original developers in the Salis project it supports a variety of different languages from Go to Ruby and so on GoSec like for if you're just running Ethereum or other GoSec based notes so GoSec is excellent in fact Salis is running a variety of open source projects and it just creates a wrapper for them so GoSec is one of them for all the other projects you have something like Semgres so if you have Seco to analyze and so on so you can use that as well so with that just to summarize what is our total view of all the different mitigations top ten things that you can do to secure your notes so make sure you handle software repositories securely make sure that you pin them that you understand that they can be compromised and you need to just investigate a little bit more build old notes from source code so again it's just reducing your attack vectors just a little bit more you just build everything from source there are a lot of eyes in source code securely configure notes so make sure that you diversify what connections your notes have make sure that they can be just as easily eclipsed and people can access it and reconfigure them restrict note access monitor and log note activity so you can get very creative with what you can do to judge what is notes help lock down your base OS you're not running you're not building your castle on quicksand hardens notes connections definitely consider note and protocol specific threats all notes are unique in a variety of different ways so you need to consider those as well verify note functionality so if your note supports risetta project run risetta validator you will exercise until you give you this good feeling that at least for the variety of tests this still works as expected and then if you have time and you have technical expertise try to run basic static analysis tools just to periodically see major low-hanging fruit vulnerabilities that are getting introduced that I can catch maybe report to original developers so with that thank you so much for your time I may have not mentioned this I'm the blockchain threat intelligence newsletter I list a lot of the node incidents of vulnerabilities that are getting discovered so subscribe see if you can catch the latest lessons learned from those vulnerabilities and feel free to follow me on twitter and or feel free to contact me offline if you have any more questions thank you