Hello, 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 Def Con 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 kashiginsky I'm a blockchain security engineer at coinbase

Where I spend most of my time breaking 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 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 fire I 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 idea of what we're going to talk about. I'm not gonna 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 making discussing like 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? well Go through a variety of examples of how notes break and we'll discuss a few of the ways that they could break in the future Finally, I'll introduce a solid note security threat model for generic notes, which you can apply later on for

specific node implementation and most importantly discuss top 10 list of Security defenses that you can implement today whether you are a standalone operator or you're working for an exchange And share lessons learned from trying to secure notes 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'll 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 it asked 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 in teams Ethereum is different in sense that it's a count based system. So you have to look up how many

How much of the assets 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 gonna see that in fact, we don't communicate with just some unknown entity abstract entity We we actually communicate to specific nodes for that specific coin. So Bitcoin wallets communicate to Bitcoin nodes

Ethereum to Ethereum and Monero to Monero and so on this introduces some complications because We realized that There there are a lot of third-party components involved so if we if we just want to manage our

Our assets we have to communicate to a whole bunch of software which is maintained by third parties So just to give you like 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 land 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 note 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 variety of different points of this threat model, so you know on will start left to right so we can see that the You know we can attack the network connection between your node and the cloud so if someone could start dropping blocks try to

Eclipse attack your notes so to basically to isolate it to make sure it's not communicating to the rest of network properly The same character can also attack you know directly if there are some Unknown weaknesses that they can exploit to do 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 the bad actors out there They can go after developers like the toad over there. They can make them commit bad That code and I'll cover a few example real-world example where this does happen

So the idea is that we it's it's a 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 by two clips attack Doge and Bitcoin minor pools So this 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 to Pakistan, I believe and it keeps happening again and again This 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 These 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 one there was immediately a code execution flaw that was discovered and

They for for a while at least they kept on getting one after another of high 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 or backdoor to steal clients funds

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 like this is an ongoing problem. This these are all the different things happening this year

So in March we had on a testnet But we still had a flaw discovered in the way Solana was processing transactions where he was not doing sufficient validation So it resulted in 500 million Solana getting stolen file coin again had a nasty inflation bug fortunately discovered on testnet

Exploited also on testnet but it resulted in 9 billion file coins 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 It's an aisle service vulnerability was discovered there when parsing specially 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 Raven coin Raven coin 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 it allows an attacker just to profit and sell value to exchanges and It basically impacts every single user of the of the coin

What's interesting about this particular vulnerability was that it was actually maliciously introduced. It was introduced back in January through by an account which Was seemingly making like adjustments to the way the comments were made on the the debugging views were made

So and and the core developers unfortunately missed that Until the point that someone reported them some a third party which was building a blockchain explorer for Raven coin reports Like there's something weird going on in your network. We're observing someone Minting a whole bunch of RVN and also by the way selling them on exchanges and profiting from it

so the Raven coin Team was able to issue an emergency patch worked with the miners but it's still 300 million RV ends were minted and And exchanged for some other coins something that we have to learn from

So before we we go into section on how to secure the notes how to Look out for those vulnerabilities. Let's first think about all the different ways that we can break the notes So just to define the scope right away We're not going to talk about the features of a note which are documented and designs of the note

So if something implements proof-of-work, then we'll say we're not going to deep dive into 51% attacks reorgs Other protocol design issues will accept them as is What we're more concerned about is if the note 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 if you're you know, you should probably running notes on 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. So I assume that if you're running a specific note that you read a documentation you read everything that is known about it

So you don't necessarily Make mistakes like a good example of that is ripples 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 only it only it's a 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 gonna focus on the layer 2 vulnerabilities such as smart contracts defy and so on

So what's in scope? What's in scope are the implementation flaws so protocol software flaws attack resilience. Can the note stand up to sustained? attacks infrastructure, so we're not looking at notes as just this one thing and we're protecting just the note itself and don't care about anything that

It's built-in top we're worrying about underlying OS with worrying about the network stack and anything that goes around it Finally management human factor is always was 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

so with that Just before we dive into the the exercise just wanted to establish some terminology So we're all on the same page The threat model and this is taken from OS 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. So 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 are they basically gonna result in me losing money or is it just a denial service or some other maybe?

