Un-edited Live session – http://www.youtube.com/watch?v=dvOQKH2ng-A
Tony Bemus, Mat Enders, and Mary Tomich
Sound bites by Mike Tanner
Kernel News: Mat
mainline: 3.19 2015-02-09 stable: 3.18.7 2015-02-11 longterm: 3.14.33 2015-02-11 longterm: 3.12.38 2015-02-19 longterm: 3.10.69 2015-02-11 longterm: 3.4.106 2015-02-02 longterm: 3.2.67 2015-02-20 longterm: 188.8.131.52 2014-12-13 linux-next: next-20150222 2015-02-22
Distro Talk: Tony
- 2-9 – Network Security Toolkit 20-6535 – Top 125 Security Tools by INSECURE.ORG are available in the toolkit.
- 2-10 – Kali Linux 1.1.0
- 2-11 – Univention Corporate Server 4.0-1
- 2-13 – Robolinux 7.8.1 “KDE”
- 2-13 – Rebellin Linux 2.5
- 2-14 – Parsix GNU/Linux 7.0r1
- 2-16 – Netrunner 15
- 2-16 – Black Lab Linux 6.1 “MATE”
- 2-17 – Frugalware Linux 2.0
- 2-17 – Bodhi Linux 3.0.0
- 2-18 – Clonezilla Live 2.3.2-22
- 2-19 – Proxmox 3.4 “Virtual Environment”
- 2-20 – LinHES 8.3
- 2-20 – Ubuntu 14.04.2
- 2-20 – ClearOS 6.6.0 “Community”
Distro of the Week: Tony
- openSUSE – 1393
- Bodhi – 1481
- Debian – 1720
- Ubuntu – 2047
- Mint – 3175
SMLR’s Half Book Review: Networking for System Administrators (Author: Michael W. Lucas)
This Episode’ Half-Book Review: Networking for System Administrators (Author: Michael W. Lucas)
When Michael W. Lucas approached me about reviewing his latest book: Networking for System Administrators, I jumped at the chance. Whether you’re a professional system administrator or someone who’s simply connects one or more computer or router to your home network, you’ve interacted with the network. Although naturally this book focuses on the men and women who maintain systems and servers for a living, anyone who’s curious about their home network or who just has a natural curiosity will find this information useful.
Note that Mr. Lucas covers networking in a Windows environment, Unix as well as Linux.
In the first chapter of the book, which is appropriately named Chapter 0: The Problem, Mr. Lucas lays out the situation Essentially it’s this: Due to the specialization and complexity of the enterprise, it’s difficult to know everything about everything. This specialization can lead to a blame game when something goes wrong. It’s not always the network guy’s fault when your server isn’t properly communicating. Lucas asserts that by learning some basic networking principles and applying them as needed, a system administrator’s troubleshooting effectiveness will increase. It’s a far better strategy than simply throwing up your hands and claiming the problem is with the network. That may be the case, but after reading Lucas’ book, you won’t be embarrassing yourself when it’s not. And, according to Lucas, the network administrator might actually like you.
The book is divided into two sections: The first six chapters discuss network technology that system administrators really should know. The second half of the book–Chapters 7 through 12—invites sys admins to roll up their sleeves so they can actively check the systems they maintain and evaluate the results of that check before they contact the network administrator.
No book on networking would be complete without a discussion of the network stack and Lucas’ conversational style covers it effectively in–Chapter 1: Network Layers. He mentions the seven-layer OSI model but then notes that the TCP/IP model is a better fit in modern networks. For anyone not aware of it, TCP/IP model rolls everything past the transportation layer, i.e. layer 4, (session, presentation, and application) into a single application layer, including HTTP, SMTP, LDAP, some of the services a system administrator manages. As an overview, the chapter conveniently includes a table listing some troubleshooting tools for each layer of the stack. It’s later in the book where Lucas expands on this information. In a section called Layering in Practice, Lucas takes a simple web page request and shows how each layer participates. While it might be old news for grizzled veterans I found it to be informative.
Chapter 2 focuses on Ethernet, the ubiquitous local area network protocol. As expected, Lucas covers various aspects of the protocol—including things like speed, duplex, fragments, MTU, ARP, to name a few. I found Lucas’ brief description of including MTU to be enlightening. And he provides useful advice regarding setting the MTU if you need to—one size doesn’t necessarily fit all (i.e. It should be set on a network basis). Ping, one of my favorite commands makes an appearance in this chapter. Lucas shows how a non response from the pingee (my term) doesn’t mean that host isn’t on the network. It just means you didn’t get an answer. And that’s a perfect segue to ARP, the Address Resolution Protocol and its IPv6 counterpart, Neighbor Discovery. This chapter has them both well covered
Our old friend, IPv4 receives good coverage in Chapter 3 and it should because that’s the title of the chapter. Lucas spends some time in the first portion of this chapter discussing the basics of IPv4 networking, about which I won’t go into detail but it involves lots of 1s and 0s. The focus shifts to activity on the local machine with local-host and loop-back. (Apparently talking to one’s self here is a good thing.)
From there, Lucas moves to private addresses and NAT (Network Address Translation). Of course private addresses and NAT has extended the lifespan of the IPv4 address pool. Lucas effectively explains NAT and how it works.
We hear the word firewall and Lucas aptly notes that it can mean several different things…from a software package on a desktop to a combination of packet filters, proxy servers, and NAT or in the case of global organizations
Lucas cautions that proxies, NAT devices, and firewalls are not “Internet security systems.” Lucas says they’re components in an organization’s security policy, Lucas notes that NAT in particular is not a security mechanism—that minimal protections was broken years ago. Lucas concludes the chapter by touching on the two main tools for troubleshooting IP connectivity: ping (most appropriate for testing local network connectivity) and traceroute (testing connectivity to networks on our local domain). More about those later in the book.
I found Chapter 4, IPv6, to be very informative…primarily because Lucas does a very good job describing the essentials, then transitions to the details. Of course we were bound to run out of IP v4 addresses eventually and Lucas mentions that ARIN projects they’ll no longer be able to issue IPv4 addresses by April 23, 2015, and recommends preparing for the eventuality before it becomes a mission-critical situation.
Both protocols have a lot in common and Lucas says you can almost replace an IPv4 address with an IPv6 address and watch everything work.
Lucas also notes an interesting difference between IPv4 and IPv6 for many OSes: For a while, the last part of the host’s IPv6 address could be computed from the network card’s MAC address. An obvious privacy issue, it’s been gradually replaced with non-reversible ways to generate IPv6 addresses.
NAT which was invented as a work around the limited number of IPv4 addresses, isn’t a part of the IPv6 protocol. Lucas explains that NAT is so deeply entrenched, that organizations are clamoring for its inclusion in IPv6. Lucas ends this chapter with a brief discussion of how dual-stacked hosts—hosts that are configured to use bot IPv4 and IPv6—handle traffic: Incoming connections are handled by the protocol they come in on. Outgoing, on the other hand, can be handled by either, depending on the operating system. Windows Vista and later prefer IPv6 if it’s been set up. On the Unix side, however, it varies widely—some rely on DNS to decide while others use a program like ip6addrctl or a conf file in /etc to set the preference. Per Lucas: Which is better really depends on your connectivity.
In the next chapter–Chapter 5: TCP/IP—Lucas makes the distinction between TCP and IP, but notes that the acronym really refers to the whole family of protocols related to TCP and IP…it reads like a who’s who of acronyms: UDP, ICMP, and the less common SCTP, and ESP (Oh, now I understand the protocol that mind-to-mind communication uses!) Mr. Lucas spends time discussing each and noting the differences. His analogy of the difference between UDP and TCP is effective…comparing them to a cars on a crowded freeway and an automated factory assembly line, respectively. The initial reaction to these descriptions is what good is UDP when it’s connectionless and doesn’t have its own error correction. As it turns out, according to Lucas, very good when you’re using VoIP. The example he uses to drive this point home is perfect: “If the phone drops a couple of packets, you don’t want the application to say “Oh, we lost a quarter-second of audio! I better go ask the sender to retransmit those!” No. The little slice of sound is gone. The caller doesn’t need a two-second-old dropped slice of sound suddenly dumped into a blank spot in the conversation.” It’s the perfect explanation!
He touches on the other protocols and points the user to the protocol file where you can view the list.
The remainder of the chapter is spent discussing TCP. Lucas walks the reader through an overview setting up the connection…the three-way handshake. I didn’t realize that it takes a four-way handshake to close the connection.
No chapter on TCP/IP would be complete without a look at ports and, of course, sockets. Lucas calls sockets a virtual construction for plugging communication into and goes on to discuss them and they’re used.
The remainder of the chapter briefly looks at other protocols —if you’re running FreeBSD/PC-BSD, it’s at /etc/protocols. The protocols file on my BSD laptop were at least twice as long as the file on my Linux desktop.
Chapter 6: Viewing Network Connections – In this chapter, Lucas discusses the readout from the netstat command for both Windows and Unix-like systems. He also takes the time to show how various options can effectively filter for the information that you’re seeking. Because he’s showing Linux, Unix/BSD, and Windows output, Lucas helpfully organized the information in this chapter into separate sections, although in the Unix section, some of the Unix/BSD commands very slightly from Linux, so if you’re not careful when using some of these commands, you’ll get unexpected results. Case in point: netstat -na 4 on BSD produces very different output than it does on Linux. On my laptop it appeared to provide a real time look at what was passing over my laptop’s network connection. However, on Linux you see a list of active connections and their state.
Lucas runs down the list of commonly used options for netstat so you can see, for example only TCP or UDP, only established connections, or only listening sockets. Finally, he provides you with the netstat options you need to see who’s listening on a port (netstat -na -b). While it differs across the Linux/Unix variants, ,field, you can Rather than use a separate set of options to view this information,
Chapter 7: Network Testing Basics, starts the second half of the book and the focus turns to troubleshooting. Of course there are “dos and don’ts” of troubleshooting—network testing etiquette, as Lucas calls it. After all you don’t want to create an abnormal situation on the network. Lucas says that it’s OK to send normal traffic between your systems for testing but abnormal traffic is another story. The two tools that can create this type of traffic are load balancers and port scanners. He says that you probably can create a small amount of abnormal traffic but if you use tools that create a large amount of abnormal traffic, be prepared for a visit.
Lucas says that potential network issues for systems administrators boil down to two key questions: what do my hosts send, and what do my hosts receive?
He also discusses how to report problems and that it’s typically better to not jump to a conclusion about what the cause is. People can take these things seriously, Lucas notes. The best thing to do is let the network team know what you’re trying to accomplish. Just the facts, sir.
Chapter 7 concludes with some of the items that can block or disrupt traffic and how they might do it.
In Chapter 8, Lucas then moves to the Domain Name System. He assures sys admins that they don’t have to know the innards of DNS but the basic idea behind it and how the query the system for information is very useful information. For example, DNS runs on TCP and UDP, using port 53 on both. It’s a common myth that DNS only uses UDP, but Lucas notes in the book it hasn’t been true since the 1990s.
As you’d expect, he covers the concept of domains and zones, including child and parent zones: child zones belong to parent zones but, depending on your perspective, a zone could be a child or a parent. Mr. Lucas uses his own web site as an example.
A complete collection of data for a zone is called a zone file. Zone files live on the authoritative DNS servers. DNS servers come in two varieties: authoritative and recursive. Lucas helpfully explains the difference and why it’s not a good idea to combine both on a single server.
Michael Lucas also talks about forward and reverse DNS. As you might expect—one maps host names to IP address and the other does the reverse. Guess which is which…
According to Lucas, DNS’ greatest curse is its success. He specifically discusses this thought in terms of DNS zone records. Over the years, many different types of information has been jammed into the zone record. Lucas mentions that the A record contains the IPv4 address and the AAAA record contains the IPv6 address. I personally wondered why four As were needed…
No chapter on DNS is complete without a section on querying DNS and Lucas doesn’t disappoint. He provides a thorough treatment of this topic from both Windows and Unix perspective. The common tool in Windows is nslookup. Lucas notes that this tool is deprecated in Unix/Linux, but Microsoft has updated its version to support the newest protocol standards. The Unix counterpart is host (not to be confused with the hosts file in /etc) for which Lucas provides several sample searches as well a few suggestions if you need a more sophisticated tool.
Mr. Lucas wraps up this chapter with a sections on the hosts file, where you can manually map IP addresses with host-names and disabling DNS. There are times when that step is needed.
Tools to determine what is coming and going on your server are covered in Chapter 9: Packet Sniffing. In this chapter Mr. Lucas discusses the commonly available tools for various OSes: tcpdump, WinPcap, Windump, wireshark. Most are console tools, but Wireshark presents a newer, fancier interface. I have used it and know that it captures everything. Lucas emphasizes that, for security reasons, Wireshark should never go on a production server—instead, install it on a throw-away virtual machine. Most of this chapter is spent discussing the command options available, including filtering for specific protocols, as well as considerable detail on interpreting the results.
In chapter 10, we go from analyzing traffic to creating traffic. Reproducing the problem is a valuable troubleshooting technique and in this chapter, Lucas introduces netcat, a tool which let’s you generate arbitrary TCP/IP traffic. For example, You want to know if a client can connect to TCP ports 25 and 587 on your mail server? Stop using your email program to generate traffic. Fire up netcat on your client, point it at those ports on the server, and see if the packets arrive.
Lucas notes that netcat has been around for 20 years. Of course original versions were lacking IPv6 support, but Lucas notes that it’s been forked, rewritten and improved by many people. If your Linux box ships with the original netcat (cough, cough, Debian), Lucas says to install netcat-openbsd package to get IPv6 support. Netcat has been ported to Windows but there are other Windows tools for generating traffic.
Lucas again goes into considerable detail on how to use these tools, from connecting to listening and sending files, he has you covered.
Server Packet Filtering is covered in chapter 11. Lucas helpfully provides scenarios where packet filtering can help isolate a problem or prevent an intrusion. Lucas says that: “Your server probably runs all kinds of services used only by the local host, and it probably offers all of them on its network interface. Why should other hosts be able to access them? Block that stuff. Block everything except what the server specifically provides.” He goes on to say that this approach helps you lean about how the serer’s applications actually function.
Chapter 12: Tracing Problems. In this chapter, Lucas introduces traceroute and describes how to use it, what it can tell you and what some of the common errors mean. He explains that more is better as far as traceroute is concerned, when trying to identify a network problem. This is where mtr comes in. Mytraceroute (mtr) is a utility that runs traceroute continuously and prints statistics. He also recommends a presentation by Richard Steenbergen from NANOG 47. It’s called a practical guide to correctly troubleshooting with Traceroute. Apparently it was so good that Michael Lucas removed Traceroute Mastery from his to-do book list.
There is a lot of useful information packed into this book. I recommend it!
Michael W Lucas
- Get the DRM-free ebook at:
- Amazon US, Amazon Canada, Amazon UK, Amazon DE (and any other Amazon site, of course, but I got tired here)
- Direct from my bookstore (PDF, epub, mobi)
- iBooksGet the print book (also DRM-free)!
- my CreateSpace store
- Amazon US, Amazon UK, Amazon DE
- Other bookstores coming soon
If you’ve bought a Lenovo laptop in recent months it may have come packed with adware called Superfish that also creates massive security holes in your PC
“Major technology companies just can’t help tampering with our Web traffic to deliver advertising. Security researchers recently discovered that consumer-grade Lenovo computers ship with software called Superfish Visual Discovery that injects advertising into websites on browsers like Google Chrome and Internet Explorer.
Even worse, Superfish installs a self-generated root certificate into the Windows certificate store and then resigns all SSL certificates presented by HTTPS sites with its own certificate — the classic definition of a man-in-the-middle attack. It’s a weakness that hackers could potentially use to steal sensitive data like banking credentials or just observe your web surfing activities. ”
In an exclusive interview, Lenovo’s Mark Cohen explains how the Superfish debacle went down
“”What was Lenovo thinking?” asked Paul Venezia yesterday. It turns out it was as surprised as everyone else, according to Windows Ecosystem Vice President Mark Cohen. He told me that the first he knew of the issue was when he started reading about it in the press yesterday.
Presented by Good Technology
10 Best Practices for Implementing a Successful BYOD Program
Harness the benefits of BYOD for your organization including improved user productivity, engagement,
Cohen went on to explain that Lenovo had screened the software from Superfish before it was installed on Lenovo’s consumer laptop lines last September and had asked Superfish to remove certain features that abused SSL connections. Superfish claimed it did this for Lenovo, which then felt confident to ship a feature Cohen told me it saw as a value-add rather than as adware. Cohen claimed the company was unaware of the certificate injection issues until yesterday.
The full magnitude of the problem has gradually unfolded for Lenovo, which is still updating its remediation instructions”
Google Calls FBI’s Plan to Expand Hacking Power a ‘Monumental’ Constitutional Threat
Obama’s New Order Urges Companies to Share Cyber-Threat Info With the Government
Another update on the Truecrypt audit
Open Crypto Audit Project
Is it Alive
show (at) smlr.us or 734-258-7009
Amigita by Circuz
This content is published under the Attribution-Noncommercial-Share Alike 3.0 Unported license.