Question Securing a PC/Server for paranoids ?

Status
Not open for further replies.

Herr B

Commendable
May 29, 2020
179
36
1,690
Situation
I am doing a thought game about making a server to manage the own financial situation and do some trading.

I understand, an offline machine would be the safest machine but this kind of defeats the purpose. Please help me find any gaps and/or improvements in my thoughts as well as (if possible) provide some references (videos, books, articles) which I can further research on.
I'm looking forward for your assistance.

System Requirements
Suppose, the system manages Tremendous Funds (what ever this means for you, a few thousand, 100k million, billion whatever). It should therefore be as safe as possible against access from third parties, Natural and Man-Made desasters.
  • The system should be backed up and backups should be stored in a safe manner
  • The system must have some online capability in order to fullfill it's purpose (eg trading cryptos or whatever)
  • The system would at best have some capability to intervene remotely (I understand, this is a huge security caveat but in practice, it is very hard to have on machine access all the time)
My thoughts about security measurements
System
My though was to use a physical Machine with Linux (ubuntu) LTS Server installed. The system should be as clean as possible.

Patching
Updating a system is essential but always updating to the latest version might introduce system instabilities and bugs. It is probably best to enable security updates but disable feature updates

Network and firewall
Network would be best fully disabled for a secure system. Unfortunately this is not always feasible. Wireless Network should be avoided, a cable should be used instead.
The Firewall should be as restrictive as possible. At best only allowing function-essential services. Foreign countries should be blocked off alltogether.
The Machine should not be visible on the network.
Ping etc should be disabled

Datastorage and Backup
An internal storag should be used as opposed to nas. The storage should be encrypted.
Backups should be taken regulairly or after relevant system/data changes. One backup should be stored safely on location in order to restore operation after an immediate failure of the machine or operator screw up.
Further backup should be stored in a remote, safe location providing security against natural desaster.

Remote Access
Remote access should be disabled at best or very restricted.
Laptops can make an easier choice as they have a direct attached screen and keyboard and as such might be easier managed directly. However, they are not designed to run 24/7 under heavy load ( the battery should be replaced after 2-3 years to prevent bloating)

If remote access is absolutely nessesary, it should only be available to immediate network. If access from outside is nessesary, a jump host should be used with trust relationship.
Remote access should not work with passwords. Key-files should be used instead (how to protect keyfile???)

Passwords and User account
The root user should be disabled and not allowed for login.

Usernames should not be easily guessed and should not contain any obvious phrases such as (list just exemplary):
  • admin
  • super
  • root
  • user
The Password should be unique, individual and not easily guessable:
  • The password should be long (length beats complexity) but memorable
  • The password should not be used in any other systems or anywhere else (unique to the system)
  • The password should not be stored in a text file.
    Ideally one would carve the password onto a granite stone but a password manager with strong encryption on a offline media might be sufficient??
  • An account lockout policy should be in place (lock account for x minutes after 3 attemts)
Audits
  • Successful and unsuccessful logon attempts should be audited regularly
  • Upon logon, the last successful logon time should be displayed
  • A software could audit running Processes, services and corresponding ports, Log changes thereof.
  • A software could log File changes (excluding logfiles) and Log there changes
 

Aeacus

Titan
Ambassador
Based on your needs, and rather than setting up the system and all the infrastructure up by yourself, i suggest that you instead partner with any of the data centers, who offer mind blowing security and who already have established and carefully monitored infrastructure in place. They are also the best when it comes to the protection of theft and natural disasters.

Further reading 1: https://datacentremagazine.com/data-centres/top-10-underground-data-centres
Further reading 2: https://www.softwaretestinghelp.com/data-center-companies/

Contact a firm you like and make out a deal with them. Or the very least, you can consult them to set up your own, since they are the leading edge in the world, when it comes to data protection.
 
  • Like
Reactions: Herr B
Would also concur getting a company that provides this service to do this for you, rather than you trying to do setup your own thing. It's easy to overlook something if you're not willing to spend the time really digging into things or know what to look for.

