davout
Legendary
Offline
Activity: 1372
Merit: 1007
1davout
|
|
February 06, 2013, 12:09:38 AM |
|
Close all unnecessary ports.
Only open ssh to admin's ip.
[...]
Plan for complete failure and run monthly complete restore runs only from back up.
implement fail over in co-located data centers.
Slightly overkill for the OP if you ask me. While you're at it you might want to add that everything should be hosted in a nuclear bunker. On Mars.
|
|
|
|
|
|
|
|
|
"You Asked For Change, We Gave You Coins" -- casascius
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
|
February 06, 2013, 12:37:54 AM |
|
Close all unnecessary ports.
Only open ssh to admin's ip.
[...]
Plan for complete failure and run monthly complete restore runs only from back up.
implement fail over in co-located data centers.
Slightly overkill for the OP if you ask me. While you're at it you might want to add that everything should be hosted in a nuclear bunker. On Mars. so you have a service for hosting a server on mars? il take 1
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
BCB
CTG
VIP
Legendary
Offline
Activity: 1078
Merit: 1002
BCJ
|
|
February 06, 2013, 12:40:43 AM |
|
yes this is extreme. Additional layers of security can be added with growth of value.
But we've seen it all in bitcoin.
Compromised hosts
exposed public keys
unpatched zero day exploit
trojans
disappearing data that was not backed up.
insider fraud.
If you are dealing with anything of value exposed though an http interface you are vulnerable.
You can never be too safe.
|
|
|
|
madmadmax
|
|
February 09, 2013, 02:21:27 PM |
|
So I'm working on a project that will hold bitcoins and of course, security is the most obvious risk/danger.
On advice of the developer we have a specially compiled version of bitcoind (unnecessary RPC calls have been removed, as well as calls that pose a security risk).
Bitcoind runs under a separate user than the php script. SSH/ftp into the server is only possible with keyfiles.
All mysql calls are escaped so injection should (hopefully) be covered.
A cold wallet is being implemented so the majority of funds are off-site.
What other steps should I be keeping in mind? After some advice from a friend I'm worried as well about somehow the database being compromised in some slight way as to affect imperceptible shifts in balances that I would be unable to detect.
I toyed with the idea of every database entry having a hash generated from all the data and the hash being periodically verified against the database to check for manipulation. But is this realistic?
Anyone have any more ideas? Thank you
I am surprised that such an engine hasn't been developed for commercial websites yet...
|
▄▄▄▄▄ ▄▄▄▄▄ ▄▄█▀▀▀▀▀▀██▄ ▄▄█▀▀▀▀▀▀▀█▄ ▄██▀ ▀██▄ ▄██▀ ▀█▄ ██▀ ▀██▄ ▀▀ ██ ██ ▀██ ▄▄▄▄▄▄▄▄██ ██ ▀██▄ ▀▀▀▀▀▀▀▀▀▀ ██▄ ▄██ ▀██▄ ▄▄▄ ▀██▄ ▄██▀ ▀██▄▄ ▄██▀ ▀▀██████▀▀ ▀▀██████▀▀
| | █ ║ █ | ✔ Unchained Smart Contracts ✔ Decentralized Oracle ✔ Infinitly Scalable
| ✔ Blockchain Technology ✔ Turing-Complete ✔ State-Channels
| █ ║ █ | ▄████▄▄ ▄ ██ ████████████▀ ████▄ █████████████▀ ▀████████▄▄ █████████████ ▄▄█████████████████████████ ██████████████████████████ ▀██████████████████████ █████████████████████ ▀█████████████████▀ ▄█████████████▀ ▄▄███████████████▀ ▀▀▀▀▀▀▀▀▀▀▀
| | ▄██▄ ▄ ▐████ ▄▄ █████ ██████████ █████████████████▀ ▄████████████▀████▌ ██████████ ▀████ ▀▀ █████ ██████████ ▀████▌▄████████████▀ ▄▄▄███████████████▌ ██████████▀ ▐████ ▀▀▀ ████▌ ▀▀▀ ▀███▀
| | f | | █ ║ █ | |
|
|
|
Scrat Acorns
|
|
February 09, 2013, 02:47:34 PM Last edit: February 09, 2013, 03:14:31 PM by Scrat Acorns |
|
All mysql calls are escaped so injection should (hopefully) be covered.
I'd make a habit of using prepared statements exclusively. No handcrafted SQL queries. All your parameters are sent as binary (or escaped automatically in some libs) and there is no need to escape. If you handcraft SQL queries there's a small chance you'll forget to escape something. Agreed that if you are storing information that is sensitive (such as email addresses or other more personal information) then it should be encrypted.
This makes zero sense if the decryption key is stored on the same server.
|
|
|
|
crazy_rabbit (OP)
Legendary
Offline
Activity: 1204
Merit: 1001
RUM AND CARROTS: A PIRATE LIFE FOR ME
|
|
February 10, 2013, 06:27:38 PM |
|
What do people think about this service: http://www.dome9.com/If I am hosting on Amazon Ec2, they can use the API to shut off all the ports all the time, except for when you plan to login. It seems like a nice solution to shut down any open ports, additionally as I have a developer working with me, it allows me to at a later point keep an eye on when they are on the server as well, no?
|
more or less retired.
|
|
|
crazy_rabbit (OP)
Legendary
Offline
Activity: 1204
Merit: 1001
RUM AND CARROTS: A PIRATE LIFE FOR ME
|
|
February 10, 2013, 06:52:58 PM |
|
What do people think about this service: http://www.dome9.com/If I am hosting on Amazon Ec2, they can use the API to shut off all the ports all the time, except for when you plan to login. It seems like a nice solution to shut down any open ports, additionally as I have a developer working with me, it allows me to at a later point keep an eye on when they are on the server as well, no? That is over kill for a bitcoin project, you should close the ports yourself, but 22,80,443 (if you have ssl) also if your worried about logins use ssh keys to login then you can easily remove them and that user could never come in or brute force your password. Why would you need to know when they log on to the server? Well although I trust my developer, I might in the future have additional developers- or even the developer could be compromised in some way I can't know. It seems to make more sense to say, okay can we do this? I'll open the server for this day for updates/fixes, and then have it close again after. I don't have to wonder if the developer/s log back in at a different time after the fix has been done. I know I can close things myself, but I'm a novice. I'd rather know I haven't overlooked something.
|
more or less retired.
|
|
|
BCB
CTG
VIP
Legendary
Offline
Activity: 1078
Merit: 1002
BCJ
|
|
February 10, 2013, 06:54:50 PM Last edit: February 10, 2013, 07:43:42 PM by BCB |
|
What do people think about this service: http://www.dome9.com/If I am hosting on Amazon Ec2, they can use the API to shut off all the ports all the time, except for when you plan to login. It seems like a nice solution to shut down any open ports, additionally as I have a developer working with me, it allows me to at a later point keep an eye on when they are on the server as well, no? crazy rabbit. Great option. Shut down all your ports except 80 and 443 and only allow access to 22 from the single ip or ips that need access. can't get any tighter then that.
|
|
|
|
|