less critical impact And also later on we'll use that to prioritize mitigations Why would we spend hours or or weeks trying to address a risk which is not really that impactful? An important thing that we're going to do next we'll define the attack surface and 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

So let's begin with just a really basic System, it's not interacting with any other nodes. It's not managed by anything just like a really basic core software, so we have the node itself, which all it does is it's processing the The packets it's processing the

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 and it may also include a VM interpreter Process where it can interpret smart contracts or some anything like full-blown Turing completes

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 note to be useful. It needs to have some kind of management interface and most notes implement some kind of RPC Network clients, so we have to think about the threats coming from that who can access this thing who get what is it?

They can do and of course node 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 And also these are just humans. Can they be attacked on their own with malware or maybe any other social engineering?

Finally Those need to communicate to other nodes to figure out What is the state of the network and this is where a whole bunch of different things are coming into play like network? infrastructure other nodes that we need to talk to And miners so network infrastructure includes basically underlying layers of communication for the notes

So think of BGP And DNS client DNS services and just basic routing like TCP connections UDP All of that is in scope and needs to be secured as well Finally nodes 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 Raven coin someone was able to backdoor

the the assets through a very sneaky code change and something that we also need to Consider it within our threat model So with that in mind join the BCV general text on the defcon discord channel and Start well, I'll ask you questions to just brainstorm together and how we can break notes

So the first thing we're gonna attack is the core. This is this is the note software itself. This is what processes the The The the blocks the transactions and used to verify them correctly

If you are this, you know sneaky mr. Robot character and you wanted to attack this how would you do it? So I'll look in the channel for your responses So I have one comment of software supply chain attack

So that's well, 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 the piece of software that does the the actual blockchain logic BGP attacks to create an eclipse

so again, so this is 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 to the bad blocks now form block headers so that's exactly exactly that so we We can we can craft a packet think of a tender mint flaw Which basically crashes a node or maybe executes a some kind of really nasty code execution attack

So just to give you some some background. This is this is how I created the model so there's a title protocol vulnerabilities severity, so if you can Crash or do code execution. I know the severity is high Probability I would say medium. It's just harder to find harder to exploit

It's a it requires a dedicated time to discover those things but the impact is that Anything that is not properly pricing blocks transactions What is the correct fork making 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 note however, I Want you to consider it's less sexy of an attack So you're not trying to find some kind of oday within blocks and transactions and consider the nodes actually run all sorts of third-party software, so For example parity notes they run or open here. No, they run

You know web UIs to manage the thing a bunch of no 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 your node infrastructure. I'm not gonna spend time Trying to find old days for the way that you parse packets It's a lot easier for me to find out like what is the weakest link? What is the common? Off the shelf software that you're running such as you know, if you're running nginx and for some reason it's a vulnerable version

I'll try to attack that as well I'll try to attack that instead because it probably has more eyes on it and more vulnerabilities discovered so far so consider consider those as your first line of things to lock down and the probability is definitely higher than finding a very Directed attack to like 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, you know the supply chain attack So whether you're attacking the Software repository itself so you can you know Like a Raven coin example or Monero example if you can compromise the software repository itself

Then you can introduce arbitrary changes Which which are maybe different degrees of how hidden they are depending how many eyes are looking at the repository And again this this can result in in fun stuffed or money printing type of vulnerabilities

however, what I want to invite you to if to also consider is not just the main software repository, but also Software dependencies. So an example not as actually a no vulnerability, but I believe it was Trinity wallet which had a It was back doored on the on the source code level

But the way that it was back door was not through the main repository but through one of the dependencies So someone figured out what are the what is the weakest link in a supply chain to that particular piece of software? the back door 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 is is it's very high you can 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 The variety of things that administrator can do and the variety of ways that administrator can get attacked through phishing malware Social engineering you name it?

The last you you get the you get the gist of how we're going through different components The last 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 the

All you know a lot of 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? Like what are what are the basic trusted? infrastructure that I can use to start Getting an idea. What is the current block state?

well, a lot of them use protocols like DNS in order to To find out so like what is what is the first set of notes 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 of service if If your nose can never communicate over those protocols, then they will never be able to connect to the network in the first place BGP routing attacks, that's those are extremely damaging and Something that that needs 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 it's still it's still probable So we can keep going through all of these

