Network Solutions blog: How Microsoft Teams Enhancements Protect Collaboration

As remote working has increased in popularity, better collaboration tools have become more of a necessity. Microsoft has been paying attention to this trend of course and recently announced numerous enhancements to its Teams platform. Teams has been around for more than a year and combines chat and instant messaging with video conferencing. Most of its newest features are only available on the latest version of its Windows desktop app that was released at the end of July: the web browser and Mac versions are not yet at feature parity.

If you think of Teams as just being a mind-meld between Slack and Webex, you would be underestimating what Microsoft is trying to do with this software. And with the latest update, Microsoft aims to make Teams more of the connective tissue that will bring together its various Office applications, as well as a platform that can enable better collaboration among office workers. This post for Network Solutions’ blog goes into the details.

 

Network Solutions blog: Tools and tips for best practices for WFH network printing

Now that more of us are working from home (WFH), one of the key technologies that can cause problems is surprisingly our networked printers. Hackers target these devices frequently, which is why many IT departments have taken steps to prevent home laptops from connecting to them. In my latest blog post for Network Solutions, I suggest several strategies to help you understand the potential threats and be able to print from home securely, including what IT managers can do to manage them better and what users can do to avoid common security issues.

Network Solutions blog: How to sell your spare IP address block

For the past 27 years, I have owned a class C or /16 block of IPv4 addresses. I don’t recall what prompted me back then to apply for my block: I didn’t really have any way to run a network online, and the Internet was just catching on at the time. The transaction took moments with the exchange of a couple of emails, and there was no cost to obtain the block. 

Earlier this year I was reminded that I still owned this block and that I could sell it and make some quick cash. What was interesting is that in all the years I had the block I had never really used it for anything. I had never set up any computers using any of the 256 IP addresses associated with it. In used car terms, it was in mint condition. Virgin cyberspace territory. So began my journey into the used marketplace that began just before the start of the new year. I document some of this journey in a blog post for Network Solutions. I tell the story about what I learned and what I would do differently knowing what I know now. You can see that block transfers have become a thing from this graph.

I also wrote an eBook for them based on this experience if you want to learn more about the address block aftermarket. And in this more personal post,Beware that it isn’t easy or quick money by any means. It will take a lot of work and a lot of your time.

The evolution of the network protocol sniffer

Last month I caught this news item about Microsoft building in a new command-line feature that is commonly called a network protocol sniffer. It is now freely available in Windows 10 and the post documents how to use it. Let’s talk about the evolution of the sniffer and how we come to this present-day development.

If we turn back the clock to the middle 1980s, there was a company called Network General that made the first Sniffer Network Analyzer. The company was founded by Len Shustek and Harry Saal. It went through a series of corporate acquisitions, spin outs and now its IP is owned by NetScout Systems.

The Sniffer was the first machine you could put on a network and trace what packets were being transmitted. It was a custom-built luggable PC that was typical of the “portable” PCs of that era — it weighed about 30 pounds and had a tiny screen by today’s standards. It cost more than $10,000 to purchase, but then you needed to be trained how to use it. You would connect the Sniffer to your network, record the traffic into its hard drives, and then spend hours figuring out what was going on across your network. (Here is a typical information-dense display.) Decoding all the protocols and tracking down the individual endpoints and what they were doing was part art, part science, and a great deal of learning about the various different layers of the network and understanding how applications worked. Many times Sniffer analysts would find bugs in these applications, or in implementations of particular protocols, or fix thorny network configuration issues.

My first brush with the Sniffer was in 1988 when I was an editor at PC Week (now eWeek). Barry Gerber and I were working on one of the first “network topology shootouts” where we pit a network of PCs running on three different wiring schemes against each other. In addition to Ethernet there was also Token Ring (an IBM standard) and Arcnet. We took over one of the networked classrooms at UCLA during spring break and hooked everything up to a Novell network file server that ran the tests. We needed a Sniffer because we had to ensure that we were doing the tests properly and make sure it was a fair contest.

