NMCI and Other Nefarious Adventures

Yep. A little too quiet....

Hear no evil, see no evil, speak no evil.

Censorship is not dead! It appears that NMCI began blocking network access to our site sometime around the middle of February. We are not sure about this but we've had reports from several people and the lack of NMCI gateways in our log files would appear to confirm this.



Am I upset about this? No way! I'm flattered! To think that someone at NMCI was so afraid of their users finding out the truth that they actually changed their configurations to block our site. I couldn't ask for better publicity!

Our readers will connect to us from their home ISPs or from legacy networks. Or they can simply read the cached articles on Google. Big brother hasn't made it into every aspect of our lives just yet but they are giving it the old college try.

At the risk of being too sanctimonious, let me offer the following:

We are not saying anything in these pages that isn't said out loud, every day, by thousands of victimized NMCI users. I could play a game of cat-and-mouse and move to a different IP address. I could do some tricky DNS stuff. But that would just be playing their game. No, we will be here... right here. We will continue to publish, even if nobody from the NMCI leadership wants to read it. Obviously they don't want you to read it.

Say "Happy Birthday!" to your NMCI computer today. Your operating system is six years old.

Actually its well over six years old but that was the official birth date.

Are you patched? Could you do anything about it if you weren't?

Let's be clear up front, we are not advocating anything below and doing anything proposed below may not be permitted by your local authority. However, we know of at least one instance where these types of things were permitted for certain mission requirements. We are also not sure if all of these would work as we have not tried them ourselves. Your mileage may vary. We'd be interested to hear any test results.

What if we could run a real application on our NMCI machines without violating the rules about installing software? Do you long to use Firefox or Thunderbird or a real FTP application? Do you need to use secure shell (SSH) to talk to devices or other servers?

Although it was rumored that you could install Firefox without modifying the registry at a non-S&T seat, doing so would still be prohibited by the "install no software" rule. Here is a way to use the full-blown Firefox and other applications without actually installing anything.

Portable Firefox is available which can be run off a USB drive. You can save all your settings and even import settings from your legacy machines.

They have several other applications available at the Portable Apps Site which should run fine on NMCI desktops and laptops.

What if you need to do something that just isn't possible in Windows 2000? Could you load Linux on an NMCI machine? No.

Well, maybe.

There is no reason that Damn Small Linux could not be booted from a CD. Or if you need more horsepower, Knoppix is certainly the king of bootable Linux CDs. It should recognize all the hardware on both NMCI laptops and NMCI desktops. It would leave the internal hard drives untouched. Leaving the NMCI machine connected to the NMCI network while booted into Linux would probably not be advisable.

Of course one extremely valuable use for a bootable Linux CD would be disaster recovery of a damaged NMCI Windows installation or a hard drive failure. Both Knoppix and DSL should mount both the internal hard drive and an external USB device. This would allow you to copy documents off the hard drive and on to the memory stick or other external drive. As the internal hard drives are (presumably) formatted as NTFS, you would not be able to write information to the internal hard drive of an NMCI computer. That's probably a good thing.... Although Linux is close to being able to mount an NTFS drive as read/write.

The initial promise of the NMCI Science and Technology (or S&T) seat was great. Some call it a "developer's" account or "dot dev" after the login name but it is all the same thing. Users believed that they would have significant advantages over the standard NMCI user seat. Indeed, the S&T seat was conceived to answer the needs of the programmers, developers, engineers and technicians that required more control over their computing environment. What these power users received was something less than they expected.

Let's take a look at some of the common beliefs about the S&T seat and see what is true and what isn't true. We make no judgment on some of these policies as a few of them "come with the territory" when you subscribe to a managed IT paradigm and would probably be imposed on any managed IT user in any corporate setting. As always, we leave the cost vs. benefit evaluation of this managed IT world to the reader.

S&T users have administrative privileges on their computers
This is only partially true. One also has to place this within the context of other restrictions placed on the NMCI user, many of which will be discussed below. S&T users do indeed have administrative privileges however some of the common things that an administrator would want or need to do are not possible as an S&T user.

Simply logging in to the Microsoft Windows Update site to install security updates is not allowed. This is understandable when you consider that NMCI and the Navy have carefully carved their NMCI seats into a very custom build with some security/performance updates installed and others not installed. Although this is not a completely uncommon practice among managed IT systems, there is always something to be said for simply keeping everything current. Much of the tripe circulating in IT circles about "black Tuesday" upgrades breaking machines is nothing short of rumor and anti-Microsoft propaganda. Millions of fully updated users can prove this pick-and-choose methodology wrong every day. Trying to juggle various updates (for an outdated operating system such as Windows 2000) and installing some and not installing others proves to be very difficult and often needlessly exposes users to security vulnerabilities.

