N10-007 Given a scenario, configure and apply the appropriate ports and protocols
The Simple Network Management Protocol (SNMP) enables remote query and remote configuration of just about anything on a network. Assuming all your computers, switches, routers, and so on are SNMPcapable, you can use programs to query the network for an unimaginable amount of data. SNMP is a popular tool to check on your network, but you’ll need to take the CompTIA Network+ exam to see SNMP in action.
The Server Message Block (SMB) protocol isn’t even an application but rather proof of the power of Microsoft. SMBs date back to the old NetBIOS naming service and were the tools that tossed a PC’s name around a network. NetBIOS names are gone, but SMBs are the reason that tools like Network can show you all the computers on your network. SMB is so powerful that other operating systems copy SMB using a popular program called SAMBA. SAMBA emulates SMB—it makes non-SMB operating systems on a network look like Windows.
Secure FTP is nothing more than FTP running through an SSH tunnel. This can be done in a number of ways. You can, for example, start an SSH session between two computers. Then, through a moderately painful process, start an FTP server on one machine and an FTP client on the other and redirect the input and output of the FTP data to go through the tunnel. You can also get a dedicated SFTP server and client.
If you need a remote terminal that works securely across the Internet, you need Secure Shell (SSH). In fact, today SSH has replaced Telnet in almost all places Telnet used to be popular. To the user, SSH works just like Telnet. Behind the scenes, SSH uses port 22, and the entire connection is encrypted, preventing any eavesdroppers from reading your data. SSH has one other trick up its sleeve: it can move files or any type of TCP/IP network traffic through its secure connection. In networking parlance, this is called tunneling, and it is the core of most secure versions of Internet technologies such as SFTP and VPN.
When moving data from one system to another, the TCP/IP protocol suite needs to know if the communication is connection-oriented or connectionless. When you want to be positive that the data moving between two systems gets there in good order, use a connection-oriented application. If it’s not a big deal for data to miss a bit or two, then connectionless is the way to go. The connection-oriented protocol used with TCP/IP is called the Transmission Control Protocol (TCP). The connectionless one is called the User Datagram Protocol (UDP).
Let me be clear: you don’t choose TCP or UDP. The people who developed the applications decide which protocol to use. When you fire up your Web browser, for example, you’re using TCP because Web browsers use a protocol called HTTP. HTTP is built on TCP.
Over 95 percent of all TCP/IP applications use TCP—that’s why we call the protocol suite “TCP/IP” and not “UDP/IP.” TCP gets an application’s data from one machine to another reliably and completely. As a result, TCP comes with communication rules that require both the sending and receiving machines to acknowledge the other’s presence and readiness to send and receive data.
UDP is the “fire and forget” missile of the TCP/IP protocol suite. UDP doesn’t possess any of the extras you see in TCP to make sure the data is received intact. UDP works best when you have a lot of data to send that doesn’t need to be perfect or when the systems are so close to each other that the chances of a problem occurring are too small to bother worrying about. A few dropped frames on a Voice over IP call, for example, won’t make much difference in the communication between two people. So there’s a good reason to use UDP: its smoking fast compared to TCP.
The FTP, or the File Transfer Protocol, makes it possible for users to exchange files between their personal computers and remote servers with the help of specialized software tools called FTP clients. Through FTP software tools users can establish connections with a remote machine of their choice and perform any necessary data transfers. The FTP connections are executed through certain ports, which are either the default TCP ports or custom ports set by an administrator.
Executing an FTP port connection through a client is a two-stage process requiring the use of two different ports. Once the user enters the name of the server and the login credentials in the authorization fields of the FTP client, the FTP connection is established and the FTP control port of the FTP server (the default port for sending commands is 21) is opened. Then a second connection to the server is made by the client, followed by a response of the FTP server from the port for sending data (the default data sending port is 20), when the real file transfer actually begins.
Terminal Server Clients use TCP port 3389 to communicate with Terminal Server. A common problem in a WAN environment is that a firewall or other network filter prevents connectivity with this port. You can run a simple troubleshooting test to make sure the Client can connect to the port. Just try to telnet to the port from the Client.
To test the functionality of port 3389, use this command from the Client:
Telnet tserv 3389
where “tserv” is the host name of your Terminal Server.
If telnet is successful, you simply receive the telnet screen and a cursor. On the Terminal Server, Terminal Server Administration will show a blue computer icon with no other information. The Telnet connection will also consume an idle session.
The Terminal Server should disconnect the connection after a few minutes. Or, you can disconnect using Telnet.
During DNS resolution, DNS messages are sent from DNS clients to DNS servers or between DNS servers. Messages are sent over UDP and DNS servers bind to UDP port 53. When the message length exceeds the default message size for a User Datagram Protocol (UDP) datagram (512 octets), the first response to the message is sent with as much data as the UDP datagram will allow, and then the DNS server sets a flag indicating a truncated response. The message sender can then choose to reissue the request to the DNS server using TCP (over TCP port 53). The benefit of this approach is that it takes advantage of the performance of UDP but also has a backup failover solution for longer queries.
In general, all DNS queries are sent from a high-numbered source port (49152 or above) to destination port 53, and responses are sent from source port 53 to a high-numbered destination port.
RDP (Remote Desktop Protocol) uses port number 3389 for LAN (Internal/Private) traffic and port 3390 for WAN (Internet/public) traffic. if you need to allow RDP into a firewall policy, then these are the ports you need to use for allowing DRP connections or for blocking.
RDP is a windows terminal server protocol. if you have windows xp professional it already comes installed by default. also, windows 7 professional and ultimate have it install. if you have windows xp, vista or seven or 8 home edition, it does not come with a RDP server, but it does come with a RDP client.