Individual components and try to go through like what are the main threats luckily? I went through this exercise over the last few months and I built a and a no threat model which applies to Generic notes out there. So if you if you take a Bitcoin node versus let's say aetherium nodes

They will have all these core issues all these core threats plus whatever makes them unique from each other So if you're like I mentioned that for example open a theorem has an extra web server in there So you'll need to slap in a web server into this model and consider like what is what is what are the threats there as well? So more terminology so we can interpret the threat

The grid that I'm going to show you in a bit So stride is a common acronym used for threat modeling It stands for simply just variety of bad things you can do which is spoofing tampering Repudiation information disclosure the now service elevation of privilege It's just a guide to help you think better about like what are 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 as 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 number of threats that identify 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 the Doctorized images and all that your your threat model will continue growing this this is just to get you started somewhere and provide you foundation This is a 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 then our service severity probability Description most importantly a variety of different mitigations that you can implement to address this threat

so a key 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 much how many resources you need to invest to address something? What is the severity and probability of this threat? So in order to prior to prioritize a variety of threats, I came up with this five level I guess Criticality grid where most critical flaws are the ones that are both have high impact but also high probability of happening

Severe are Severe threats are the ones that have high impact but maybe slightly lower probability of occurring so think of your generic web server getting exploited which is running on your 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 We can't address at one point but only after we're done with with the top two or top three at least so if all these mitigations I

In the model I created about 41 mitigations that one could potentially implement It could be probably more that we can think of but I'll share the top 10 once in a bit Of those mitigations, they're addressing 22 critical threats What's interesting? Is that half of those mitigations for critical threats? In fact, very low cost

This is something that you can implement in a day And will significantly bolster the security stance of your notes So yeah, you can start building fuzzers. You can start looking for every Line of code of your notes 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 you will not make your notes completely secure But they will also by the order magnitude make them resilient to sound 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 you know If you really want to push it through this like it's 99.99 percent 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 no 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 nongid version That you will work with and you will stick to until you go through some kind of process that okay I'm gonna 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 and 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 you're downloading make sure you verify all the signatures that in the case of Monero The binaries were signed and the attackers did not have signed

signatures Correctly, then you would be able to detect that in the case of source code If you can at least verify like who is committing to the repositories coming from am I accessing a website and it's you know? The TLS is not breaking. No one is men in middle of me trying to download the source code again. This is something that could

Make your notes more secure on We continue on that train of thought we can also Make sure that we built all notes from source code I know this is a big ask for 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 both could have been compromised. But if you consider how binaries for notes 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 in their machine downloads that source code

Builds the library up close the binary back on the website. There are variety things that could break along the way same goes with a 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 a backdoor But at least you have like one points of failure as opposed to a multitude of others which are required when building binaries secure no configuration, so Every single note that I looked at has a whole variety different levers that you can pull to make them secure

Some things that you should generically you could consider is make sure that you can diversify the number of connections that your note can make and To which knows it can make it can connect to so an example would be Things like stellar. I believe they they need to be

manually configured to Distribute which knows that you connect to so make sure that if you configure notes like that you you select as wide of a Note selection as possible Others they restrict the number of connections total. So you want to see like what is a 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 another important key on Configuring notes securely is locking down your RPC interfaces So I believe last year there was mass scanning of etherium notes that we're looking for open and RPC interfaces

to basically steal Private keys so lock down your RPC interface. There's no reason why those should be exposed to the rest of the world So make sure you configure, you know Whatever whatever IP or interface that RPC is listening on make sure it's configured to something local to your network or just localhost

Restrict node access So Not everyone needs constant access to your notes. Not everyone needs to be able to modify Arbitrary things within your node. So it a coin base. What we do is we create a consensus mechanism with no configuration changes no nodes No one can bring up and down notes just arbitrarily

It requires a consensus of people the more critical your infrastructures the more people it requires a sign-off so you can implement it through a 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 enforce administrator roles again, this is something to restrict to security notes in larger environments, but You can apply this to you individual nodes as well. Make sure that there are some specific roles set up for for the node That you know, you can either Configure notes 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 node from anywhere and then 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 notes cannot communicate to the rest of your network as well because they could be used as stepping stones