If an S&T user attempts to use Windows Task Manager to cancel a zombie (or annoying) process, there is no guarantee such an action will meet with success. Often such attempts will be met with "Operation could not be completed. Access is denied."

There are likely other Administrator actions, like Windows Update, that are physically blocked or broken to the S&T user. Yet by far, most of the capabilities of an Administrator user are blocked by policy and rule rather than hard, OS-based enforcement. Many of these are discussed in the following paragraphs.

S&T users can install any software they want
This is categorically false. Although the operating system, as configured, may not prevent an S&T user from installing software even if registry changes are required, it is against NMCI policy to do so. Even installing something as innocuous as an updated Microsoft hardware driver is not allowed.

Of course NMCI requires the computer user to have valid licenses for all installed software. This is nothing unusual. What is unusual is that even if the user has a boxed, licensed copy of a piece of software, there is no guarantee that they can install it. The software must be on a list of approved applications. The exact version the user wishes to install must also be on the list. If it isn't, the user's only recourse is to submit the desired software to NMCI for approval. The vaunted approval process has been tried by only a few hearty souls willing to endure the costly and lengthy process of having NMCI technicians test and endorse the software. One could say, "Well, of course they don't want users installing random software, it could break the OS/computer/network!" This would be true except for one thing: NMCI throws its S&T users to the wolves anyway. See S&T users can not call the help desk below.

So suppose an S&T user is lucky enough to find his desired application on the approved list. He still has to notify his local NMCI officials that he is installing the software and submit paperwork to do so. Any software found installed on a system that is not part of an official push or a documented subsequent S&T install is grounds for immediate revocation of user privileges and disciplinary action.

S&T seats are not allowed access to E-mail
This is true while logged in as the S&T user. Although we have reports of several S&T users who regularly access NMCI email (normally sent to their non-S&T accounts) this is still, as far as we know, prohibited under NMCI policy. This requires S&T users to log out of their S&T accounts and log back in as a non-S&T user just to check their E-mail, several times a day. One could speculate on the reason for this policy however we would hope that it is being done for security reasons.

S&T users can not do custom network applications
This is true at most sites on most network segments. The S&T user is subjected to the same draconian IP network filtering as the non-S&T user. There are no open ports except those that are proxied by NMCI proxy servers. This makes custom network applications impossible to test on the NMCI network. S&T seats could easily be placed on a VLAN to keep them separate from the protected non-S&T network and allow S&T users the flexibility they need to work with network-intensive applications.

S&T users have access to BuRAS
This is false. It is more false than it might first appear. S&T users are not only prohibited from using BuRAS while they are logged in as S&T users, they can't even use it while they are logged in as regular users. In fact, NMCI has refused to push the BuRAS software to any machine that is operated as an S&T seat. So even if the user has never logged in to his S&T account, he does not have the same BuRAS capability as the non-S&T user sitting next to him. This policy is supposed to change in the near future but as it presently stands, the S&T user is on the losing end again.

Software development is impossible on an S&T seat
This is true. This is another example where NMCI policy oversteps the physical limitations on the administrative user. Even if the user installs a compiler that is from the approved application list he is violating policy simply by compiling source code. Part of the agreement for S&T users is that they will not "execute, install or compile" non approved code. Obviously if they are developing new software, it is not on the approved application list.

S&T users can not call the help desk
This is partially -- the most important part -- true. Science and Technology users are welcome to call the help desk as long as it doesn't involve a software issue. It doesn't matter if the user has never installed anything on the computer. NMCI has deemed S&T users as experts and throws them to the wolves in terms of help desk support. The actual CLIN says, "Customer support will be limited to those services offered by EDS and not extend to software or hardware loaded and configured by the user." Yet in reality S&T users are told not to call the help desk for anything remotely related to software. So one could ask, "If they are not going to support me, why can't I install any software I want?" If the help desk is going to treat S&T users differently whether they install some bizarre piece of software or nothing at all, why put restrictions on the software?

There are probably other fine points of the Science and Technology lifestyle that we haven't discussed here but we hope the above items are enough food for thought. One now has to ask, "Is all this really worth an extra $25 per month?"

Several people have asked about NMCI being hacked on or around 20 October. Our site traffic stats also reflect an increased interest in this possible event. We can neither confirm nor deny any compromise of the NMCI infrastructure. We don't have a clue.

We have resisted posting anything here until now in an attempt to allow any security compromises to be handled or at least minimized. However Federal Times was not afraid to publish.

The truth is, we have no information. And if we did, we wouldn't post it here.

Thanks for asking though.

Hold on folks, we're in for a bumpy ride.

