rdig/ethereum-honeypot

Track external parties actions run on open ethereum nodes.

ethereum-honeypot's Issues

Autosetup script

For local development, there's a Vagrant image, for the container environments there's Docker images.

Here we'll cover the third case, a Virtual Machine. Either local, barebones or rented.

A bash autosetup script will cover this nicely.

Implement an Firebase Realtime Database connector

This will serve as an alternate json object storage solution (NoSQL).

It will not replace the planned MongoDB integration, but will serve as an alternative to having to deal with setting up and configuring mongo.

Getting started guide

Rename project

When this project is in a decent state, and able to be released, rename it something sensible. Eg: ethereum-honeypot

Firestore reads optimizations

We seem to be hitting the reads / day quota very easily (granted, this was during development of #30):

We should look into this to find out where the numerous reads come from. Also, if it makes sense, change the logger to also use transactions (just like stats).

On the other hand, this might be a one time fluke and we might be threading on premature optimization territory.

NOTE: If we end up implementing #5, this will not be relevant anymore.

Web interface

It should come as no surprise that this should have a web interface that displays the relevant maps, charts and stats.

Otherwise the whole logging endeavor is kinda for naught

Write an RPC passthrough server

This should be a drop-in replacement for the existing ganache-core server.

Rewriting it we can make it more specialized, adding the ability to log requests and responses and everything in between.

Also gives us the ability to use ganache-core as an actual dependency, instead of just cloning and changing the code.

Integrate Snyk for vulnerability detection

Integrate Snyk, or equivalent, into the project repository (via GH's marketplace) to help with code and dependency vulnerability detection.

Integrate CI for automated builds and testing

Integrate Circle CI to help with automated builds, unit and integration testing.

Most likely this will also help integrate Greenkeeper into the project.

This should be available / accessed via GH's new Checks tab.

Server health stats

It will be useful to have some server health stats tracked as well.

A good use case would be correlating different RPC methods with high memory / cpu use.

Maybe this could be tied into #7

Multiple honeypot servers

The system should be able to handle multiple honeypots, set up in different regions, logging data into the same database.

This is the main need for #5

Transactions simulations

A nice to have is a script that will randomly simulate transactions between accounts to further the idea of a real blockchain node.

This can be done via a cron script, a trigger on every request, or some other solution.

Blockchain forking

Since ganache give us the ability of forking an existing chain, we should take advantage of this to further the simulation and the chances that the honeypot is discovered.

A mechanism to periodically re-fork the chain should also be considered, so that the data is somewhat up-to-date.

Ganache provider wrapper / adapter

This is needed in order to be able to respond the the web3_clientVersion call with different strings.

This should just intercept the calls, pass them through, but change the calls that we need.

This may not be possible and a provider might need to be written: to investigate.

Note

A naive implementation may be possible by intercepting the response in the server just before sending it out and modifying the string.

This is not ideal as it would be redundant, and obviously eat up more resources.

Periodically restart `node` process

The node process that's running the RPC server keeps crashing randomly (maybe one of the commands executed against the honeypot crashes the process...).

The makeshift logger that we set up doesn't catch much output (something to do with the server env it's running on, since on the local dev machine it logs every error).

So, to plug the leak, until we have time to deal with the underlying issue, we can set up a script to restart the node process periodically (on the hour maybe?).

This is actually an improvement, since every time we restarted, fresh accounts with new ether are generated, so the bots have new toys to play with.

Services logs

The server, provider and the rest of the helpers should log debug info to a local .log file for diagnostic purposes.

Same client version string per request IP

Continuing the implementation from #3 which tracks modifying the response from the web3_clientVersion call.

It should query the database, find out the last request from this IP (current requester) and match the client version response.

This way, it will be a little less obvious that the machine is running a honeypot.

Docker image

For production deployment in environments which use Docker containers a pre-build image would speed up setup time / upfront learning curve.

Integrate Greenkeeper for dependency management

Integrate Greenkeeper most likely via CI for dependency updates and management.

This will most likely be done via CI. See #19 about that.

Infrastructure architecture

This issues should keep track of the various infrastructure architecture configurations:

• all on one server
• honeypot on an edge server, database + web interface on another
• multiple honeypot edge servers, database + web interface on another
• ...

Sqlite3 to Cloud Firestore migration script

Since #25 landed all data storage was moved to Firebase's Cloud Firestore engine.

The currently available data, that is still stored inside sqlite3 files needs to be migrated to the new storage format.

Vagrant local development

Since this project will have quite a few moving parts, it will be nice to have an automated setup process / image that takes care of this.

For local development a Vagrant image might be a good choice. Obviously there may very well be a better alternative.

RPC Server code improvements

This Epic tracks implementation of code improvements in the RPC server code.

They are marked with @TODO code blocks.

Create Firestore stats collection

Since we are storing data inside a NoSQL database we can't really get nice stats like we need to display on our interface.

Currently planned stats:

• unique countries count
• total countries count (by counting unique countries prop names)
• top countries (by sorting unique countries by they're count)
• unique cities count (this will also have geolocation besides the count)
• total cities count (by counting unique cities prop names)
• top cities (by sorting unique cities by they're count)
• unique ip addresses count
• total ip addresses count (by counting unique ip addresses prop names)
• top ip addresses (by sorting unique ip addresses by they're count)
• unique web3 methods count
• total web3 methods count (by counting unique web3 methods prop names)
• top web3 methods (by sorting unique web3 methods by they're count)
• unique user agents count
• total user agents count (by counting unique user agents prop names)
• top user agents (by sorting unique user agents by they're count)
• requests per day

We can overcome this by creating a new Firestore collection that tracks this for us, so we will just have query that to display info on web page.

Retroactively process stats script

We added a new stats collection in #29, but this will track stats only going forward, not the ones that already exits.

This issue tracks implementing a local script that will use transactions to process backlogged requests.

Change database server to MongoDB

Since we'll need it will be nice to support multiple input sources (multiple servers) we need a database engine that can handle that.

While the current sqlite is super easy to work with, it will be cumbersome to set up for multiple servers. Also the filesystem file limit will play a role here.

Note

This is a suggestion made by somebody (me) who's main expertise is not databases, so my choice may not be the best.

Implement an alternative geoip lookup

The current service we are using ip-api.com limits more than 150 calls per minute by banning the originating IP.

If this happens (and it happens when there's an influx of bots accessing the node) the whole logger method call will fail (this issue should also look into fixing that) and the data will be lost.

Either use an external service, or something local, it's all good, as long as it works.