Client Server socket security

Assuming we have a server S and a few Clients (C) and whenever a client update a server, an internal database on the server is updated and replicated to the other clients. This is all done using sockets in an intranet environment. I believe that an attacker can fairly easily sniff this plain text traffic. My colleagues believe I开发者_StackOverflow社区 am overly paranoid because we are behind a firewall.

Am I being overly paranoid? Do you know of any exploit (link please) that took advantage of a situation such as this and what ca be done differently. Clients were rewritten in Java but server is still using C++. Any thing in code can protect against an attack?

Inside your company's firewall, you're fairly safe from direct hack attacks from the outside. However, statistics that I won't trouble to dig out claim that most of the damage to a business' data is done from the INside. Most of that is simple accident, but there are various reasons for employees to be disgruntled and not found out; and if your data is sensitive they could hurt your company this way.

There are also boatloads of laws about how to handle personal ID data. If the data you're processing is of that sort, treating it carelessly within your company could also open your company up to litigation.

The solution is to use SSL connections. You want to use a pre-packaged library for this. You provide private/public keys for both ends and keep the private keys well hidden with the usual file access privileges, and the problem of sniffing is mostly taken care of.

SSL provides both encryption and authentication. Java has it built in and OpenSSL is a commonly used library for C/C++.

Your colleagues are naïve.

One high-profile attack occurred at Heartland Payment Systems, a credit card processor that one would expect to be extremely careful about security. Assuming that internal communications behind their firewall were safe, they failed to use something like SSL to ensure their privacy. Hackers were able to eavesdrop on that traffic, and extract sensitive data from the system.

Here is another story with a little more description of the attack itself:

Described by Baldwin as "quite a sophisticated attack," he says it has been challenging to discover exactly how it happened. The forensic teams found that hackers "were grabbing numbers with sniffer malware as it went over our processing platform," Baldwin says. "Unfortunately, we are confident that card holder names and numbers were exposed." Data, including card transactions sent over Heartland's internal processing platform, is sent unencrypted, he explains, "As the transaction is being processed, it has to be in unencrypted form to get the authorization request out."

You can do many things to prevent a man in the middle attack. For most internal data, within a firewall/IDS protected network you really don't need to secure it. However, if you do wish to protect the data you can do the following:

1. Use PGP encryption to sign and encrypt messages
2. Encrypt sensitive messages
3. Use hash functions to verify that the message sent has not been modified.

It is a good standard operating proceedure to secure all data, however securing data has very large costs. With secure channels you need to have a certificate authority, and allow for extra processing on all machines that are involved in communication.

You're being paranoid. You're talking about data moving across an, ideally, secured internal network.

Can information be sniffed? Yea, it can. But it's sniffed by someone who has already breached network security and got within the firewall. That can be done in innumerable ways.

Basically, for the VAST majority of businesses, no reason to encrypt internal traffic. There are almost always far far easier ways of getting information, from inside the company, without even approaching "sniffing" the network. Most such "attacks" are from people who are simply authorized to see the data in the first place, and already have a credential.

The solution is not to encrypt all of your traffic, the solution is to monitor and limit access, so that if any data is compromised, it is easier to detect who did it, and what they had access to.

Finally, consider, the sys admins, and DBAs pretty much have carte blanche to the entire system anyway, as inevitably, someone always needs to have that kind of access. It's simply not practical to encrypt everything to keep it away from prying eyes.

Finally, you're making a big ado about something that is just as likely written on a sticky tacked on the bottom of someone's monitor anyway.

Do you have passwords on your databases? I certainly hope the answer to that is yes. Nobody would believe that password protecting a database is overly paranoid. Why wouldn't you have at least the same level of security* on the same data flowing over your network. Just like an unprotected DB, unprotected data flow over the network is vulnerable not only to sniffing but is also mutable by a malicious attacker. That is how I would frame the discussion.

*By same level of security I mean use SSL as some have suggested, or simply encrypt the data using one of the many available encryption libraries around if you must use raw sockets.

Just about every "important" application I've used relies on SSL or some other encryption methodology.

Just because you're on the intranet doesn't mean you may not have malicious code running on some server or client that may be trying to sniff traffic.

An attacker which has access to a device inside your network that offers him the possibility to sniff the entire traffic or the traffic between a client and a server is the minimum required.
Anyway, if the attacker is already inside, sniffing should be just one of the problems you'll have to take into consideration.

There are not many companies I know of which use secure sockets between clients and servers inside an intranet, mostly because of the higher costs and lower performance.