Rumor has it that the vaunted Phase II of the Spam Flail-ex is about to begin. Several sources from an east coast facility say that "suspected spam" quarantining will start in the near future. As reported here earlier, users will have a fixed amount of time to respond to messages put into the quarantined area before it is deleted. If the user is unable, for whatever reason, to access his mailbox during the quarantine period, the E-mail is deleted. Messages determined to be "known spam", as opposed to suspected spam, will be dealt with even more swiftly -- it will be deleted immediately with no notification to the intended recipient.

We can only hope that the tagging debacle of a few months ago does not portend a quarantine storm where dozens of legitimate E-mails per day end up erroneously identified as spam.

Anyone who observed the monumental failure of spam tagging is surely holding their breath for the quarantine phase. We can only hope that the powers-that-be noticed the problems with tagging and have tweaked the spam identification process to prevent the same false-positive problem from occurring with this new phase.

We can always hope.

Once again we see fallacy in action. NMCI has apparently started blocking web access to Hotmail, Yahoo Mail, Google Mail and other on-line, web-based mail sites. So what could their reason be for such a drastic measure?

Very simply this is DoN policy. That's right folks, don't blame the good folks at EDS for this one. The Navy has deemed access to unofficial E-mail as an unacceptable risk to the integrity of their internal networks. Certainly users could unsuspectingly download a virus, worm, Trojan, malware or other Nasty in the form of an E-mail or attachment.

Yet one needs to ask, how is downloading such a threat from an E-mail site any more likely than acquiring one from a regular website? What makes web E-mail any more of a threat?

In fact, there are several things that make such a stance even more illogical and lay fallacy to the idea that web-based E-mail is a higher threat.

First, most large web-based E-mail services do scanning on attachments. Yahoo, AOL, Juno and others all scan their user's E-mail for suspicious items. So most of these sites are probably less likely to have dangerous code on them than millions of other regular websites.

Secondly, in the same vein, how are the file links on a regular website checked when a user clicks on them? Perhaps in the NMCI HTTP proxy system, but does this checking occur for SSL sites? Point is, if there is a threat on web mail sites, then there is a threat on all web sites. Maybe they should block access to everything except .mil and .gov sites. I know. Don't give them any ideas.

Third, many of the recent vulnerabilities publicized for Microsoft products do not need a user-executed code vector to do their business, they exploit flaws in the browser itself. There are several easily exploited weaknesses that Microsoft has been quick to address in its current Internet Explorer products and Windows XP-SP2. Once again we see the problems with having an outdated OS and application software on NMCI seats. So if the exploit is on the webpage itself, and has nothing to do with a user downloading a malicious attachment, some of the safest sites on the net would be reputable sites like Hotmail, Yahoo and AOL.

Lastly, we wonder where the NMCI proxy administrators got their list of web-based E-mail sites. How complete could it be? How many thousands of Squirrelmail sites and small ISP sites are out there?

Their method for "blocking" these sights appears to be little more than DNS modification. So someone at the central site has gone through the domain name servers and put manual entries in for things like mail.yahoo.com and www.hotmail.com. These new entries redirect the user to a warning banner instead of taking them to the requested mail web page. Of course this means that any local user (S&T .dev account not required) can modify their own hosts table to override these same DNS entries. For Windows 2000 users this means simply going into c:\winnt\system32\drivers\etc\hosts and placing a few entries like:

66.218.75.184 mail.yahoo.com
64.233.185.83 mail.google.com

In reality it would prove a little more difficult as many mail sites use many different host names and jump around during the user session. It all comes down to following the rules -- the admins can make things more difficult and keep out the casual user but if someone insists on breaking the rules, they will.

There was also widespread speculation that the stance resulted from (or the fear of) users forwarding Government E-mail to non-Government servers -- for whatever reason. This opens up the possibility of FOUO, Privacy Act, Procurement Sensitive and even classified data (which would point to bigger problems) being sent to servers outside the Government's control. The thought of NMCI going to Yahoo and asking them to wipe their terrabytes of hard drives simply to remove one FOUO memo is not something anyone wants to deal with. It is still unclear how restricting web access to these remote sites has anything to do with someone writing an auto-forward rule in Outlook. Keeping them from reading it is different than keeping them from sending it.

At some point it all comes back to trusting the users to follow the policy. If the policy states that DoN users are not allowed to access personal E-mail from an NMCI seat, then at some point that has to be good enough. People are going to put infected floppies, USB drives and CDs into their seats. People are going to forward inappropriate mail to outside addresses. People are going to visit compromised web sites with an outdated browser. People are going to open infected attachments received through NMCI/Outlook. Web-based E-mail is probably the least of our worries. Blocking major websites is nothing more than window dressing. Once again....