Though to tickle my brain a bit, I did want to address some of these requirements.

My though was to use a physical Machine with Linux (ubuntu) LTS Server installed. The system should be as clean as possible.
This would also require going through what preinstalled packages come with the server and removing everything you don't need.

Updating a system is essential but always updating to the latest version might introduce system instabilities and bugs. It is probably best to enable security updates but disable feature updates
Actually most people who run high-uptime servers don't update to the latest and greatest right away. They have a test server that they apply updates to and makes sure that everything still works. While keeping up with security is important, it's also important to assess the risk of any vulnerability to see if it's low enough for you to stall an update. The next worst thing to a security breach is downtime.

Network would be best fully disabled for a secure system. Unfortunately this is not always feasible. Wireless Network should be avoided, a cable should be used instead.
What do you mean "fully disabled"?

The Firewall should be as restrictive as possible. At best only allowing function-essential services. Foreign countries should be blocked off alltogether.
This won't stop a foreign adversary from hopping to a domestic node and tapping into your computer. If this isn't supposed to be a publicly available computer, you should whitelist which IP addresses are allowed to initiate communication.

The Machine should not be visible on the network.
Not possible. Computers have to announce themselves on the network for routers to work.

Ping etc should be disabled
This can be done.

Remote access should be disabled at best or very restricted.
Sure, use an SSH server and make it listen to something other than port 23. I believe you can also set it up for IP whitelisting.

If remote access is absolutely nessesary, it should only be available to immediate network. If access from outside is nessesary, a jump host should be used with trust relationship.
Remote access should not work with passwords. Key-files should be used instead (how to protect keyfile???)
Honestly, remote access should be required, unless you're absolutely certain you can be physically present should the server need servicing. And if you can't remote into your server, something else has gone horribly wrong.

In any case, yes, you can use key files in place of a password and those key files can be made to require a password to use. PuTTY has a companion tool that lets you generate an RSA key-pair for this purpose (you give the server the private key and you use the public key to log in)

  • The password should not be used in any other systems or anywhere else (unique to the system)
Your password system shouldn't even know that duplicates are being used. It's also a potential security issue if someone tries a password and it responds with "this password is already in use."

  • The password should not be stored in a text file.
    Ideally one would carve the password onto a granite stone but a password manager with strong encryption on a offline media might be sufficient??
I'm guessing you don't want people writing down their passwords? Well, that's something the system can't stop.

Password management should be left to the user. The system should not know anything about a user's password other than what it is. And even then, most password systems don't even know what the plaintext password is, as the password goes through a series of convolutions to scramble it before the password system sees it.

  • An account lockout policy should be in place (lock account for x minutes after 3 attemts)
If you want to do this sure, but a lot of login systems these days will add delays between authenticating and reporting a problem if the password is incorrect.

Audits
  • Successful and unsuccessful logon attempts should be audited regularly
  • Upon logon, the last successful logon time should be displayed
  • A software could audit running Processes, services and corresponding ports, Log changes thereof.
  • A software could log File changes (excluding logfiles) and Log there changes
Is auditing something you're willing to do manually?
 

Aeacus

Titan
Ambassador
This topic is actually quite interesting and i couldn't help myself to pitch in a bit. :sweatsmile:

This would also require going through what preinstalled packages come with the server and removing everything you don't need.

That, or getting Debian which is essentially barebones GNU/Linux distro.

What do you mean "fully disabled"?

I guess OP meant offline PC. But then it has 0 functionality for the task OP wants it.
 

kanewolf

Titan
Moderator
Your password system shouldn't even know that duplicates are being used. It's also a potential security issue if someone tries a password and it responds with "this password is already in use."
Minimum complexity standards need to be enforced. Twelve character minimum with no more than two repeating characters and 90 day expiration. Keep record (hash etc) of 25 previous passwords to prevent reuse.
 
  • Like
Reactions: Eximo

Eximo

