Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes
  • Basic Security for Custom Seedboxes

We are the best invite forum on the internet! Here you will find free invites, free seedboxes, free bonuses, and much more. Our members know the true meaning of sharing and have created a truly global bittorent community! Our site has the most up to date information on all private trackers and our members will guide you and introduce you to this truly secretive and enlightened club. Ready to get started? Register now!

Results 1 to 10 of 10
  1. #1

    Default Basic Security for Custom Seedboxes

    Basic Security for Custom Seedboxes
    Ok, I'm going to preface this with saying that I'm not a linux security expert, but I've picked up a few tips over my years of using linux that I figured would be good to share with others who might be using something like a Kimsufi box to run a seedbox of their own.
    Most of this is going to be Ubuntu-centric since that's what I use for my seedbox.

    Limiting Access
    One of the first things you want to do is limit who can access your machine and how. I think there's really two important steps involved: configuring a firewall and limiting SSH access.

    Configuring a firewall
    Under Ubuntu, I would suggest using UFW. UFW is a tool that helps configure the built-in linux firewall iptables.
    To install UFW, run:
    sudo apt-get install ufw
    In order to lock down your box, but allow SSH, HTTP traffic you do this (UFW has to be run as root):
    sudo ufw allow ssh
    sudo ufw allow http
    sudo ufw allow https
    sudo ufw default deny
    sudo ufw enable
    If you want to see your current rules in place type:
    sudo ufw status
    UFW should start automatically to re-apply your rules every time your machine reboots, so once you've set your rules you don't need to set them again (unless you want to change them).
    The general format of adding a opening to your firewall is one of
    sudo ufw allow port-number # Open a port number
    sudo ufw allow start-port:end-port # Open a port range
    sudo ufw allow port-number/tcp # Open a port number only for TCP (can also use ranges)
    sudo ufw allow port-number/udp # Open a port number only for UDB (can also use ranges)
    So if you have services like vsftpd running, you'll want to add those ports to the list. For more information see the UFW ubuntu help page.

    Limiting SSH Access
    You'll probably want to lock down SSH access too. Some guides online will tell you that you should change your default SSH port to help stop brute force attacks, but I don't think it helps. If someone wants to brute force your machine, they'll just do a port scan and find where SSH is, changing the port won't stop them.
    There are a few things you want to make sure you do:

    • Disable root logins
    • Enable RSA Key authentication
    • (Optionally) White list specific users

    To do these things, make sure the following lines appear in your /etc/ssh/sshd_config file:
    PermitRootLogin no # Disables root user login via SSH
    RSAAuthentication yes 
    PubkeyAuthentication yes
    AllowUsers username1 username2 username3 # This line will tell SSH to ONLY allow the listed users to log in
    After you make changes, restart SSHD with 'sudo service sshd restart'

    Checking for Vulnerabilities
    There's a cool tool called 'Tiger' that will run automated checks on your system for vulnerabilities, specifically ones that might help attackers gain root privileges. On Ubuntu you can install with 'sudo apt-get install tiger'. Their home page can be found here: Tiger.
    Once installed, you can run it like so:
    sudo tiger
    It'll take a few minutes to run most likely, but will produce a report in '/var/log/tiger'. Installing Tiger on Ubuntu also sets up a CRON job that runs tiger periodically, if you want to turn that off comment out the last line of the '/etc/cron.d/tiger' file.

    Blocking SSH Attacks
    If your seedbox is in a busy datacenter, or you use it with public trackers (or even private ones really I suppose) people will find out your IP address and those interested in building bot nets or whatever will probably try to attack your SSH daemon (one reason why it's advised to always keep it updated). To help counter that, you can install a package called 'Denyhosts'. Denyhosts will keep an eye on your logs and if an IP address tries to SSH in to your machine unsuccessfully too many times, it will block their IP from connecting. On Ubuntu you can install it with:
    sudo apt-get install denyhosts
    It will run automatically (on ubuntu) and will log to '/var/log/denyhosts'. You can check what IPs are banned by looking at /etc/hosts.deny. On one of my new seedboxes, after 1 day I had 4 IP addresses blocked already.
    Warning: Be careful, if you accidentally try to log in too many times unsuccessfully, you will be blocked! I had this happen and I had to reboot my machine into recovery mode to remove my home IP from the block list

    More Reading
    This isn't really even scratching the surface, but I think it's a start. If you want to read more, here's a few links that I've found useful:
    Securing an Ubuntu Server
    Fail2Ban - Another tool like Denyhosts but more comprehensive. It scans several log files (not just SSH) and will tweak your firewall rules to deny access to people. Doesn't take much more setup, so it's worth checking out.
    Ubuntu's Wiki on Security - Ubuntu centric, but has good advice

    I hope this was helpful to some, if you're running a always-connected linux machine you should do all you can to keep it secure so it doesn't become some bot DDOSing people, or worse, ruining your reputation with your trackers that you worked so hard to get onto.


  2. #2


    Thanks for the post @sirecho some good information and how to's for security...


  3. #3

  4. #4


    Thanks a bunch for this info! I used this on my secondary VPS to lock it down. I am running Ubuntu 11.10.

    One thing I want to add, I had a problem with UFW after installing it - I had no outgoing access from the VPS. I had to run this before it would work:

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

  5. #5


    Very nice post, but as somebody who works in the monitoring department of a VERY large datacenter, I would like to simply recommend using APF + BFD, as opposed to DENYHOSTS and UFW. APF + BFD does the same thing, only in a much easier configurable way. On the thousands of servers that I have logged into, I have never found a server running DENYHOSTS, it's always either APF, or CSF on cPanel servers.

    You can easily lock ports, or hell even limit access to the server AT ALL to every IP accept for yours, which would be difficult if you had a dynamic IP, but you could always allow an entire range. You can even disable ICMP (ping).

    The way that I currently have my dedi set up, is SSH root logins diabled, along with root logins at console (people in datacenter have no business getting into my box ;)). I also have SSH listening on a default port (trust me, majority of brute forcers do not port scan, and even if they do, they get blocked for it because BFD also watches for port scans.), and I have a user that can sudo up. I also have every single port locked down, aside from my torrent port, and my SSH port.

    I would recommend pubkey access though, that's more secure, but the way I have my server set up, is you have to SSH using a user, whose password is quite long, and randomly generated, and then you have to "su -" to sudo up, and then enter root's password, which is even more secure (even longer randomly generated pw). I find this way to be quite secure, and am not concerned about my server being rooted at all.

  6. #6

  7. #7


    Nice post. Has some pretty useful info. Thanks

  8. #8


    very nice post thank you

  9. #9


    Security is very important's always nice when you see security tips..

  10. #10


    Never mind "basic" security.

    What everyone should be doing is password-Less logins using ssh keys. You keep your public key on your server, and you keep your private key on your personal computer as well as back it up somewhere. Then you login with your private key.

    You lock down ssh, no root logins, no password logins.
    Don't use any ftp daemons such as (proftp, pureftp, vsftpd). Use the built in pre-installed Sftp that comes with ssh, and you only use ssh keys to login to that as well. (ive heard ppl say sftp is slower then normal ftp, but i personally havent noticed it & i can max my download connection out.)

    And for those that dont know what all this does, it disable's password login so ppl cant brute force there way in to your server.
    If you dont think there is not a problem with ppl trying to crack your password check your server for failed login attempts daily and see for your self.
    grep Failed password /var/log/auth.log

Similar Threads

  1. Looking for 250gb seedbox for 30USD?
    By vistac in forum Seedbox Discussions
    Replies: 6
    Last Post: November 27th, 2013, 09:03 AM
  2. Best practices for privacy/security from a seedbox?
    By macprivateer in forum Seedbox Discussions
    Replies: 39
    Last Post: November 29th, 2012, 02:50 PM
  3. Looking for FAST! Seedbox...
    By Family Guy in forum Seedbox Discussions
    Replies: 21
    Last Post: August 18th, 2009, 01:43 PM
  4. Looking for a seedbox.
    By Mortivore in forum Seedbox Discussions
    Replies: 0
    Last Post: May 1st, 2009, 03:22 AM
  5. Replies: 6
    Last Post: October 23rd, 2008, 11:11 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts