search

solusipse / fiche

Command line pastebin for sharing terminal output.
http://termbin.com
MIT License
1.4k stars 166 forks source link

How do I stop this? #120

Open roughnecks opened 9 months ago

roughnecks commented 9 months ago

https://termbin.woodpeckersnest.space/b305/

https://termbin.woodpeckersnest.space/bik5ji/

https://termbin.woodpeckersnest.space/r77f/

Thanks

msva commented 9 months ago

ask your users to stop that :shrug: or password-protect the site

roughnecks commented 9 months ago

These are robots

martin-braun commented 8 months ago

A good way to solve would be to have a different domain for the receiver, so people can't really attach the main service by spamming. However, that's security through obscurity. @roughnecks Look into rate and request size limiting via firewall / load balancer, so people can't abuse it.

roughnecks commented 8 months ago

A good way to solve would be to have a different domain for the receiver, so people can't really attach the main service by spamming. However, that's security through obscurity. @roughnecks Look into rate and request size limiting via firewall / load balancer, so people can't abuse it.

Hi, do you mind explaining the "different" domain setup, because I actually own 2.

roughnecks commented 8 months ago

"Rate and request limiting". okay but it would only stop the spam after N requests, right? Not really a good solution this one too.

roughnecks commented 8 months ago

or password-protect the site

How can users access their pastes if I password protect the site?

martin-braun commented 8 months ago

@roughnecks I deleted my comment to rephrase, there was a mistake on my end in regards of shadowing your service.

The obscurity path is to have two containers, your public domain needs to point to the container without 9999 port forwarded. It needs to a run a reverse proxy that proxies to the secret container, that is actually port forwarding only 9999. Then you have both domains do different things. I was hoping it can be done with one container only, but as soon as you forward 9999, it will be available for all domains that point to that machine, because a reverse proxy can only work for the HTTP(S) protocol afaik.

In regards of the better solution "rate limiting" and "request limiting", yes, it will not prevent strangers from using the service, but it will limit the potential of abuse. Don't know in the top of my head how to rate limit a port though.

A solution of the problem is to not expose 9999 at all and pipe your content into a temporary file, scp it to your server and use a ssh command to nc it into 9999 locally. Then your service is protected via SSH, there you have it. Just a little bit of scripting should do the job.

martin-braun commented 8 months ago

Untested idea out of my head:

( 
  ssh-add
  tmp="$(mktemp)"
  remoteauth="user@remote"
  remotetmp="$(ssh "$remoteauth" mktemp)"
  echo "just a test" > "$tmp"
  scp "$tmp" "$remoteauth:$remotetmp"
  ssh "$remoteauth" cat "$remotetmp" | nc localhost 9999; rm "$remotetmp"
  rm "$tmp"
)

Don't copy paste, test carefully and adjust. Also add your identity via ssh-copy-id, so you don't have to enter your password multiple times.