Titan
Ambassador
I was just writing something like that. How many many places have all used the same password policy. There are some smart programmers out there who have been able to rule out passwords that people aren't likely to enter, and the general structure of passwords that these policies generate.

Numbers are always moving, but 8 characters is basically under an hour to crack, and something like 5 years for 10 characters.
 
Minimum complexity standards need to be enforced. Twelve character minimum with no more than two repeating characters and 90 day expiration. Keep record (hash etc) of 25 previous passwords to prevent reuse.
Not sure that the repeating shtick is a good thing. In effect, putting rules in place that prevent using a completely random password is a big weakness.
Remember that this is what did the Enigma machine in
 

kanewolf

Titan
Moderator
Not sure that the repeating shtick is a good thing. In effect, putting rules in place that prevent using a completely random password is a big weakness.
Remember that this is what did the Enigma machine in
But a completely random password can't be memorized easily. It would have to be recorded somewhere. At least with minimum length and basic complexity standards, a human recognizable password can be created that still requires a lot of time to brute force crack. These are standard password guidelines for secure environments.
 

Eximo

Titan
Ambassador
Not sure that the repeating shtick is a good thing. In effect, putting rules in place that prevent using a completely random password is a big weakness.
Remember that this is what did the Enigma machine in

Minimum length is one thing. If I recall the best passwords are just long and can even include dictionary words. But you can follow the rules and still have a good password.

17*StarsJumpOverALongBridge

The problem with some of the rulesets out there you end up with 6GoPatriots!
 
But a completely random password can't be memorized easily. It would have to be recorded somewhere. At least with minimum length and basic complexity standards, a human recognizable password can be created that still requires a lot of time to brute force crack. These are standard password guidelines for secure environments.
Sure, but in the publically knowed real world examples, these things are not attacked by brute force, but by an elimination algorythm based on ’cribs’.
Even modern computers would not be practical in attacking an Enigma machine ( a 1920 design) by brute force
 
Sure, but in the publically knowed real world examples, these things are not attacked by brute force, but by an elimination algorythm based on ’cribs’.
Even modern computers would not be practical in attacking an Enigma machine ( a 1920 design) by brute force
The Enigma is actually pretty weak in terms of possible combinations. Assuming 4 rotors and 4 plug board wires, you end up with 26^4 * (26! / (4! * 22!)) = 6,831,791,200 configurations (permutation of the rotors times the combination of the plug board, including self plugs). Compared to DES with a 56-bit key size which leaves you with over 72,057,594,000,000,000 configurations, and DES can be cracked within a month, though 15 days on average, on something as powerful as a GTX 1080 Ti.

Minimum complexity standards need to be enforced. Twelve character minimum with no more than two repeating characters and 90 day expiration. Keep record (hash etc) of 25 previous passwords to prevent reuse.
My comment is more addressing the idea that every user has a unique password, which is how I interpreted the requirement.
 
Passwords are passe. A smartcard coupled with biometrics (fingerprint AND retinal scan) eliminates such things as passwords being written down and left where they can be found and stops the brute force password crackers in their tracks. Even if the card is left laying around or lost it can't be used by itself. And the biometric data isn't stored on the card and so can't be compromised in that fashion.
 
Situation
I am doing a thought game about making a server to manage the own financial situation and do some trading.

I understand, an offline machine would be the safest machine but this kind of defeats the purpose. Please help me find any gaps and/or improvements in my thoughts as well as (if possible) provide some references (videos, books, articles) which I can further research on.
I'm looking forward for your assistance.

System Requirements
Suppose, the system manages Tremendous Funds (what ever this means for you, a few thousand, 100k million, billion whatever). It should therefore be as safe as possible against access from third parties, Natural and Man-Made desasters.
  • The system should be backed up and backups should be stored in a safe manner
  • The system must have some online capability in order to fullfill it's purpose (eg trading cryptos or whatever)
  • The system would at best have some capability to intervene remotely (I understand, this is a huge security caveat but in practice, it is very hard to have on machine access all the time)
