Various Stuffs And Things

First of all, you may notice that I've updated the meeting place in the banner above. Meetings of HLUG are now at the Houston HQ of the maker of a popular web hosting application, WHM/cPanel (many thanks to Hal-PC for their past support).

Second, I made last Wednesday's meeting of the group (these are weekly, 6-9pm) and was very impressed at the size and quality of the turnout. The program was on the Hugin Panorama Stitcher program for linux (they have a Sourceforge page), but it was also interesting in that although there was at least one "hobbyist" project going (a user was getting printer hookup help for a recent Ubuntu load), the level of programming/scripting discussion was high, at least to me. Only about half of the 14 or so attendees were cPanel veterans and a wide variety of IT experience was represented.

Third, I also discovered that the cPanel location is not only the host of HLUG now but of the local branch of PerlMongers, the group that does a lot of coding in that manner (Practical Extraction and Reporting Language). I'll get a link for them as soon as I figure out where the Houston Branch is located in the interwebs. ALSO - special thanks to the cPanel executive in attendance who sprung upon me the news that BackTrack (the famous security distro) is now rechristened as Kali Linux. This must have happened over the last 60 days... or maybe I've been distracted more than usual!

More to come - things are happening!

I was only a bystander but here's what I saw...

So this guy says he's getting a bunch of unsolicited SMTP interrogations and it's filling up his logs and requiring him to check in a lot to make sure he's still got room in that directory so as not to strangle commands and crash the server. Could we "fix it"? Actually, no, since we don't manage his stuff, but we checked into it for him by asking another department with the clearance to see more that we can. "This guy" fears some kind of DDOS but our superiors point out that the incoming SMTP connection attempts aren't in amounts any greater that 200kb per second, and add to that the fact that the server operator admits that email isn't that active. I get onto the command line at one point and watch uptime, top, df and so on, noticing not much load or activity.

Apparently there's not much to any of this... except the fact that the guy's logs have been filling up and this effect took the server down at least once. The SMTP requests are coming from many obviously bogus IP's and not actually generating mail. BUT the connections must be logged, so /var/whatever is overloaded at some point and Crash. This looks to my inexperienced eyes like an unusual form of Denial Of Service.

A few of us came up with a strategy for the server operator. First, check in often if nothing else. Second, perhaps come up with a cron job or two that will archive or dump the affected logs based on size. Third, if he has some kind of web hosting control panel like Plesk, there's probably an app that's a front end to crontab or logrotate that would easily schedule size-based dumps as above.

And it came to a head on a weekend. That's the main reason we bought into the DDOS conspiracy theory (much skullduggery happens from Friday to Sunday), but the guy probably needed to set up rotation anyway. Serves him right, as well as us all. Also, he could be misconfigured in 15 other places, in addition to Mr. BogusIPs coming at him.

The moral of the story might be that any protocol activity on any server or application THAT MUST BE LOGGED can constitute a kind of vulnerability, since if not checked, the log directories involved would fill up at some point. And if you didn't throw bogus requests at your target in multi-gigabit-per-second amounts, you fly under the radar of either the server or the network outfits. It's an effective trick, until the target figures it out - or unless the target configured logrotate effectively in the first place.

EDIT: I should know better than to gravitate to conspiracy, particularly when I recall the quote "never attribute to deviousness what can be adequately explained by incompetence"... Another explanation for the above facts (pointed out by someone with more experience in these matters than me) is that, in configuring some DNS matter for email purposes, maybe somebody got one digit of an IP address wrong... and our "victim" is getting someone else's mail through no fault of his own. Think about it: 175 kbps or so, random IP's... yeah, maybe so. It would still be a clever ploy to deny service due to reboot inducement, but again, if one does logrotate right, the issue never comes up.

Current Windows Routine featuring Your Pal, TRK! (edit 2.0 at bottom)

I have several computers in different configurations, OS situations and states of disrepair. For a particular Windows 7 computer, I just went through what's a kind of a weekend routine for cleanup. Here's my checklist for such a machine, useful not only to maintain system health but also to be familiar with the maintenance tools themselves:

1. backup any/all user-created or downloaded important files

2. run onboard utilities like Disk Cleanup, Defrag, MRT (Malicious SW Removal Tool from Microsoft, which takes a long time to run but what the heck), MS Security Essentials

3. run Window/Washer or CCleaner (crap cleaner?)-type third party products for unneeded file removal if you wish

4. run Spyware Blaster by brightfort.com (keep this program around to prevent unauthorized installers from running; it's not antivirus but an installation preventer that's active only at bootup)

And last but not least:

5. use trk with clamav (run commands "freshclam" and "clamscan")

