So some Chief Tech Security people...

... might be scrambling, considering the latest data breaches being reported by Forbes Online. Or maybe they're not.

According to this story, malware, employee misconduct, phishing scams or whatever has recently affected either customers or third party participants in the business activities of JP Morgan Chase, Dairy Queen, Touchstone Medical Imaging and AT&T (in addition to Target and Home Depot a month or two back). What if you were in charge of Information Security at those joints? What would your day have been like this week?

Maybe it would have been crisis mode - or perhaps just another day at the office. If I were one of those people and were reasonably decent at my job, I think I'd be memo-ing quite a bit. My main memo this week would have had an email subject line with a nice version of "I TOLD YOU SO". I'd first list the things that I'd been recommending to management that our people do for best practices, with emphasis on what measures had been overruled, when, why, by whom and hopefully with meeting minutes from the discussion in which I was shot down due to impracticality. Then I'd list or link the emails that had been sent out detailing voluntary or mandatory practices that people were actually supposed to be following and to which management had actually given lip service.

So, contingencies list: call up money for the security consultant outfit to do damage control, get the important password change procedure, pull tested backups from secure or offsite location, reload sensitive systems... and regularly tell certain people "I Told You So". This last only works if one DID tell them.

Job Opportunities

If you have a working knowledge of Linux server and/or Windows server operation (and networking or scripting would be plusses), take a look at the Houston Softlayer offerings at Softlayer's link to the IBM Employment page:

http://www.softlayer.com/careers

Softlayer is a major force in both physical and virtual server rental, second only to Google in number of servers currently under administration, and is now a division of IBM.

If your talents lean toward programming, specifically in Larry Wall's venerable PERL, give

http://cpanel.net/jobs-site

a look. Their Houston office has openings in support and in development.

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.