Prevent the computer screensaver from locking the console

When you add functionality, you add vulnerability. This is true whether your network powers a small business, or a Fortune 500 company. This is true whether you are looking at a single Lan, or a world-wide Wan. Every piece you add brings with it risk.

We use controls to mitigate risk. Mainly these are directive, preventative, and detective controls. Directive or policy controls define appropriate use of the system. Sometimes people will follow these policies, sometimes they will not. Of course, technology allows us to set permissions and therefore implement preventative controls to keep people from doing certain things. For the times when people do not follow policy and the system does not (or cannot) stop them, detective controls are there to leave an audit trail.

When we add functionality, we need to consider these controls. Now let us work our way from cables to computers.

When deploying a network switch and cabling, ask, how could this break? What can we do to protect it? Consider fault-tolerant designs such as full-mesh for connecting multiple switches and cabling with Fibre instead of copper. Consider directive controls to specify who can access the switch and how. Consider preventative controls such as locked rooms and climate controls. Consider detective controls such as check-in forms and electronic monitoring.

What are Ethernet’s risks and what controls are available? Directive controls could include specifying how a computer gets connected to the Ethernet Lan. It could also specify who is allowed to run sniffers. The preventative controls would be locking down the switch ports to specific Mac addresses, thereby making it difficult to connect a computer without first following procedure. Consider enabling the switch manufacturer’s protection against ARP cache poisoning, such as Cisco’s Dynamic ARP Inspection. Detective controls enabling the switch’s audit logs, and regularly scanning for network cards in promiscuous mode with tools like Sentinel.

What about IP’s risks and controls? Design IP networks to address concerns about addressing and fragmentation. Use directive controls to specify who can access what IP and Internet resources, and who is responsible for addressing and naming. Preventative controls include securing Dhcp address servers and Wins/Dns name servers. Detective controls include auditing and logging. Monitor for IP address and name conflicts, and excessive traffic to Wins/Dns.

Good design along with proper controls will protect integrity and availability. All along, we have been assuming that there is no confidentiality. We have suggested that the place for this is in applications (application, presentation, session, transport layers). Ask your vendors for recommendations on how to securely run their applications. First build a solid network infrastructure, and then turn your attention towards securely delivering applications over it.

The Internet Protocol or IP is what makes the World Wide Web go around. IP packet is divided up into the header and the data.

The IP header has fields such as the source and destination IP address, and fragment offset. What can go wrong here? We’ll use the typical Alice and Bob for two people on a network.

Take the example of Alice’s computer talking to Bob’s. Alice’s will use a name service to look up the IP address, like DNS or WINS. If all is well, then this name service sends back an IP address. Alice’s computer builds a packet with this address as the destination. But can you trust the name service? No, of course not. An attacker can poison these services with incorrect information. Alice’s packet could be sent to the attacker’s machine.

But let us suppose that we are using only IP addresses, without any names or name services. This makes more work for the Alice and Bob, of course, but remembering a few IP addresses is a small price to pay for security. Right? Ok, to prevent poisoning we skip the name lookup and instead send a packet to Bob’s computer’s IP address.

When the response arrives, Alice looks to see if it came from Bob. From the source address alone, can she be certain who sent this packet? No. Attackers can falsify or spoof their IP addresses. Now if the attacker is outside the network, he could pretend to be a computer on the inside. This might fool a router or firewall into allowing the connection. The packet with Bob’s address could really be from anyone inside or outside the network.

The fragment offset field can also be misused. The idea here is networks have a maximum size for the packets transmitting packets. When a packet exceeds this maximum transmission unit (MTU), the router fragments the packet. The offset is the number of bytes into the packet. The destination computer then uses the offset field to reassemble the packet. Just like IP addresses, an attacker can falsify the fragment offset.

Fragmentation can be used to hide data or attack availability. For instance, say you are watching the router for some bad command (like format C:). At attacker could send this in two fragments, “form” and “at C:”.  Other ways are to send fragments with offsets that overlap or send only the initial fragment without the rest of the packet. These can confuse the OS, chewing up memory and eventually make the computer unavailable.

This is significant because to spoof Bob’s computer, the attacker will first have to knock Bob off the network. An IP address has to be unique on a segment and hence only one computer can use the address at a time.