Ethernet ended up wining the shootout, but we did find implementation bugs in the Novell Token Ring drivers. Eventually Ethernet became ubiquitous and today you use it every time you bring up a Wifi connection on your laptop or phone.

Since the early Sniffer days, protocol analysis has moved into the open source realm and WireShark is now the standard application software tool used. It doesn’t require a great deal of training, although you still need to know your seven layer network protocol model. I have used Sniffers on several occasions doing product reviews, and one time helped to debug a particularly thorny network problem for an office of the American Red Cross. We tracked the problem to a faulty network card in one user’s PC which was just flaky enough to operate correctly most of the time.

Today, sniffers can be found in a number of hacking tools, as this article in ComputerWorld documents. And now inside of WIndows 10 itself. How about that?

I asked Saal what he thought about the Microsoft Windows sniffer feature. “It is now almost 35 years since its creation. Seeing that some similar functionality is now hard wired into the guts of Windows 10 is amusing. Microsoft makes a first class Windows GUI tool, NetMon, available for free and of course there is WireShark. Why Microsoft would invest design, programming and test resources into creating a text-based command line tool is beyond me. What unfilled need does it satisfy? Regardless, more is better, so I say good luck to Redmond and the future of Windows.”

So you wanna buy a used IP address block?

For the past 27 years, I have owned a class C block of IPv4 addresses. I don’t recall what prompted me back then to apply to Jon Postel for my block: I didn’t really have any way to run a network online, and back then the Internet was just catching on. Postel had the unique position to personally attend to the care and growth of the Internet.

Earlier this year I got a call from the editor of the Internet Protocol Journal asking me to write about the used address marketplace, and I remembered that I still owned this block. Not only would he pay me to write the article, but I could make some quick cash by selling my block.

It was a good block, perhaps a perfect block: in all the time that I owned it, I had never set up any computers using any of the 256 IP addresses associated with it. In used car terms, it was in mint condition. Virgin cyberspace territory. So began my journey into the used marketplace that began just before the start of the new year.

If you want to know more about the historical context about how addresses were assigned back in those early days and how they are done today, you’ll have to wait for my article to come out. If you don’t understand the difference between IPv4 and IPv6, you probably just want to skip this column. But for those of you that want to know more, let me give you a couple of pointers, just in case you want to do this yourself or for your company. Beware that it isn’t easy or quick money by any means. It will take a lot of work and a lot of your time.

First you will want to acquaint yourself with getting your ownership documents in order. In my case, I was fortunate that I had old corporate tax returns that documented that I owned the business that was on the ownership records since the 1990s. It also helped that I was the same person that was communicating with the regional Internet registry ARIN that was responsible for the block now. Then I had to transfer the ownership to my current corporation (yes, you have to be a business and fortunately for me I have had my own sub-S corps to handle this) before I could then sell the block to any potential buyer or renter. This was a very cumbersome process, and I get why: ARIN wants to ensure that I am not some address scammer, and that they are selling legitimate goods. But during the entire process my existing point of contact on my block, someone who wasn’t ever part of my business yet listed on my record from the 1990s, was never contacted about his legitimacy. I found that curious.

That brings up my next point which is whether to rent or to sell a block outright. It isn’t like deciding on a buying or leasing a car. In that marketplace, there are some generally accepted guidelines as to which way to go. But in the used IP address marketplace, you are pretty much on your own. If you are a buyer, how long do you need the new block – days, months, or forever? Can you migrate your legacy equipment to use IPv6 addresses eventually (in which cases you probably won’t need the used v4 addresses very long) or do you have legacy equipment that has to remain running on IPv4 for the foreseeable future?

If you want to dispose of a block that you own, do you want to make some cash for this year’s balance sheet, or are you looking for a steady income stream for the future? What makes this complicated is trying to have a discussion with your CFO how this will work, and I doubt that many CFOs understand the various subtleties about IP address assignments. So be prepared for a lot of education here.

