Category: Network security

An error of networking computers caused in Chile and the United States under the control of the Great Wall of China to come, rerouting of Facebook, Twitter and YouTube users the Chinese servers.

Security experts do not know exactly how it happened, but it seems that at least one supplier has recently started doing high-level DNS (Domain Name Server) information, which as known root DNS server China. This server, operated by China by the Swedish NETNOD returned DNS information for Chinese users are intended to spread efficiently in the network censors in China and abroad. China firmly control access to a number of sites, using technology, popularly known as the Great Wall of China.

The matter was reported Wednesday by Mauricio Erec, a DNS administrator with NIC Chile, which found that ISP unnamed local reported that queries DNS for sites such as Facebook.com, Twitter.com and YouTube. com – all of which have been blocked in China – have been diverted to bogus addresses.

It is unknown how extensive the problem. Erech always false information reported by three access points to the network in Chile and California, but on Thursday he said that the problem does not occur again. “The evidence shows that we have not hit the server in China,” he said to send in a group discussion.

This problem occurs because, for whatever reason, at least one Internet service provider outside the DNS queries sent to a root server located in China, such as network experts. This is something that should make the service outside China, because it allows network censored in China “leakage” outside the country.

Researchers have long known that China has censored DNS routing information has changed for the users of government services functioning of the server instead of redirect sites like Facebook and Twitter. But this is the first version, leaked to these routes outside China, according to Rodney Joffe, a senior technician, DNS services company NeuStar. “Suddenly, the consequences are that people can be defeated outside China or redirected to servers in China,” he said.

From the use of a China-based root servers, ISPs are primarily controlled China, a way to get all the traffic of its users on the network. The serious security problems mean for people, said the network accepts the well-trodden routes could Joffe.

The ISP uses the roads bad probably wrong its BGP (Border Gateway Protocol) system is used to provide information based on the Internet, according to Danny McPherson, chief of security at Arbor Networks. “I do not think it is deliberately,” he said. “This is an example of how easy it is these details are contaminated or are damaged or have fled beyond the borders of what is supposed to be. “

What are network defenses?
At first, the subject of network defenses might seem redundant or very general. However, there’s nothing redundant or general about this area. Network defenses address the issues involved in connecting networks to each other and in operating a network as a whole. Network defenses don’t address things such as external firewalls or dial up connections, since the perimeter security layer covers these. Nor do network defenses cover individual servers and workstations, since the host-defenses layer covers these. Instead, network defenses cover things like protocols and routers.

Internal firewalls
Just because the subject of network defenses doesn’t cover external firewalls, it doesn’t mean that it doesn’t cover firewalls at all. One of the first steps that I recommend taking toward securing your network defenses is to enable internal firewalls where possible. Internal firewalls are basically the same as external firewalls. The main difference is that their primary job is to protect the machine against traffic that is already on your network. There are a couple of reasons for implementing internal firewalls.

First, imagine for a moment that a hacker or a virus was able to manipulate your external firewall in a way that allowed all varieties of traffic to flow through it. Normally, this would mean that it was open season against your network. However, if you had enabled internal firewalls, the internal firewalls would block the malicious packets that the external firewall had let slip through.

The other main reason for enabling some internal firewalls is that many attacks tend to be internal in nature. At first, you might hear this statement and think that an internal attack couldn’t possibly happen on your network, but I’ve seen internal attacks and other security breaches in every company that I’ve ever worked for.

At two of the places that I used to work, people in other departments who were hacker or administrator wannabes thought that it would be cool to probe the network to see how much information they could acquire. In both cases, they had no ill intent (or so they said), they were just looking to impress their friends by hacking the system. Whatever their motivation, they did attempt to break through the network’s security. You’ve got to protect your network from people like this.

In other places that I’ve worked, I’ve seen people bring in unauthorized software that was infected with Trojan horses (remember “Back Orifice”?). These Trojan horses would then broadcast on specific ports. The firewall was powerless to stop malicious packets from entering the network because the packets were already on the network.

This actually brings up an interesting point: Most of the techs I know configure their external firewalls to block all but a few inbound ports and to allow all outbound traffic. I recommend being just as picky with the outbound ports as you are with the inbound ports because you never know when a Trojan horse could be using some obscure port to broadcast information about your network to the world.

Internal firewalls ideally should be placed on each PC and on each server. There are several good personal firewall products on the market, such as Norton’s Personal Firewall 2003 from Symantec. However, you may not have to spend a dime on an internal firewall for your workstations as Windows XP contains its own built in personal firewall.

To enable the Windows XP firewall, right-click on My Network Places and select the Properties command from the resulting shortcut menu to display the Network Connections window. Next, right-click on the network connection that you want to protect and select Properties. Now, select the Advanced tab and then click on the check box in the Internet Connection Firewall section. There’s also a Settings button that you can click to enable any ports that should remain open. Although the Windows XP firewall is intended as an Internet firewall, it works great as an internal firewall as well.

Encryption
The next step that I recommend taking is to encrypt your network traffic. Begin by implementing IPSec wherever possible. However, there are a few things that you need to know about implementing IPSec security.

