Top five network security concerns

Securing a computer network requires mastery of many skills and concepts -- network design, device configuration, protocols, etc. As an expert on sister site, Mike Chapple, CISSP, answers end users questions on these topics and more. We've compiled the five most popular questions to help you better address your customers' needs.

Securing a computer network requires mastery of many skills and concepts -- network design, device configuration, protocols, etc. As an expert on sister site, Mike Chapple, CISSP, answers end users questions on these topics and more. We've compiled the five most popular questions to help you better address your customers' needs..

CLIENT CONCERN #1------------------------------------------------------------

What issues can arise if there are IP phones on a network that uses 802.1x? What if, behind the phones, there are connected PCs that share the same switch port? 

Voice over IP (VoIP) telephony technology is beginning to replace traditional PBX (private branch exchange) telephony in the enterprise. Last year, discussed Cisco's move toward quadplay convergence -- putting data, voice, video and mobile communications on the same network. And you're right to question the security issues of such an arrangement.

When deploying VoIP on an 802.1x network, a significant issue is the use of the Ethernet port. Most VoIP phones provide this port so that a client PC can connect to the network. If you're using 802.1x, make sure that the switch is configured to allow multiple devices on the same port. Otherwise, only the first device to establish a connection -- the phone or the PC -- will be able to access the network.

You'll also need to take measures to protect against a new kind of eavesdropping threat. By placing your voice traffic on the same network as your data traffic, it's exposed to confidentiality risks not seen on a traditional voice network. Now, if your security controls aren't up to par, any computer on your network has the potential to become an eavesdropping device. For that reason, not only should VoIP traffic be placed on a separate VLAN, but you also need to consider the security of the VLANs themselves. Read Combining 802.1x and VLANs for advice on implementing VLAN segregation, or check out Popular VLAN attacks and how to avoid them for tips on securing your VLAN implementation.

More information:

  • Visit's VoIP security topics page.
  • Check out our voice over WLAN topics page.

    CLIENT CONCERN #2------------------------------------------------------------

    Is it possible to get the following data from a Snort intrusion detection system (IDS)?

    1. Number of packets that Snort receives from one destination only
    2. Number of packets that Snort receives from all senders
    3. The time between two received packets

    Is this information useful from a security perspective, or should I turn my focus toward other Snort data points?

    You might be able to extract some of that information from a Snort sensor, but I'd recommend turning your focus toward other data points. For your first two requests, you should use a NetFlow aggregator. There are numerous dedicated systems designed to find these basic network statistics.

    I'm not sure why you'd need to collect "the time between two received packets." Snort doesn't keep a record of every received packet unless you specifically instruct it to do so. Under Snort's primary settings, you consequently wouldn't be able to determine the time difference between two arbitrary packets. Tools like tcpdump run on the host, however, and should be able to address this third area.

    Snort is an intrusion detection system, so the real question you should be asking is, "What type of unusual events does Snort detect on my network?" On any network using an IDS for the first time, you'll likely find a number of false positive reports. Your next question should then be, "Which of those alerts can I safely ignore?" Once you have the answers to those questions in hand, you can use Snort as part of your ongoing routine to monitor the network for potential security events.

    More information:

  • Check out's Snort Report tip on Snort basics and configuration.
  • Check out our full archive of Snort Report tips.
  • CLIENT CONCERN #3------------------------------------------------------------

    If public mail servers are located in a DMZ, what is the procedure for channeling internal mail through the firewall?

    To channel internal mail through the firewall, many organizations use a Simple Mail Transfer Protocol (SMTP) relay server in the DMZ. The enterprise email server (e.g. Microsoft Exchange) sits on an internal network and interacts with users. External parties wishing to send email via SMTP can connect to the SMTP relay system in the DMZ, which is listed as the mail exchanger in DNS. The SMTP relay then accepts -- or denies, according to policy -- inbound messages and relays them to the internal mail server.

    Similarly, when the internal mail server receives a message destined for an external network, it accepts the message from the client and then passes it to a DMZ's SMTP relay. The relay then forwards the message to the destination server. This architecture prevents direct connections from the Internet to the internal mail server, providing a layer of isolation.

    As an added bonus, you can use a spam-filtering device as your SMTP relay. Devices like SendMail's Sentrion appliances and the Barracuda spam firewall are popular tools that can reduce the spam-filtering burden on clients.

    More information:

  • Learn how to configure a DMZ.
  • Learn where enterprise users belong in a DMZ setup.

    CLIENT CONCERN #4------------------------------------------------------------

    Under what circumstances would you recommend building your own intrusion detection system (IDS)?

    Generally, I'm a fan of the "buy vs. build" philosophy, and I recommend the use of commercially supported products in enterprise environments. In most cases, it's simply more cost-effective to use a product that has manufacturer support available. Many administrators find the notion of calling for support a blow to their egos, but that's a misguided philosophy; technical support should be viewed as a direct pipeline to expert knowledge, rather than a last-ditch 911 call.

    Some organizations, like schools and other non-profits, may have volunteers available to spend time maintaining a system, or simply don't have the funds to purchase and maintain a commercial IDS. In such cases, building an intrusion detection system may be a viable option.

    If you do choose the "build it" route, go with a mainstream tool. Enterprises around the world, for example, deploy the open source Snort IDS. The intrusion detection system's rule updates are available for free, but with a 30-day delay. If you're willing to spend a few hundred bucks a year, however, you can purchase a real-time rules subscription. There's also a huge community that provides a free support resource through forums on the Snort Web site.

    More information:

  • Learn how to use Snort IDS rules in this edition of the Snort Report, courtesy of

    CLIENT CONCERN #5------------------------------------------------------------

    How is a client without SSL able to connect to a secured server?

    Generally speaking, a client can't do this. If the server only supports Secure Sockets Layer (SSL) communication, clients that do not support SSL will not be able to connect. However, in some cases, servers allow both secured and non-secured communications, so the client that does not support SSL may still be able to connect.

    SSL is now widely used and should always be employed when exchanging any type of sensitive information. All modern Web browsers contain built-in SSL code and can handle a number of common cryptographic algorithms. If you're referring to a Web server, you'll have a hard time finding a Web client that doesn't support SSL.

    More information:

  • Learn about the top five SSL VPN products, as chosen by the expert at
  • What's better for your client, IPsec or SSL VPNs? About the author
    Mike Chapple, CISSP is an IT Security Professional with the University of Notre Dame. He previously served as an information security researcher with the National Security Agency and the U.S. Air Force. Mike is a frequent contributor to, a technical editor for Information Security magazine and the author of several information security titles, including the CISSP Prep Guide and Information Security Illuminated.

Dig Deeper on Managed network services technology