I am using the BBB for backup (via BTSync, this also gives me some troubles lately, but that is a different story…). I am thinking of bringing the BBB to work (at a university) to get a real off-site backup. However, I am not sure what steps I should take in order to make sure nobody can access my files there. So my questions are:
What should I do to make sure it is secure? I think I would even be happy only to access it via USB and the webserver of BTsync (port 8888)
What services could I shut off? I don’t need the GUI, the webserver, could probably lock down many ports and other services I do not even know that they are currently running…
Potentially I could also hook the BBB to my computer via USB and share Internet with it. Would that be a more secure option?
Ps: I tried to search the group/internet, but interestingly it seems not to be a big question out there…
I been running a linux webserver in the wild open internet since 1996.
if you keep your distro uptated
and have a strong password you will be fine.
remove packages you do not need to further secure your system.
I have Iptabled all of china, russa and a few other places due to loads
of attacks but after my one hack in the late 90s
i have been hack free.
Now if i could eliminate
Just some quick points, as you could spend a lot of time/research into
Physical access = root access... Unless you physcally modify the board
with a gallon of hard epoxy and seal it in concrete. The board was
designed for ease of development...
By the default, the bb.org image has root access open (no password)
and ssh on port 22..
There's a script under:
That'll reset root to a password (root) and disable root over ssh.
Next disable bone101/cloud9 both applications give you root access to.
BTW, for this project, starting with something really bare bones such as:
You cant apt-get update && apt-get upgrade . . .
apt-get install x.y.z, but until you understand the OS completely you’ll never feel good. Best practices - Only install what you need and completely understand what you install. Anything potentially facing the internet is at risk - period…
The long standing bash exploit ( 19+ years ) is a perfect example of that.
BTW, any who cares, Deian is one of the oldest, and most reliable distro’s - period, even it was susceptible to this bash exploit. The only thing you can do in any case short of locking this device up in a closest with no power is keep up to date with the technology you’re using.
A “real hacker” doesn’t care about your system only the data it presents to him / her. The rest are script kiddies, and generally easy to foil.
If you really must keep up to date . . . .- http://threatpost.com/
and . . . http://goto.fail/blog/2014/11/25/at-and-t-u-verse-vap2500-the-passwords-they-do-nothing/
Some ppl just don’t “get it”.
Anyway, the moral of my long winded story ? If you do not trust it, do some research on your own . . .
Thanks for your suggestions. I will look more into it. I am aware that full security is not achievable, I wanted more to make sure that there is no super easy way in where everyone could just see whatever they want to.
Also that was my point about removing/disabling unused features. Then I do not need to keep them up to date when they are not present any more.
First, have ONLY one user account, and be sure ROOT can’t be logged into from the net.
Two, install denyhosts, and set a very restrictive policy, like two failed login attempts within
two weeks and that IP is locked out for 6 months. I used to get 1000 login attempts a day.
The botnets actually did a scientific probing sequence to find out what the horizon of the
lockout was, and once they determined it remembered failed logins for a two week window,
immediately the attempts fell off to about 2 a day! denyhosts was the best security
thing I ever found to deter the hackers.
Of course, shut down all unnecessary services.
99% of security issues are going to be from using weak( or no paswd ) passwd’s, and social engineering. An added step I do is remove the default debian user, and add my own user. Of course anyone whose read my blog posts, or has seen me paste commands etc, including my username, but obviously id change that when the image went true production.
Anyway, security through obscurity is really not security at all, and security really depends on what you need / do. Somethings like forking processes for instance can potentially be a security risk. But when you’re unsure, google x.y.z + debian + security, and 9 times out of 10 you’ll get some decent information.
There really is so much to cover that you’re never going to get a full understanding just from a single thread on these groups. Oh, and like the last user said, remove root. Or rather just disable root, after it is no longer needed as such:
$ sudo passwd -l root
I think that is right . . . also for what it’s worth, hosts.allow, and hosts.deny is deprecated on the most recent Debian releases . . .
Here’s what I’d do for a secure personal use only system:
- Start with a minimal installation as Robert suggested, changing passwords/usernames, and installing only what is required.
- Setup my user to use ssh key pair authentication.
- Confirm it works.
- Disable ssh root login, and password authentication.
- Setup iptables to disallow all connections from any host except localhost, but open ssh to almost any host.
- Then, on the local machine run:
ssh -L 8888:localhost:8888 <username>@<host>
to set up port forwarding.
- BTsync would then be directed to connect to localhost:8888. Backups would run as long as the ssh tunnel is active. You may have to mess with the ports used to keep the copy of BTsync running locally from interfering with the port forwarding.