Part of the choice of whether to rent or buy should be based on the size of the block involved. Some brokers specialize in larger blocks, some won’t sell or lease anything less than a /24 for example. “If you are selling a large block (say a /16 or larger) you would need to use a broker who can be an effective intermediary with the larger buyers,” said Geoff Huston, who has written extensively on the used IP address marketplace.

Why use a broker? When you think about this, it makes sense. I mean, I have bought and sold many houses — all of which were done with real estate brokers. You want someone that both buyer and seller can trust, that can referee and resolve issues, and (eventually) close the deal. Having this mediator can also help in the escrow of funds while the transfer is completed — like a title company. Also the broker can work with the regional registry staff and help prepare all the supporting ownership documentation. They do charge a commission, which can vary from several hundred to several thousand dollars, depending on the size of the block and other circumstances. One big difference between IP address and real estate brokers is that you don’t know what the fees are before you select the broker – which prevents you from shopping based on price.

So now I had to find an address broker. ARIN has this list of brokers who have registered with them. They show 29 different brokers, along with contact names and phone numbers and the date that the broker registered with ARIN. Note this is not their recommendation for the reputation of any of these businesses. There is no vetting of whether they are still in business, or whether they are conducting themselves in any honorable fashion. As the old saying goes, on the Internet, no one knows if you could become a dog.

Vetting a broker could easily be the subject of another column (and indeed, I take some effort in my upcoming article for IPJ to go into these details). The problem is that there are no rules, no overall supervision and no general agreement on what constitutes block quality or condition. IPv4MarketGroup has a list of questions to ask a potential broker, including if they will only represent one side of the transaction (most handle both buyer and seller) and if they have appropriate legal and insurance coverage. I found that a useful starting point.

I picked Hilco’s IPv4.Global brokerage to sell my block. They came recommended and I liked that they listed all their auctions right from their home page, so you could spot pricing trends easily. For example, last month other /24 blocks were selling for $20-24 per IP address. Rental prices varied from 20 cents to US$1.20 per month per address, which means at best a two-year payback when rentals are compared to sales and at worst a ten-year payback. I decided to sell my block at $23 per address: I wanted the cash and didn’t like the idea of being a landlord of my block any more than I liked being a physical landlord of an apartment that I once owned. It took several weeks to sell my block and about ten weeks overall from when I first began the process to when I finally got the funds wired to my bank account from the sale.

If all that seems like a lot of work to you, then perhaps you just want to steer clear of the used marketplace for now. But if you like the challenge of doing the research, you could be a hero at your company for taking this task on.

Sometimes, the tin-foil hat types are right

A recent story in the NY Times caught my attention. It is about a block in the Cleveland area where some of their wireless car key fobs and garage door openers stopped working. The block is near a NASA research facility, so that was an obvious first suspect. But it wasn’t. The actual source of the problem turned out to be an inventor that was flooding the radio spectrum at the same frequency as the fobs use: 315 Mhz. Once the radio emitter was turned off, the fobs and garage doors started working again. The issue was the inventor’s radio signal was so strong it was preventing anything else from transmitting on that frequency. He had no idea that he was the source of the radio interference.

This story reminds me of an experience that I had back in 1991 or so. At the time, I was the editor-in-chief of Network Computing magazine for what was then called CMP. It was a fun and challenging job, and one day I got a call from one of my readers who was the IT manager for the American Red Cross headquarters in DC. This was Jon Arnold, who spent a long career in IT, sadly dying of a heart attack several years ago. Turns out they had a chapter in Norfolk Va. that was having networking issues. Their office was a small one, of about 25 or so staffers as I recall. Every day their network would start slowing down and then eventually go kaput for several hours. It was at a different time during the day, so it wasn’t the Cleaning Person Problem (I will get to that in a moment). It would come back online sometimes by itself, sometimes with a server reboot. The IT manager asked if I would be willing to lend and hand, and the first person that I thought of to help me was Bill Alderson.