Monitor and log not node activity So this one is probably the most interesting one and this there's a lot there are a lot of things you can do there Anytime your nodes loses internet connectivity Make sure you do some basic verification Am I getting is there like 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 no specific verifications to not just generic network Monitoring such as like periodically check like am I in the right fork? What is what is the block height?

Where is the current block hash do other nodes in my system or externally or on blockchain exports? 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 the there's some kind of forking happening Finally log all access all network events. It may not be as essential during the normal operation of 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're if you want to go after the weakest link and Your notice very well-configured and firewalled off but your underlying OS is some outdated version of Linux

Which has like exposed ports and they're easily attacked This the attacker is just gonna go after that and going to skip all the other mitigations you build So you could do things like doctorize your notes run SC Linux or similar toolkits So there are variety of things you can do to lock down the OS and there are guides for that

But something to consider as well Hardened note net 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 note

Make sure it's a secure one uses DNS sec if you're using ISPs make sure that Whatever BGP connections that it uses are done in secure fashion. If you knows music communicate to Some kind of HTTP resources make sure you configure your CAs properly So you're not getting that in the middle Denial service protection is critical again. It's

potentially Hard to determine that I want to attack just one particular note for one particular User or organization, but it's prudent to use something like cloud fair to to have a layer of denial service protection So you don't have to worry about that No specific threats known and protocol specific threats

This is a catch-all basically Be mindful that all notes are unique in their own different ways So I mentioned before that stellar you have to manually configure. What are the trusted notes? You have to manually calculate like hey, like what is my threshold for it's a it's a BFT network What are what is my threshold that it can get attacked? So make sure that I'm not

I'm not going to be vulnerable to that other other Protocols like EOS they have they implement like debugging modes that you have to watch out for so Read the config file completely. Make sure you understand it complete. What are the implications of all the variety of settings and and have a

Good secure configuration specific for that note Verify no functionality before deployment. So that's a much harder one because Sure, you you pin the you pin the repository you are pretty confident Okay, so probably was not modified, but I'm not 100% sure

That whatever I downloaded it 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 network my account gets properly credited

And that's a big ask to implement for every single note So one project which aims to solve this problem is Coinbase Rosetta project which creates a kind of a 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. I get the current block hash and transactions in it Rosetta creates a kind of a middleware For a variety of different nodes that you can just use the single API call and it automatically translates to whatever is

specific for that note 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 very specific tests from from transaction verification Blocks and signing and so on to make sure that it works exactly as intended

Not every project supports Rosetta 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 but examine

the source code examine the The alerts are you getting and this is the basic static analysis of basic security static analysis of node software so You may not need to go through the actual source code, but you can observe a variety of different alerts reported by tools

Like salas. So this is another coin based tool, which we use internally and it's a it's an open source tool You can use as well to quickly run through 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 like hey if I suddenly see a hundred or so or like this really sneaky Report maybe I should investigate more or report it or ask the original developers In the Salus Salus project it supports a variety of different

Languages from go to Ruby and so on Go sec like for if you're just running a theorem or other go link based Notes, so go sec is excellent. In fact Salus is is running a variety of open source projects

And it just creates a wrapper for them. So go sec is one of them For all the other projects you have something like semgrep So if you have C code to analyze and so on so you can use that as well So 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 it a little bit more Build all notes from source code. So again, it's just reducing your

Attack vector is just a little bit more. You just build everything from source There are a lot of eyes and source code who knows what happens with those binaries securely configure notes So make sure that you diversify what connections your notes have make sure that they're they can't be just as easily

Eclipsed and people can access it and reconfigure them restrict node access Monitor and log node activity so you can get again very creative with those what you can do to judge. What is notes help? Log down your base OS make sure that you're not running. You're you're not building your castle on quicksand

hardens notes connections Definitely consider node and protocol specific threats all nodes are unique in the variety of different ways So you need to consider those as well verify no functionality So if you if your note supports Rosetta project Ron Rosetta validator You will exercise until you give you like this good feeling that okay, at least for the variety of tests

This work 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 like how they're like 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 a 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