When you configure a machine to use IPSec, you have the option of configuring IPSec to either request encryption or to require encryption. If you configure IPSec to require encryption, then any machine that the machine attempts to connect to will be informed that encryption is required. If the other machine is capable of IPSec encryption, then a secure channel will be established and the communications session will begin. If, on the other hand, the other machine is incapable of IPSec encryption, then the communications session will be denied because the required encryption can’t occur.

The request encryption option works a little differently. When a machine requests a connection, it also requests encryption. If both machines support IPSec encryption, then a secure channel is established and communications begin. If one of the machines doesn’t support IPSec encryption, then the communications session is established anyway, but the data simply isn’t encrypted.

For this reason, there are a couple of things that I recommend doing. First, I recommend placing all of the servers within a site on a secure network. This network should be completely isolated from the normal network. Each server that users require access to should have two network cards, one for connecting to the main network and the other for connecting to the private server network. The server network should consist of only servers and should have a dedicated hub or switch.

By implementing such a configuration, you create a dedicated backbone between the servers. All server-based traffic, such as RPC traffic and traffic used for replication, can flow across this dedicated backbone. By doing so, you’ve helped to secure the server-based traffic and you’ve increased the amount of available bandwidth on the main network.

Next, I recommend implementing IPSec. For the server-only network, IPSec should be configured to require encryption. After all, this network consists of nothing but servers, so unless you’ve got UNIX, Linux, Macintosh, or some other non-Microsoft server, there’s no reason why all of your servers shouldn’t support IPSec. Therefore, you’re perfectly safe requiring encryption.

Now, for all of the workstations and the server connections on the primary network, you should configure the machines to request encryption. By doing so, you’ve achieved the optimal balance between security and functionality.

Unfortunately, IPSec can’t distinguish between network adapters on multihomed computers. Therefore, unless a server is attached exclusively to the server network, you’ll want to use the request encryption option or else clients may not be able to access the server.

Of course IPSec isn’t the only type of encryption available for your network traffic. You must also consider how you’ll secure traffic that flows through your perimeter and the traffic flowing across your wireless networks.

Wireless encryption tends to be a touchy subject these days because the wireless networking devices are still evolving. A lot of administrators view wireless networks as inherently insecure because of the fact that network packets are flying through the air and anyone with a laptop and a wireless NIC card can intercept those packets.

While there are certainly risks associated with wireless networks, in some ways, wireless networks are even more secure than wired networks. The reason is that the primary mechanism for encrypting wireless traffic is WEP encryption. WEP encryption ranges in strength from 40 bit on up to 152 bit or even higher. The actual strength depends on the lowest common denominator. For example, if your access point supports 128-bit WEP encryption, but one of your wireless clients only supports 64-bit WEP encryption, then you’ll be limited to using 64-bit encryption. These days, however, just about all wireless devices support at least 128-bit WEP encryption.

What many administrators fail to realize is that just because wireless networks use WEP encryption, it isn’t the only encryption type that they can use. WEP encryption simply encrypts whatever traffic is flowing across the network. It doesn’t care what type of traffic it is encrypting. Therefore, if you are already encrypting data with IPSec, as you should be, then WEP will simply provide a second level of encryption to the already encrypted data.

Network isolation
If your company is very big, then there’s a good chance that you have a Web server that hosts the company’s Web site. If this Web server doesn’t require access to a backend database or to other resources on your private network, then there’s no reason to place it on your private network. Why run the risk of someone using a Web server as an entry point to your private network when you can fix the problem by isolating the server into its own network?

If your Web server does require access to a database or to some other resource on your private network, then I recommend placing an ISA Server between your firewall and the Web server. Internet users will communicate with the ISA Server rather than with the Web server directly. ISA Server will proxy requests between the users and the Web server. You may then establish an IPSec connection between the Web server and the database server and an SSL connection between the Web server and the ISA Server.

Packet sniffers
After you have taken the necessary steps to secure the traffic flowing across your network, I recommend occasionally using a packet sniffer to monitor network traffic. This is just a precautionary step because it allows you to see what types of traffic are actually present. If you detect unexpected packet types, you can see where those packets are coming from.

The biggest problem with protocol analyzers is that they can be used as a hacker tool. I used to think that it was impossible to detect someone that was using a packet sniffer on my network because of the nature of packet sniffing. Packet sniffers simply watch traffic flowing across the wire and report the contents of each packet. Since packet sniffers don’t transmit packets, how could you possibly detect them?

It’s actually easier than you might think to detect packet sniffing. All you need is a bait machine. The bait machine should be a workstation that no one knows exists except for you. Make sure that the bait machine has an IP address, but is not a part of a domain. Now, place the bait machine on the network and generate some packets. If someone is sniffing the network, the sniffer will pick up the packets that the bait machine produces. The problem is that the sniffer will know the machine’s IP address, but not its host name. Usually, the sniffer will do a DNS lookup to try to determine the machine’s host name. Since you are the only one who knows about the machine, no one should be doing DNS lookups on the machine. Therefore, if you check the DNS logs and see that someone has been doing DNS lookups on your bait machine, then there’s a good chance that the detected machine is sniffing the network.