I first met Bill when he was a young engineer for Network General, which made the fabulous Sniffer protocol analyzer. Many of you who are not from that generation may not realize what this tool was or how much of a big deal it was to have a device that could record packet traffic and examine it bit by bit. Today we have open source tools that do the same thing for free, but back then the Sniffer cost four or five figures and came with a great deal of training. Bill cut his teeth on this product and now has his own company, HopZero that has an interesting way to protect your servers by restricting their hop count.

Bill and I first met back in 1989 when I worked at PC Week and we wanted to test the first local area network topologies. We set up three networks, running Ethernet, Token Ring and Arcnet in a networked classroom at UCLA during spring break. All were connected to the same Novell Netware server. Ethernet won the day (as you can see in this copy of the story), and the other topologies died of natural causes. But I digress.

Jon, Bill and I flew to Norfolk and spent a day with the Red Cross staff to try to figure out what was happening with their Novell network. We did all sorts of packet captures that weren’t conclusive. Our first thought was that it had to be something wrong with the server, but we didn’t see anything wrong. Our second thought was more insidious. Being in Norfolk, we were directly down the road from the naval base (you could say that about much of the town, it is a big base). We actually managed to get through to the base commander to find out if their radar was active when they were coming into port. Imagine making that phone call these days in our post-9/11 world? Anyway, the answer we got was negative. Eventually, after hours of shooting down various theories, we figured out the cause of the problem was a wonky network adapter card in someone’s PC. It usually operated just well enough that it didn’t interfere with the network most of the time. Once we replaced the card, everything went swimmingly, and we could put away our tin-foil hats.

Okay, so what is the Cleaning Person Problem? This sounds like folklore, but another reader told me about a problem they had on their network years ago. The reader was periodically disconnected from his network at the same time every night. He was one of the few people online at the time in their office, so it wasn’t like there was high traffic across the network. Eventually, after several evenings he figured out the problem: The cleaning crew was vacuuming the rug in the server room, and the network cable to the server was being run over by the vacuum. Because the cable wasn’t properly crimped and because it was run under the carpet (who knows why this was done), it was shaken just loose enough to disconnect it from the server. When the crew was finished, the cable would operate just fine. Thankfully, they made a better cable and ran it elsewhere where no one could step on it.

The Cleveland folks that had their car fobs disabled actually had it easy: the fault was in a very deliberate emitter that – while initially difficult to trace – was a very binary cause. Their challenge was that not every car fob and garage door was affected. The two scenarios that I mention here were not so cut-and-dried, which made troubleshooting them more difficult. So keep these stories in mind when you are troubleshooting your next computer or networking problem, and don’t be so quick to blame user error. It could be something not as obvious as the odd radio transmission.

Why your networking future shouldn’t include NAT

This post is taken from a recent issue of the Internet Protocol Journal and reused with permission. It is written by Leroy Harvey, a data network architect.

The networking world seems to be losing sight that NAT is a crutch of sorts, a way of dealing with the primary problem of a lack of IPv4 addresses. An earlier article in IPJ stated that NAT provides a firewall function. I think NATs and firewalls are mutually exclusive, even if they are found on the same networking device. This is because NATs don’t by themselves provide any natural protection from the host on the other side of a protection point. The two can operate independently.

NAT does present real-world problems with a number of products, such as Microsoft AD Replication and IBM’s Virtual Tape Library. Passing through a NAT breaks the application’s intended communication model and requires compensating mechanisms.

We are asking the wrong question if we say, “should I deploy IPv6 now”. Someone once told me that IPv6 was here to stay. To my way of thinking, it has not arrived after 25 years.

Let’s look at the situation where we want to merge two large company networks together that both make extensive use of NAT. This becomes more complex than if the two networks were originally using a valid replacement for IPv4 and sadly, that protocol doesn’t exist. While I agree with the notion that the Internet can’t be completely stateless, this doesn’t justify using NAT as middleware. Justifying NAT for the sake of IPv4 life-support is nonsensical.

