Get this Security+ CertiGuide for your own computer.
Click Here!
Use coupon code "certiguide" to save 20%!
(Expires 2004/12/31)

Also available: 300-question Security+ practice test!
Get It Here!

Custom Search

Table Of Contents  CertiGuide to Security+
 9  Chapter 2:  Communication Security (Domain 2.0; 20%)

Previous Topic/Section  Site Surveys
Previous Page
Pages in Current Topic/Section
Next Page
2.8  Success Questions
Next Topic/Section

2.7  Summary

In this chapter, we looked at the topics in the second domain of the Security+ exam, Communication Security.

You discovered key characteristics of remote access technologies designed to give users access to your network without being physically on the LAN, such as:

  • 802.1X, which can improve privacy on wired and wireless LANs via a standardized, extensible authentication mechanism called EAP.

  • VPNs, or Virtual Private Networks, which use encryption and a public network such as the Internet to create a secure network between two points or networks; protocols used to create VPN’s include PPTP, L2TP, L2F, SSH and IPSec.

  • RADIUS, a popular authentication protocol that centralizes the user database and is often used to validate users dialing in to their ISP; in RADIUS, the dial-in server is a client to the RADIUS server.

  • TACACS and TACACS+, which do not interoperate even though they sound the same (TACACS+ also has issues with sending accounting data in clear text, allowing it to be altered undetectably if intercepted).

  • PPTP, a layer 2 tunneling technology available on Microsoft Windows, which uses TCP port 1723, can be used to provide data integrity and encryption for a VPN

  • L2TP, a layer 2 tunneling technology intending to replace PPTP and L2F (an older version of L2TP), which uses UDP port 1701.

  • SSH, the Secure Shell protocol, which started out as a more secure replacement for telnet and evolved into a general purpose tunneling protocol allowing the use of a wide variety of encryption protocols, provides secure authentication and encrypted communication; it uses port 22 by default.

  • IPSec, a layer 3 tunneling technology, which is a standard protocol suite for secure IP communication using public-key encryption.

You explored the details of IPSec, which uses TCP port 1293 and establishes a Security Association (SA) for each side of the connection, and uses the ISAKMP protocol over UDP port 500 to negotiate session keys for a conversation. IPSec includes AH (Authentication Header, IP protocol 51) and ESP (Encapsulating Security Payload, IP protocol 50) protocols; both allow for packet integrity but only ESP supports packet encryption. You learned about the difference between running IPSec in transport (encrypts only data, can be used with non-IPSec enabled routers and may require software installation on clients) and tunnel (encrypts header and data, generally used from router to router and invisible to clients) modes.

You also learned about email security, including common email protocols such as SMTP (using TCP port 25, for sending mail and transferring mail among servers), POP3 (port 110) and IMAP (port 143). You discovered that POP3 and IMAP are used by clients to retrieve their email from servers. You learned about common public key encryption mechanisms for email, such as S/MIME (which uses x.509 digital certificates) and PGP. You learned about email vulnerabilities in the authentication, transmission and storage of message data, as well as in the programs used for email communication. Spam, which consumes corporate resources and staff time, and various ways to corral it were unveiled to you as well as the social engineering issue of email hoaxes.

Next, you learned about basic web security, including the SSL and TLS encryption protocols which use X.509 certificates and public key encryption. You discovered that URL’s beginning “https:” use SSL communications over TCP port 443 (the HTTP/S protocol), and that the SSL conversation startup uses a 6-step handshake. SSLv3 improved upon SSLv2 by supporting additional encryption techniques, besides the DES encryption used in SSLv2. It was mentioned that TLS is a general-purpose evolution of the web-oriented SSL protocol, which is not compatible with SSL but can back down to SSLv3 operation if needed, and that implementations of many popular protocols such as LDAP and SMTP have been layered over TLS. S/HTTP (“shttp:”) is an older standard for encryption of web communications which has fallen out of favor as the popularity of SSL increased.

You explored the security-related aspects of content such as JavaScript (which is a humanly-readable programming language often used to download and run scripts within the user’s browser, generally to display fancy menus or animations) and ActiveX (compiled, non-humanly readable program code, used for purposes similar to JavaScript; ActiveX programs use “digital signing” to identify the origin of the downloaded component, but unlike JavaScript don’t try to isolate the client user’s machine from potential damage by the ActiveX program). Digital signing, used by both ActiveX and java components, lets you be (somewhat) sure of the origin of a component, but does nothing to protect against damage. Once again, we also looked into buffer overflows, which are a common technique for attacking a web server; web server buffer overflows are often exploited by sending huge amounts of data when posting a web form.

Still on the topic of web servers, you discovered the risks inherent in cookies, which are pieces of information sent from the server to be stored on a client machine, often based on information provided by the user to the web server. One issue with cookies is that they often store sensitive information on the client machine, or information which can be used to determine where the user has been on the web (a privacy concern); another is that if a site uses cookies for authentication, an attacker can copy a cookie from one machine to another, to impersonate the user of the original machine.

You learned about CGI scripts, which are executable programs that run on a web server, including the fact that it’s difficult to get them right and they can often be exploited by providing unpredictable input.

