pudding wrote:Ok, forget about the money transaction part of it, let's just focus on preventing attacks on data stored on the server.
Excellent. Focusing on specific issues really does help - it lets you get a specific answer to a specific situation. Asking the general question "Will I be secure" is always a bad start.
pudding wrote:
Would a system like the following be secure:
Internet -> Firewall -> Public FreeBSD Server -> Firewall -> Private FreeBSD Server
Here you have seperated access and priveldge - thats a great step to take. By putting the confidential data on the private server, you've ensured that you can "lock" access to just the Public server. By doing so, you are increasing the complexity of the attack - the attacker now needs to gain some level of access on the public server.
Firewalls are popular, and they arent bad, but think of them as what they are - a filter. They reduce the NUMBER of ports and the NUMBER of source/destination pairs. That makes it much easier to reduce the potential number of attacks. However, it makes the need for a solid Intrustion Detection System much higher.
Why? Because now the traffic is "normalized". It all looks very similar. All coming from the public server, to the private server. Probably all on one or two ports. Same IP, same ports. Even if it were un-encrypted, the data is likely to look extremely similar - even for an attack! So you will definitely want some form of IDS.
There are competing schools of thought on whether it should be host-based, or network-based, or both. Each has strengths and weaknesses. The key for you is that the weak point of your diagram is the public server. It's the beachhead that MUST be defended. If I was implementing it, I would definitely have a Network-IDS (NIDS) on the red-zone firewall (outside the public server). I would also have a Hostbased-IDS (HIDS) on the public server. Snort, and tripwire would work just fine, and cost you nothing.
I'm sure someone will talk about OS choices, and let me give you my stock answer. You should run the OS you are most familiar with. The native security of a completely-locked-down windows box and an OpenBSD box are not equal, but with a competent administrator, they can approach a similar security level. However, ANY box that you are not familiar with will be inherently less secure regardless of security features, architecture, or anything else.
pudding wrote:
This way no data can be accessed directly.
Slight correction - the data isnt being accessed directly from the internet to the data. You've put obstacles in the way. Thats good - security is mostly about making the cost of the attack much higher than the value of the compromise. In the case of a credit database with multi-million dollar account totals (ala PayPal), they are willing to spend millions to protect it.
The extra steps are good, but with some caveats..
pudding wrote:
Would this be fairly secure? Or would it need more? Something special?
You didn't mention much about the firewalls. I would highly suggest that they be a non-freebsd firewall. If possible, a firmware-driven solution, that is harder to change.
Why? Because that way the attacker needs to know more than just FreeBSD. If the firewalls were also FreeBSD, and he knew an exploit that you didn't, he would have control of every piece of the roadmap!
However, if the firewalls were say, Linux, or Windows ISA servers, then suddenly the attacker needs to know two somewhat different systems to 'completely' fool you. There is an element of difficulty there - again, we are raising the cost. Now, he needs to know an exploit for FreeBSD, AND a Linux exploit - both of which that you DONT know. On top of that, he has to figure out how to get to the data in the private system (which might be easy or not).
Even better would be to deeply vary everything. Have OpenBSD for the Firewalls, have Linux for the private server, and FreeBSD for the public server. Now he has to know three very different unix-like OS's. Possible, but challenging, for sure.
There are plenty of "extras" you could add. Encrypt the data on the public system with a dual-key system. You have to have the key from the public server AND the private system to decrypt it. Tricky to implement, wonderful security though.
You could ensure that you used SSL for each point-to-point connection. That way even if they get the firewall, they cant sniff traffic.
You could do stringent IP blocking on the firewalls - thats an implementation detail that shouldnt be assumed by saying "I have a firewall". Firewall design alone can take years to get right.
All in all, there are dozens of things you could add. But in general, yes, the architecture you described is an excellent start towards a secure infrastructure for storing private data.
All of that being said - its a horrible thing to choose to do. One breech of your security, and the law can literally bankrupt you. Read up on California Information Practices Act - SB1386. Its groundbreaking stuff, and it really sticks it to business owners that don't protect customer data properly.
There are businesses that will outdo anything you can design, and for far less money.. a monthly fee in exchange for no chance of a lawsuit is an excellent security and business decision.