My thoughts about security measurements
System
My though was to use a physical Machine with Linux (ubuntu) LTS Server installed. The system should be as clean as possible.

Patching
Updating a system is essential but always updating to the latest version might introduce system instabilities and bugs. It is probably best to enable security updates but disable feature updates

Network and firewall
Network would be best fully disabled for a secure system. Unfortunately this is not always feasible. Wireless Network should be avoided, a cable should be used instead.
The Firewall should be as restrictive as possible. At best only allowing function-essential services. Foreign countries should be blocked off alltogether.
The Machine should not be visible on the network.
Ping etc should be disabled

Datastorage and Backup
An internal storag should be used as opposed to nas. The storage should be encrypted.
Backups should be taken regulairly or after relevant system/data changes. One backup should be stored safely on location in order to restore operation after an immediate failure of the machine or operator screw up.
Further backup should be stored in a remote, safe location providing security against natural desaster.

Remote Access
Remote access should be disabled at best or very restricted.
Laptops can make an easier choice as they have a direct attached screen and keyboard and as such might be easier managed directly. However, they are not designed to run 24/7 under heavy load ( the battery should be replaced after 2-3 years to prevent bloating)

If remote access is absolutely nessesary, it should only be available to immediate network. If access from outside is nessesary, a jump host should be used with trust relationship.
Remote access should not work with passwords. Key-files should be used instead (how to protect keyfile???)

Passwords and User account
The root user should be disabled and not allowed for login.

Usernames should not be easily guessed and should not contain any obvious phrases such as (list just exemplary):
  • admin
  • super
  • root
  • user
The Password should be unique, individual and not easily guessable:
  • The password should be long (length beats complexity) but memorable
  • The password should not be used in any other systems or anywhere else (unique to the system)
  • The password should not be stored in a text file.
    Ideally one would carve the password onto a granite stone but a password manager with strong encryption on a offline media might be sufficient??
  • An account lockout policy should be in place (lock account for x minutes after 3 attemts)
Audits
  • Successful and unsuccessful logon attempts should be audited regularly
  • Upon logon, the last successful logon time should be displayed
  • A software could audit running Processes, services and corresponding ports, Log changes thereof.
  • A software could log File changes (excluding logfiles) and Log there changes

Sounds like a school project. This is NOT a one man setup. You have to have experts on many levels from edge network configuration, firewall rule experts, cryptography, redundancy, backup specialist, database experts, VPN configuration experts and more. You'll need to setup honeypots, and run a professional firewall. (something like pfSense with Sericota, SNORT, and more.) You'll also need redundancy (fail over)

When dealing with the kind of people crypto attracts (hackers/state actors) you do NOT mess around.

But as a topology you would need:

Professional Router -> Firewall rules -> Honeypot machine & WebAPI machine in DMZ with very limited port forwarding

Anything past this point is on a subnet that only accepts webapi calls to one or two ports for the servers in the DMZ. Transaction processor that only has 3 ports open. One for DMZ request, one for database, one for backup/logging. Another PC for database & logging with incremental offline backups. Only ports are for transaction request and backup machine. Backup machine should do offline backups to tape.

All database password stores should be HASH only. Each login is tracked to an IP. Real security nuts will throw alarms and require 2FA if an account has unusual activity from a geo difference source IP. Large spikes in traffic or attacks on honey pot, should also have a paging notification service for your security team to go over logs (sericota)

ABSOLUTELY NO WIFI
 
Last edited:
Minimum length is one thing. If I recall the best passwords are just long and can even include dictionary words. But you can follow the rules and still have a good password.

17*StarsJumpOverALongBridge

The problem with some of the rulesets out there you end up with 6GoPatriots!

This was a skit about this by a famous comedian. He kept putting out passwords and then modified it to meet requirements. He added "!" to the end. or "1" And then there was laughter from the audience because they all do the same thing. And then he tacked on "And I bet a bunch of you will change your passwords when you get home"
 
Status
Not open for further replies.