We should appreciate NAT for its role as a tactical compensating mechanism for IPv4 address depletion, not a a strategic future-proofing scalability mechanism for IPv4. Really what many are saying about NAT is just putting lipstick on the IPv4 pig. Unfortunately, in IT there is nothing more permanent than a temporary solution. Let us not fall victim to this easy psychological trap only because we seem to have collectively painted ourselves into a corner of sorts.

Document your network

Over the weekend, I had an interesting experience. Normally, I don’t go into my office then, which is across the street from my apartment. But yesterday the cable guy was coming to try to fix my Internet connection. During the past week my cable modem would suddenly “forget” its connection. It was odd because all the idiot lights were solidly illuminated. There seemed to be no physical event that was associated with the break. After I power cycled the modem my connection would come back up.

I was lucky: I got a very knowledgeable cable guy, and he worked hard to figure out my issue. I will save you a lot of the description here and just tell you that he ended up replacing a video splitter that was causing my connection to drop. Cable Internet is using a shared connection, and my problem could have multiple causes, such as a chatty neighbor or a misbehaving modem down the block. But once we replaced the splitter, I was good to go.

Now I have been in my office for several years, and indeed built it out it from unfinished space when I first moved in. I designed the cable plant and where I wanted my contractor to pull all the wires and terminate them. But that was years ago. I didn’t document any of this, or if I did have misplaced that information. But the cable tech took the time to make up for my oversight, He tracked down my misbehaving video splitter that was buried inside one of my wall plates. And that is one of the morals of this story: always be documenting your infrastructure. It costs you less to do that contemporaneously, when you are building it, then when you have to come back after the fact and try to remember where your key network parts are located or how they are configured.

Part of this story was that I was using an Evenroute IQrouter, an interesting wireless router that can optimize for latency. I was able to bring up this graph that showed me the last several minutes’ connection details so I knew it wasn’t my imagination.

 

Now my network is puny compared to most companies’, to be sure. But I have been in some larger businesses that don’t do any better job of keeping track of their gear. Oh the wiring closets that I have been in, let me tell you! They look more like spaghetti. For example, here I am in the offices of Checkpoint in Israel in January 2016. Granted, this was in one of their test labs but still it shouldn’t look like this (I am standing next to Ed Covert, a very smart infosec analyst):

 

Compare this with how they should look. This was taken in a demonstration area at Panduit’s offices. Granted, it was set up to show how neat and organized their cabling could be.

Documentation isn’t just about making pretty color-coded cables nice and neat, although you can start there. The problem is when you have to change something, and then you need to keep track when you do. This means being diligent when you add a new piece of gear, or change your IP address range, or add a new series of protocols or applications. So many times you hear about network administrators that opened a particular port and didn’t remember to close it once the reason for the request was satisfied. Or a username which was still active months or years after the user had left the company. I had an email address on Infoworld’s server for years after I no longer wrote for them, and I tried to get it turned off to no avail.

So take the time and document everything. Otherwise you will end up like me, with a $5 part inside one of your walls that is causing you downtime and aggravation.

StateTech magazine: 4 Steps to Prepare for an IoT Deployment

As the Internet of Things (IoT) becomes more popular, state and local government IT agencies need to play more of a leadership role in understanding the transformation of their departments and their networks. Embarking on any IoT-based journey requires governments and agencies to go through four key phases, which should be developed in the context of creating strategic partnerships between business lines and IT organizations. Here is more detail on these steps, published in StateTech Magazine this month.

SecurityIntelligence.com: Protecting Your Network Through Understanding DNS Requests

Most of us know how the Domain Name System (DNS) is a critical piece of our network infrastructure and have at least one tool to keep DNS requests current and clear of potential abuses. Sometimes a little common sense and knowledge of your system log files and the DNS requests contained therein can go a long way toward understanding when your enterprise network infrastructure has been breached. I note a tale from the Cisco Talos blog how they just used some common sense research in my latest blog post for SecurityIntelligence.com today.