The interesting thing this time around was that I presumed no special knowledge on the user's part and simply downloaded a new copy from the Trinity Rescue Kit download page and selected the self-burning .exe file for Windows. It recognized the onboard burner and asked for a blank, then burned and asked for reboot. Presto - we're a Linux box now (as the hardware reads the burned CD's OS rather than the HDD's OS). Although I had to remind myself of "freshclam" and "clamscan" by looking on the net from a different computer since the help section on the CLI didn't mention those, the run went without issue, taking less than ten seconds to update and less than ten seconds to scan.

I also use Malwarebytes on this particular machine, and should probably do a closer look for this blog on all of these tools. I just wanted to put down this much to record the minimum of my approach for Windows-world maintenance - and I should also repeat my presentation of years ago of running all these things on an intentionally-virus'd machine. That was fun.

-----

NOTE: an editor's addition is coming shortly, which will prove that I am not a complete MORON. The above results were obviously the ten-second results, not the LONG VERSION, which would be to run "updatetrk" and then get serious with "virusscan -a clam; virusscan -a fprot; virusscan -a bde; virusscan -a va" ... these commands update and run four different scanners (there's a fifth, Avast, which I left off since I don't have the free key for it yet) which in order are ClamAV, F-Prot, BitDefender and Vexira. They are running now; stay tuned! (this is gonna take awhile, running as they are in -uiv, or unbelievably insanely verbose mode)

-----

ANOTHER NOTE: Ok, it got a bit more complex. I started out with a clean Windows machine (I use Windows mainly as a movie viewer) but accidentally virus'd myself by getting curious, searching for a free windows version of Vexira, choosing one of the WRONG links (pretending to be genuine) on a search and pulling in about 130 ads. That was an opportunity to run Windows solutions and see if they worked. Malwarebytes actually got almost all of them (126, I think) and they were still gone upon reboot. Further scans by Security Essentials and the protection state of Spyware Blaster didn't note anything. But running the string of four scanners from TRK as mentioned above found an interesting imposition disguised as a legit autorun file. TRK placed it into the conveniently created and named file "TRK-INFECTED". For some reason I found trk's command line difficult to fathom and in desperation found the INFECTED directory and deleted the file using the GUI from another Linux box (but in retrospect the cli was simple). The offender had been rendered inoperative by having been compressed (if there were other changes made to 'anaesthetize' it I haven't discovered what they were via the documentation yet).

So there it is. TRK finds a bad guy - which onboard Windows scanners missed - and rendered it ready for deletion. Four of the five listed scanners were used, but I'm still after days waiting for the free Avast key to show up via email. A full list of all goodies on board (unique to) TRK is at the TrinityHome page (linked above) if you go to the Documentation, then TRK Specific link...and there's an "all commands" link at the bottom of that list on the left.

In My Limited Experience...

In my limited experience with virtual computing instances, many people of all levels of technical competence miss what I consider the obvious. I could be wrong in how obvious these points are, but here they is:

1) If you have 20 virtual instances on one physical host, that host becomes 20 times more important than it was before. Other things being equal (OTBE), that's 19 more phone calls in the middle of the night than the case of only one, when a physical instance goes down. And these are computers. Go down they will. True, it's only the Administrator who gets those emails or calls, but what if that person is on vacation, doesn't answer the phone... or quits?

2) A virtual instance simulates various hardware components with files representing or standing in for them. This does not eliminate everything. This means that a FEW problems go away, like power supply or hardware-related ram failures (out-of-memory problems will still happen). Other things remain, like ALL the administration issues, jobs and potential worries. ALL OF THEM. Although it's virtual, it's still a computer.

3) I can foresee a day when virtual computers will be more stable and reliable than physical ones. We aren't there yet by any measure at all. Those who rush to virtual computing due to cost alone are slowly finding out that there's no magic bullet here.

4) It's just as easy to underbuild a virtual computer as it is to underbuild a physical one.

5) And as one is dealing with these virtual machines, add in all the other problems of networked arrangements like this ("the cloud" or "the fog"), like security issues, the it-all-goes-away-if-you-don't-pay-your-bill matter, the fact that virtuality does not constitute a backup (you still have to do that yourself unless you have a managed - EXPENSIVE - solution), etc., etc.

And a simpler take on "exposure"...

Since my most recent piece on the NSA, there have been more stories of other agencies with data collection programs, plus one on the possibility of remote activation of cell phone microphones (recalling that possibility under certain conditions during the heyday of rotary phones). Whether computers or less complex vectors are involved, I'll repeat some observations I once took to be obvious...

First of all, we should remind ourselves not to do dumb things in general. Here's an article at Bankrate.com about what to do and not do:

Five Ways To Expose Yourself To Identity Theft

Secondly, remember the old movies and TV shows that depict really short telephone numbers and live operators who can overhear conversations? In principle, all communications systems can be party lines. If a conversation is to be private, keep it off of the system (whatever system takes control of the material away from you). And don't discuss it in restaurants or crowded elevators.

