From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 6 “TCP/IP Transport and Application Services” – FTP, SSL + SNMP

1,031 Words. Plan about 6 minute(s) to read this.

On to some of the common applications that ride on TCP and UDP. The author touches on FTP (active and passive modes), SSL/HTTPS/TLS just briefly, and closes with SNMP. Accompanied by Beethoven’s Rondo from Piano Concerto No. 2, I soldier on. Quickly, I might add, as the morning will find me at work at 4am upgrading a wretched, evil pair of F5 LTM 3400’s that have been no end of headache recently.

  • Some common applications, with their ports and RFC numbers:
    • telnet – tcp/23, RFC 318.
    • FTP – tcp/20,21, RFC 959 (like the Porsche supercar).
    • TFTP – udp/69, RFC 1350.
    • SMTP – tcp/25, RFC 2821.
    • POP3 – tcp/110, RFC 1939.
    • IMAP – tcp/143, RFC 3501.
    • TLS/SSL – tcp/443, RFC 2246.
    • LDAP – tcp/389, RFC 2251.
    • HTTP – tcp/80, RFC 2616.
    • DNS – tcp+udp/53, RFC 1034, 1035.
    • NetBIOS name service – udp/137, RFC 1002.
    • NetBIOS datagram – udp/138, RFC 1002.
    • NetBIOS session service – tcp/139, RFC 1002 (makes sense that a session service would be TCP-based).
    • SNMP – udp/161, 162, RFC various.
    • BGP – tcp/179, RFC various.
    • RIP – udp/520, RFC various.
  • Active and passive FTP. FTP is file transfer protocol, still widely popular and in use all over the place, but fraught with some interesting challenges when faced with NAT, proxies, and firewalls. These challenges have a lot to do with the fact that FTP will negotiate ports on the fly while the session is running, so you need devices performing NAT, proxy or firewall services in between the client and server to be savvy about the FTP conversation. IOW, they need to pay attention to the conversation so that the conversation flows securely, but without interruption. Ergo, a review of active and passive FTP is appropriate.
    • An FTP client in “passive” mode will negotiate ports in the following manner:
      • The server will dynamically allocate an available port.
      • The server uses the FTP PORT command to tell the client what port to connect to in order to transfer data.
      • The client initiates a connection to that port.
      • The server verifies that the incoming connection is from the same client he sent the PORT command to.
      • We’re off to the races.
    • An FTP client in “active” mode will negotiate ports int he following manner:
      • The client will dynamically allocate an available port.
      • The client uses the FTP PORT command to tell the server what port he’s now listening on.
      • The server, using TCP port 20, will open a connection inbound to the client.
      • We’re off to the races.
  • Lots of popular TCP/UDP applications transmit their data in the clear, easily readable with a packet sniffer. Thus, secure protocols that, among many other things, encrypt the data payloads have been introduced to better protect these applications. SSH (secure shell), is a telnet alternative. POP3 supports encrypted retrieval of mail (although the author makes it sound as if POP3 is inherently secure, which it is not). SSL (secure sockets layer) is literally a layer that sits below the application, offering security to those applications. HTTPS is therefore good old HTTP riding on top of SSL. Netscape was the originator of this, and has specified SSL up to version 3. However, there’s a standard version of SSL called TLS (transport layer security) defined by the IETF in RFC 2246. Many other RFC’s specify how other protocols can leverage TLS for security enhancements.
  • SNMP, simple network management protocol.
    • SNMP is a protocol to allow the remote querying and response of a network device. The kinds of questions you can ask and get responses to are dependent on the sorts of variables that the SNMP agent running on the device is keeping track of, known as the management information base (MIB).
    • The guy asking the questions is known as the SNMP manager. HP OpenView, Aprisma Spectrum, SolarWinds.Net and Ipswitch WhatsUp Gold are applications leaping to mind that can act as SNMP managers.
    • These managers can ask your routers about things such as interface up/down status, bandwidth utilization, chassis temperature, CPU utilization, memory utilization, interface errors, and about anything else you can think of. While there are a number of standard MIB’s that pretty much all network devices will support, manufacturers often write custom MIB’s that provide an overwhelming amount of information.
      • MIB-I, SNMP v1, RFC 1156
      • MIB-II, SNMP v2, RFC 1213.
      • RMON (remote monitoring), RFC 2819. Used for probes, like the one in Star Trek IV, only without the transparent aluminum.
    • You can discover just what all is in the MIB tree by performing an SNMP “walk”, which will spit back at you not only the MIB you knew to ask about, but everything else under that MIB branch that you didn’t know was there. (I did this on an F5 box recently, just so that I could have Cacti, one of our SNMP managers, poll a specific MIB variable. I didn’t know what the variable was, so I walked the tree until I found what I needed, then fed it to Cacti.)
    • SNMP notable versions:
      • v1 – uses community names for authentication.
      • v2 – uses community names still (but they are optional now). Added the GetBulk and Inform messages.
      • v2c – RFC 1905, in common use. The same as v2, but allows for v1 style communities.
      • v3 – Very much like v2, but adds better security (not so much in cleartext), but is backwards compatible with communities.
        • Authentication via MD5 and SHA
        • Encryption via DES (and maybe AES someday, although that’s not a part of the specification).
    • SMI – structure of management information. Syntax definitions.
    • SNMP protocol messages (any decent sniffer will decode these for you):
      • Get – a request by a manager for a single variable value.
      • GetNext – a request by a manager for the next single variable in the tree.
      • GetBulk – a request for multiple consecutive variables via a single request, handy for getting lots of data at once.
      • Response – sent by the agent to the manager.
      • Set – a request sent by a manager to tell the agent what value a MIB variable is supposed to be. (Pretty powerful feature if you think about it.)
      • Trap – sent by an agent to a manager. This is “volunteer” information, not something the manager was asking for.
      • Inform – used between SNMP manager to share MIB information.