Security Risks with opening port 7007

has anyone experienced security notifications when testing the compose DB introduction and running:

CERAMIC_ENABLE_EXPERIMENTAL_COMPOSE_DB='true' npx @ceramicnetwork/cli daemon

this of course opens up which actually opens up port 7007 to the internet? I got 40 notifications my home wifi blocked known malicious IPs from connecting to my PC while I was running this for ~10 min. I didn’t do any port forwarding with my home router so I’m not sure why this even happened, so I’m wondering if there is a best practice to use AWS/docker VM instead of doing this on a home PC so we are not barraged by malicious bots.

Hi @walletchat,

The Ceramic daemon doesn’t do anything different w.r.t. the port than any server would when running on your machine.

The IPFS daemon that spins up alongside Ceramic does do some additional things, though. It will connect to the p2p network, which can sometimes cause incoming (legitimate) p2p connections to be flagged as malicious.

In fact, IPFS does its best to punch through NAT and firewalls - not because it’s trying to bypass them but in order to ensure clean bidirectional connectivity with other peers on the network. This is similar to how Google Meet or Zoom work (using STUN/TURN/ICE servers for negotiation through NAT/firewall, then a direct connection machine-to-machine).

W.r.t. security, I would suggest making sure your local firewall continues to block all ingress traffic to 7007 as well as to the IPFS API port (typically 5001 but might vary based on config). It should allow both ingress and egress traffic to/from the IPFS swarm port though (typically 4001 but might vary based on config). This allows IPFS to actually communicate properly with the rest of the p2p network.

You’d need to do something similar for your cloud deployments. If you know the egress IP address of the application server that wants to use the Ceramic node, you can add it to a firewall/allowlist for access to the Ceramic node. The IPFS API port should never be directly exposed to the internet, only internally to the Ceramic node. The IPFS swarm port would need to be exposed to the internet for swarm connectivity to work correctly.

Hope this helps.

Thanks, I’m trying to work with my ISP to get port numbers it was trying to access. Its still a bit odd because I never opened port forwarding, but I am not an expert in how IPFS communicates.

Is there any documentation which helps a user walk through this portion of the Ceramic setup? Apologize if I have missed it

Good question. You didn’t miss it - we’re still streamlining our docs, and not all of this information is captured. I will make a note to add this to the docs though.

BTW, this is a good description of how IPFS hole punching works, if you’re interested in some of the lower level behavior.


great thank you. I can’t seem to get the logs from my ISP to determine what port they blocked, so i’ll look to see how IPFS punches through from the article you mentioned.

I think having a docker container that could be easily deployed somewhere might help users onboard a bit faster.

Yes, we have Docker images too!

The docs are undergoing a major overhaul right now so some of the content might change or move around, but you can find instructions for running Docker images here.

And actually, I found some text regarding ports as well.

1 Like

Thanks for sharing Kevin, we’ll update the docs to reflect this.

Update: PR went out! fix: add text for port security by smrz2001 · Pull Request #274 · ceramicnetwork/docs · GitHub

1 Like

Just chiming here that, indeed, this is a “natural” behavior by IPFS. They (Protocol Labs) are amongst the pioneers of everything peer-to-peer network-wise by building up libp2p, which is used in Ceramic nodes. However, Ceramic recently switched from the JavaScript flavor (js-libp2p) to the Golang version (go-libp2p).

If you want to learn more about hole punching and NAT traversal in general, I can recommend the excellent post by Tailscale, a network software company - How NAT traversal works · Tailscale