You also looked at Instant Messaging (IM) security issues, such as the risks of transmitting confidential information unencrypted, and lack of authentication of IM users that may allow identity spoofing and disclosure of information to unauthorized people. One issue that may arise whenever files are transferred is the 8.3 character file naming convention, where file names with an 8.3.3 character name like play.txt.exe might use a second extension to fool a program or user into thinking an attachment is one type of file, when it’s really another – allowing a virus to propagate. IM started as a tool for individual users and lacks corporate-friendly features like centralized logging and authorization. IM traffic can be difficult to block, as some popular IM programs simply search for the first open port and use that for their communication.

You discovered that open SMTP relays can be used to send spam email, since they allow unauthenticated connections from anyone on the Internet, and that it is a good idea to restrict access to any SMTP server you control to avoid getting a reputation of tolerating spammers. SMTP relays in general are a good thing, because they’re how email gets from one domain to another; but relays that accept connections from untrusted sources are a bad thing.

You explored Directory services, which allow a user to look up information about a corporate network and/or its users. You learned that most popular directory services including Microsoft Active Directory and Novell eDirectory use the LDAP protocol (TCP port 389) for directory queries, and that to allow users on the Internet to query your directory server, you would need to open inbound TCP port 389 on your firewall. LDAP is a tree-structured protocol based on the X.500 standard which does not encrypt its communication. Optionally, you can combine LDAP with TLS to encrypt the traffic. LDAP can be used for purely informational purposes as well as distribution of public keys, and may be used as an information source by authentication protocols like RADIUS, TACACS+ and Kerberos.

You learned that another area of exposure is file transfer. Usually on the Internet, this is accomplished by FTP, which uses TCP and UDP ports 20 and 21 for its data and control connections. Because FTP, like other early application protocols such as telnet, transmits password information and data in clear text, you are advised to use an alternative program such as S/FTP which offers a secure authentication mechanism and an encrypted channel for data, running over SSH or SSL. To safeguard the files on your FTP server, you might implement “blind FTP” by configuring your FTP server so that users can only retrieve files whose names they know.

Usually, FTP server users are required to authenticate themselves and have a user/password on the server. Alternately, you might use anonymous FTP, so that authentication is required. Since the risk here is that now anyone can access your FTP server, if you use anonymous FTP, you should limit (maybe eliminate) directories to which users have write access, perhaps offering only “blind” access to those directories so that users who don’t know they’re there, can’t use them. Since most FTP servers have experienced high-profile bugs, make sure you update the server software regularly and carefully monitor use of your site to detect problems quickly.

File sharing, by using P2P services such as Kazaa or simple Windows File & Printer Sharing (NetBIOS) connections is another area of concern, because such user-controlled services can be used to make confidential information available to unauthorized people, as well as being a waste of bandwidth and source of (possible) pirated data such as music for which the company could become liable. Attackers can use file transfer mechanisms to upload viruses or exploit denial-of-service or buffer overflow vulnerabilities.

Wireless security and too frequently the lack of security along with the future efforts have been explained in detail. You learned how Wireless Transport Level Security (WTLS), the security layer within WAP (Wireless Application Protocol) is used to improve wireless network security, providing secure data transmission and authentication. It uses TLS/SSL-like protocols, and symmetric and public-key encryption.

In the last major topic area, you discovered key facts about 802.11x networks, such as the need to know the network’s SSID (Service Set Identifier) and if encryption is enabled, the WEP (Wired Equivalent Privacy) Key, in order to connect. Unfortunately, you also learned that those items can be snooped directly off the network or determined by analyzing enough sniffed traffic. If the WEP Key and SSID don’t both match those in use by other network devices, including the wired access point (WAP) connecting wireless devices to the network, communication will not be successful WEP employs RC4 encryption and often uses a weak 40-bit key, although it can also use 64 or 128-bit keys (depending on your equipment).

WEP is theoretically as secure as wireless networks, but practically speaking due to encryption issues has proven to be less secure. This will be improved in the future with the use of TKIP (Temporal Key Integrity Protocol), and eventually AES encryption. You learned that a primary vulnerability of wireless LAN’s is access by unauthorized individuals outside your organization, and that in addition to employing a VPN on top of your 802.11 LAN, physical measures such as careful antenna placement and shielding of a building can also be taken to reduce vulnerability to unauthorized access. If your wireless network hardware allows you to lock down access to only devices with certain MAC addresses, use it!

Previous Topic/Section  Site Surveys
Previous Page
Pages in Current Topic/Section
Next Page
2.8  Success Questions
Next Topic/Section

If you find useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider buying an inexpensive PDF equivalent of the CertiGuide to Security+ from (Use coupon code "certiguide" by December 31, 2004 to save 20%!) Thanks for your support!
Donate $2
Donate $5
Donate $10
Donate $20
Donate $30
Donate: $

Home - Table Of Contents - Contact Us

CertiGuide for Security+ ( on
Version 1.0 - Version Date: November 15, 2004

Adapted with permission from a work created by Tcat Houser et al. Version Copyright 2004 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.