Another step that you can take toward preventing sniffing is to replace any existing hubs with VLAN switches. The idea is that these switches create virtual networks between the sender and the recipient of a packet. No longer does the packet flow to every machine on the network. Instead it flows directly to its destination. This means that it would be difficult for someone who might be sniffing the network to get anything useful.

These types of switches have another benefit as well. With a standard hub, all of the nodes fall into a single collision domain. This means that if you have 100 Mbps of total bandwidth, then the bandwidth is divided among all of the nodes. However, with a VLAN switch, each virtual LAN has a dedicated amount of bandwidth that it doesn’t have to share. That means that a 100 Mbps switch could potentially handle many hundreds of Mbps at a time, all on different virtual networks. Implementing VLAN switches will improve both security and efficiency.

As unmanaged, Wi-Fi-enabled smartphones proliferate on corporate networks, network managers should use wireless network access control (NAC) to give them an idea of what’s on the network and how they can secure those devices.

“I talked to a hospital recently that had some sense that they had a lot of smartphones on their network, but they weren’t really sure,” said Jeff Wilson, principal analyst for Infonetics Research. “They thought they had about 8,000 total devices on their network, but when they dropped in [a network access control appliance from] ForeScout, they found that they had 12,000 devices. Most of the devices they hadn’t accounted for were smartphones of all flavors.”

Once network managers understand what devices they have on the network, they need look at their smartphone population as two main groups: company-owned assets that IT has access to, and user-owned devices that employees are using to access email and work with sensitive corporate information.

“You have to look at the world in terms of what are the devices I know about and control and what are the devices I don’t know about and can’t control,” Wilson said. “Then you come up with one strategy that works for devices you know about and one for unknown devices. Whether that will be a way to block all access to those devices or to allow access but find some way to limit and control [access] is up to you.”

Grasping control of the managed smartphones on the network is a matter of collaborating with the mobile device manager in the IT organization. The unmanaged devices will be a bigger challenge, Wilson said, “because you’re not going to physically touch all of them.”

Enterprises can use NAC to discover not only what kinds of devices are out there but which software and which security clients, if any, are running on them, he said. This information can help network managers determine what sort of security policies to implement for unmanaged smartphones.

Bill Perry, the IT services manager for Richard Huish College in Taunton, England, recently installed a NAC product from ForeScout specifically to gain visibility into the number of iPhones and USB devices he had on the network.

“There are many courses here where [professors] teach totally from the network,” Perry said. “If it goes down, they stop teaching. I think the iPhone could come on and bring in something that could affect the operations of the network.”

Perry’s ForeScout appliance is currently in monitoring mode to see what is happening on the network. This month he will start implementing rules and policies to gain control over which devices can access his Cisco wireless LAN and his wired network.

Wireless network access control: What are devices doing?

After taking inventory of the smartphones on the network, network managers need to know how devices are being used.

“An important part is understanding how they are getting used on your network,” Wilson said. “What is it [that] users do with the devices when they’re connected, and what kind of threat does that present? That’s something that using some sort of NAC or application control or discovery product can help you understand.”

“Secondarily, think about the data at rest problem,” he said. “Do we have a policy for what to do if someone’s phone is lost? How do we decide whether I care from an IT perspective if that device is lost? And what is it we can do if we can never see, touch or do anything to handle these devices? How can we protect ourselves assuming we are never going to have access to these devices?”

Turning a blind eye to unmanaged smartphones is a gamble. “We haven’t seen a lot of mobile device-specific exploits yet, but I believe that they are coming. Also, companies that invest specifically in security for smartphones right now [are doing it] because they know there are sensitive data that they would worry about if it’s lost or stolen.”

Out-of-band wireless NAC solutions

Not every NAC solution will afford the same amount of control and visibility into unmanaged smartphones, Wilson said. For instance, NAC products from endpoint protection vendors like McAfee and Symantec may not do much good, given that they rely on client software that the smartphones probably won’t have installed. Microsoft NAP might do a good job of managing Windows Mobile smartphones, but it will have trouble tracking other smartphone platforms. NAC products that track only devices that have 802.1x supplicants will have trouble seeing devices that don’t have this software, particularly smartphones.

“So you’re looking at out-of-band solutions that aren’t limited to 802.1x and use other methods, such as capturing MAC addresses and machine IDs,” Wilson said.

Going beyond smartphone security

NAC has also helped Perry deal with other issues relating to both managed and unmanaged laptops on the network. For instance he’s detected a couple of unmanaged PCs that are scanning his network, particularly password scanning, so he’s trying to track the machines down with ForeScout. He’s not convinced that someone is trying to hack the network, but he’ll know more once he finds the machine.

The technology also helped him find a school-owned loaner laptop that had gone missing.

“We went through the records and could see the last time it was on a network, the person who was using it and the port it was accessed through,” Perry said. “So you can track it down, then go find it. That one was being used by the finance department, and then it was locked away in a cupboard for a month and a half.”