Thirdly, if an employer is dumb enough to disqualify you for a job or promotion due to internet remarks, perhaps they don't deserve you. On the other hand, if you're dumb enough to broadcast professionally damaging material about, connected to or from yourself, perhaps they were right to check.

Fourthly, the proper way to handle the legal aspects of information exposure is to start with the reconstitution of the Patriot Act, rolling back its more invasive aspects as mentioned in my earlier post, plus adding big penalties for official abuse of information discovered in "fishing expedition" fashion. The issues here do not concern a particular agency; the issues are about evidence collection as such.

Fifthly, remember that as above, it's not just the agency in the news right now that does information collection. Technology is getting more affordable all the time, such that state and local agencies, less-affluent crooks and even nosy neighbors can buy things with capabilities that were fantasies in 1960's spy movies.

So, don't blame the computer or the phone. We must keep track of what's possible to officials with bad judgement, what's possible in the enacting of bad law, and what's possible when you don't think before you act.

Datamining: The NSA Is Not A Problem!

The recent developments regarding an NSA whistleblower who states concern over invasive practices regarding phone calls and other communications of Americans not accused of any crime deserve careful consideration. But don't make the mistake of blaming field agents - or even upper command - of the National Security Agency, the main cryptographic arm of the US Government. They don't make policy. The politicians do, via the most relevant law here, which is the Patriot act, passed during the previous Presidential administration.

The fix is obvious: keep the ability to do traditional "wiretapping" when backed up by a search warrant documenting probable cause. Rein in the newer blanket permissions that don't require probable cause. Bolster punishments for government abuse of gathered information, as in "fishing expeditions". Sure, it would be more convenient in doing search and seizure if lots of pre-gathered information were available, but that wouldn't be reasonable in the case of the innocent.

And remember what's known of the role of the NSA in helping win the cold war. These agents are soldiers, too. They've risked all and sometimes died just like soldiers who operate in the open, but could never receive the recognition that above-ground GI's get. I don't know of any problem with the whistleblower's argument (as I currently understand it) that we should be alarmed if basic freedoms are threatened, but the fix isn't to demonize operatives every bit as valuable as he. If the public gets clear on the value of our lives and persons, and the politicians don't give us the protections we and the constitution require, then we deal with the politicians, not the soldiers.

And the first thing I did in reaction to these events was not to gripe on Facebook or Twitter and not even to post this blog. It was to send $35 to the National Cryptologic Museum. This project works to build a new facility to preserve the history of the NSA, and is near the National Vigilance Park, which preserves listening post aircraft similar to those lost in service. If we forget the significance of our own heroic actions and those of our forefathers, the cost will be our souls.

Hurricane Season!!

...which isn't just for the American South anymore, as NYC recently demonstrated. So along my usual lines of best practice suggestions, what would be prudent to think about under the conditions that began June 1st?...

OFFSITE BACKUP LOCATIONS - Yes, there's the net or the network or the cloud or the fog. But if data is pushed somewhere, is it being pushed only down the street where the same flood that hits you hits the data center? And if the data center is across the country or world, how much data creeps across the connection how slowly?

POWER CONDITIONING - Power is certainly a consideration when a blackout removes it. But when power is available, it could be "dirty", fluctuating in damaging patterns and amounts.

PHYSICAL PLANT ISSUES - How's the electricity situation at your site or data center? Is there a generator or secondary source? What about physical security, like the condition of the doors, gates, windows? How about the architecture and condition? What if the roof comes off? Does the place normally leak during heavy rain? (One might stop by sites during inclement weather for inspections).

LOCAL EQUIPMENT - Think about flashlights, flashlight batteries, first aid and storm kits, tools, etc. that might be good to stash around the workplace.

ALARM FAILURE - If power fails or a falling tree physically damages some asset, what's the backup plan? Email or text message communication generated by software will be problematic if the host machine itself can't operate. And is there a secondary plan for the phone contact tree?

GENERAL COMMUNICATIONS - Even if you have an old-style pulse phone in the place (they still work in storms due to their internal magneto), an old-style answering machine still needs AC power to work. And if it's a newer desk phone, it needs AC itself. Does everybody have chargers for their cell phones? Preferably in their cars?

STORED FUELS - As well as diesel or gasoline for the generator, are other fuels needed? Bottled gases or lubricants?

EMP - I don't expect nuclear attack, but other causes of electromagnetic problems are likely, such as sunspot activity or detonation of a transformer on top of a nearby telephone pole. As unlikely as it would be for most assets to need to have Faraday cage protection, some might benefit from that. Most, though, could be protected with less complex or expensive isolation or shielding.

-----

COMING ATTRACTIONS: As soon as I can, I'll get to some projects on which to report, such as recent looks at nMap, CrunchBang Linux and TRK's latest version.