Who is responsible?

Galina Pildush ended her LTE presentation with a very good question:”Who is responsible for LTE security?  Is it the users? UE (User Equipment, handsets and devices) manufacturers and vendors?  Network providers, operators and telcos?”

It’s a great question, and one that needs to be applied to every area of security.

In the SOHO (Small Office/Home Office) and personal sphere, it has long been assumed that it’s the user who is responsible.  Long assumed, but possibly changing.  Apple, particularly with the iOS/iPhone/iPad lines, has moved toward a model where the vendor (Apple) locks down the device, and only allows you certain options for software and services.  Not all of them are produced or provided by Apple, but Apple gets vetting responsibilities and rights.

The original “user” responsibility model has not worked particularly well.  Most people don’t know how to protect themselves in regard to information security.  Malware and botnets are rampant.  In the “each man for himself” situation, many users do not protect themselves, with significant consequences for the computing environment as a whole.  (For years I have been telling corporations that they should support free, public security awareness training.  Not as advertising or for goodwill, but as a matter of self defence.  Reducing the number of infected users out there will reduce the level of risk in computing and communication as a whole.)

The “vendor” model, in Apple’s case (and Microsoft seems to be trying to move in that direction) has generated a reputation, at least, for better security.  Certainly infection and botnet membership rates appear to be lower in Macs than in Windows machines, and lower still in the iOS world.  (This, of course, does nothing to protect the user from phishing and other forms of fraud.  In fact, it would be interesting to see if users in a “walled garden” world were slightly more susceptible to fraud, since they were protected from other threats and had less need to be paranoid.)  The model also has significant advantages as a business model, where you can lock in users (and providers, as well), so it is obviously going to be popular with the vendors.

Of course, there are drawbacks, for the vendors, in this model.  As has been amply demonstrated in current mobile network situations, providers are very late in rolling out security patches.  This is because of the perception that the entire responsibility rests with the provider, and they want to test every patch to death before releasing it.  If that role falls to the vendors, they too will have to take more care, probably much more care, to ensure software is secure.  And that will delay both patch cycles and version cycles.

Which, of course, brings us to the providers.  As noted, there is already a problem here with patch releases.  But, after all, most attacks these days are network based.  Proper filtering would not only deal with intrusions and malware, but also issues like spam and fraud.  After all, if the phishing message never reaches the user, the user can’t be defrauded.

So, in theory, we can make a good case that the provider would be the most effective locus for responsibility for security.  They have the ability to address the broadest range of security issues.  In reality, of course, it wouldn’t work.

In the first place, all kinds of users wouldn’t stand for it.  Absent a monopoly market, any provider who tried to provide total security protection, would a) incur prohibitively heavy costs (putting pressure on their competitive rates), and b) lose a bunch of users who would resent restrictions and limitations.  (At present, of course, me know that many providers can get away with being pretty cavalier about security.)  The providers would also, as now, have to deal with a large range of devices.  And, if responsibility is lifted from the vendors, the situation will only get worse: vendors will be able to role out new releases and take even less care with testing than they do now.

In practical terms, we probably can’t, and shouldn’t decide this question.  All parties should take some responsibility, and all parties should take more than they do currently.  That way, everybody will be better off.  But, as Bruce Schneier notes, there are always going to be those who try and shirk their responsibility, relying on the fact that others will not.

Share

LTE Cloud Security

LTE.  Even the name is complex: Long-Term Evolution of Evolved Universal Terrestrial Radio Access Network

All LTE phones (UE, User Equipment) are running servers.  Multiple servers.  (And almost all are unsecured at the moment.)

Because of the proliferation of protocols (GSM, GPRS, CDMA, additional 3 and 4G, and now LTE), the overall complexity of the mobile/cell cloud is growing.

LTE itself is fairly complex.  The Protocol Reference Model contains at least the GERAN User Plane, UTRAN User Plane, and E-UTRAN User Plane (all with multiple components) as well as the control plane.  A simplified model of a connection request involves at least nine messages involving six entities, with two more sitting on the sides.  The transport layer, SCTP, has a four-way, rather than two-way, handshake.  (Hence the need for all those servers.)  Basically, though, LTE is IP, but a fairly complex set of additional protocols, as opposed to the old PSTN.  The old public telephone network was a walled garden which few understood.  Just about all the active blackhats today understand IP, and it’s open.  It’s protected by Diameter, but even the Diameter implementation was loopholes.  It has a tunnelling protocol, GTP (GPRS Tunnelling Protocol), but, like very many tunnelling protocols, GTP does not provide confidentiality or integrity protection.

Everybody wants to the extra speed, functions, interconnection abilities, and apps.  But all the functionality means a much larger attack surface.  The total infrastructure involved in LTE is more complex.  Maybe nobody can know it all.  But they can know enough to start messing with it.  From a simple DoS to DDoS, false billing, disclosure of data, malware, botnets of the UEs, spam, SMS trojans, even run down batteries, you name it.

As with VoIP before it, we are rolling our known data vulnerabilities, and known voice/telco/PBX vulnerabilities, into one big insecurity.

Share

Probing mobile (cell) networks

Mobile networks have many disparate types of devices.  You can probably guess what some of them are, or even go to the provider’s store or kiosk and get a list.  But there are going to be more devices out there.  So why not scan the IP addresses on your subnet?

Well, the access points for mobile networks generally don’t allow promiscuous access.  So you may have to go to ARIN and other lists in order to start getting some ranges to check.  You can also check access logs of a Website to find visitors with mobile devices.  (Of course, there is always the NATting that the providers do, not to mention DHCP, and the fact that most mobile devices don’t run servers or services.)

Colin Mulliner, of the Berlin Institute of Technology, did manage to find a fair amount of interesting stuff.  Windows Mobile tended to be a useful source of open ports and services (usually open FTP services on mobile devices).  He also found and was able to identify a number of specialized devices that were identifiable from responses to probes.  Some of the most interesting were mobile access points: connecting to the mobile networks and then providing local wifi for computers.  Others were HTTP servers for surveillance cameras.  (Others were GPS tracking devices which, oddly, had no security against “guest” login  :-)  (Some were smart meters.  With smart meters rolling out here in BC, lets hope they are more secure …)

Possibly of concern was the large number of jailbroken iOS devices.  Many of them still had the default “alpine” password.  (If you hack your own device, you’d better be prepared to secure it.)  This could form the basis of a fair sized worm and/or botnet.  Then again, iOS users aren’t alone here.  An awful lot of people seem to think nothing of creating mobile devices and hooking them up to mobile networks with very little in the way of security.

Share

Smartphone vulnerabilities

Scott Kelly, platform architect at Netflix, gets to look at a lot of devices.  In depth.  He’s got some interesting things to say about smartphones.  (At CanSecWest.)

First of all, with a computer, you are the “tenant.”  You own the machine, and you can modify it any way you want.

On a smartphone, you are not the only tenant, and, in fact, you are the second tenant.  The provider is the first.  And where you may want to modify and customize it, the provider may not want you to.  They’d like to lock you in.  At the very least, they want to maintain some control because you are constantly on their network.

Now, you can root or jailbreak your phone.  Basically, that means hacking your phone.  Whether you do that or not, it does mean that your device is hackable.

(Incidentally, the system architectures for smartphones can be hugely complex.)

Sometimes you can simply replace the firmware.  Providers try to avoid doing that, sometimes looking at a secure boot system.  This is usually the same as the “trusted computing” (digital signatures that verify back to a key that is embedded in the hardware) or “trusted execution” (operation restriction) systems.  (Both types were used way back in AV days of old.)  Sometimes the providers ask manufacturers to lock the bootloader.  Attackers can get around this, sometimes letting a check succeed and then doing a swap, or attacking write protection, or messing with the verification process as it is occurring.  However, you can usually find easier implementation errors.  Sometimes providers/vendors use symmetric enryption: once a key is known, every device of that model is accessible.  You can also look at the attack surface, and with the complex architectures in smartphones the surface is enormous.

Vendors and providers are working towards trusted modules and trustzones in mobile devices.  Sometimes this is virtual, sometimes it actually involves hardware.  (Personally, I saw attempts at this in the history of malware.  Hardware tended to have inherent advantages, but every system I saw had some vulnerability somewhere.)

Patching has been a problem with mobile devices.  Again, the providers are going to be seen as responsible for ongoing operation.  Any problems are going to be seen as their fault.  Therefore, they really have to be sure that any patch they create is absolutely bulletproof.  It can’t create any problems.  So there is always going to be a long window for any exploit that is found.  And there are going to be vulnerabilities to exploit in a system this complex.  Providers and vendors are going to keep trying to lock systems.

(Again, personally, I suspect that hacks will keep on occurring, and that the locking systems will turn out to be less secure than the designers think.)

Scott is definitely a good speaker, and his slides and flow are decent.  However, most of the material he has presented is fairly generic.  CanSecWest audiences have come to expect revelations of real attacks.

Share

Net accesses …

So, I’m always excited about CanSecWest, and I was yesterday, as I got ready.  I went to do a last minute download of email.  (Yes, the conference provides wireless, and it usually works, after a few initial glitches.  But I like to avoid risks, and I like to have most of my stuff with me on my machine.)

I could pull the email off my main account.  (I have multiple email addresses with Shaw.)  But I couldn’t get any email off the subsidiary accounts.  In order to check if this was some setting gone wrong on my MUA I tried the Web interface.  Same result: I could get at my main account, but not the subsidiary accounts.

Later in the day, at the conference, I was able to access all the accounts.  But I found that, while my main account was still accessible though the original interface, suddenly all the others were using a new “Webmail 2.0.”

I thought this was kind of odd, so I reported this to Shaw through their “ShawHelp” account on Twitter.  You can’t explain a lot in 140 characters, so we passed a few “direct messages” back and forth.

I have previously mentioned that Shaw’s support is not the best, and their attitude to security could use some work.  (As a side result of this, a friend has provided me with an emergency proxy for outbound email.  I tried it this morning, and, unlike Shaw, which requires that you be on their network before you get access to your email, it works from CanSecWest.)  So I shouldn’t have been shocked when I got a message from ShawHelp saying … well, let me quote it:

“Not seeing issues with either of them. You can’t log into cissp? What is password so we can take a look? ^LL”

I had forgotten this.  In the old days, when I stilled tried to call Shaw support when I had a problem, I frequently got asked for my password.  Since I won’t give them my password (what do you think I am, a normal user?), that usually ended any attempt on their part to deal with the problem.

So, here we are, some years later, and Shaw is still asking their customers for passwords.  How many years have we been telling people, “customer support will never ask you for your password”?

On a very slightly positive note, I can say that, two months after they announced it, the Shaw Wifi AP in Lynn Valley is finally operating.

(I suppose I shouldn’t bash too hard on Shaw.  Their tech support and security is abysmal, but the service only goes down about once a quarter.  The other day I was at the barbershop.  They are putting in service through the other major provider in our area, Telus.  Telus’ initial installation had only given them partial access, so they called in Telus’ support.  The support tech managed to shut off access completely, and had been coming back, sporadically, for over a week, without success.)  (Yes, I did manage to get them partial access back …)

Share

Forcing your users to write down their passwords

This sums up everything that is wrong with the “password policy” theme. From the t-mobile web site:

T-Mobile Password Policy

There is no way any reasonable person can choose a password that fits this policy AND can be remembered (note how they are telling you that you CANNOT use special characters. So users now have to bend according to the lowest common denominator of their bad back-end database routine and their bad password policy).

I’m sure some high-paid consultant convinced the T-MO CSO that stricter password policy is the answer to all their security problems. Reminds me of a story about an air-force security chief that claimed 25% increase in security by making mandatory password length 10 characters instead of 8, but I digress.

Yes, I know my habitat. No security executive ever got fired for making the user’s experience more difficult. All in the name of security. Except it’s both bad security and bad usability (which, incidentally, correlate more often than not, despite what lazy security ‘experts’ might let you believe.

I’ve ranted about this before.

Share

2nd Annual Cyber Security China 2012

It seems like nowadays China is the immediate suspect when it comes to hacking attempts or cyber espionage. It’s therefore interesting to know that they are suffering from as much internal attacks as anyone else.

The ‘cyber security china 2012′ is organized with ISC2, which is typically a good indicator for interesting speakers and content (at least, that’s been my past experience in other countries). The description shows that the Chinese are worried about the same things we all are:

With support from Ministry of Public Security  of  China,  and  working  with  ISC2, ITU-IMPACT and  ISFS Hong kong, Cyber Security China 2011  is successfully organized in March 24-25 in Shanghai, China.  The  2011  event convened 130+ delegates from global and local cyber security authorities, government, law enforcement  agencies, users  and  security  vendors,  and  mainly  explored  the solutions  against  evolving cyber  threats  and  attacks,  and how to fight the  cyber crimes through public-private-partnership.

More information here.

Share

REVIEW: “Above the Clouds”, Kevin T. McDonald

BKABVCLD.RVW   20110323

“Above the Clouds”, Kevin T. McDonald, 2010, 978-1-84928-031-0,
UK#39.95
%A   Kevin T. McDonald
%D   2010
%G   978-1-84928-031-0 1-84928-031-2
%I   IT Governance
%O   UK#39.95
%O  http://www.amazon.com/exec/obidos/ASIN/1849280312/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1849280312/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1849280312/robsladesin03-20
%O   Audience n+ Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   169 p.
%T   “Above the Clouds: Managing Risk in the World of Cloud Computing”

The preface does a complicated job of defining cloud computing.  The introduction does provides a simpler description: cloud computing is the sharing of services, at the time you need them, paying for the services you need or use.  Different terms are listed based on what services are provided, and to whom.  We could call cloud computing time-sharing, and the providers service bureaus.  (Of course, if we did that, a number of people would think they’d walked into a forty-five year time-warp.)

The text is oddly structured: indeed, it is hard to find any organization in the material at all.  Chapter one states that the cloud allows you to do rapid prototyping because you can use patched operating systems.  I would agree that properly up-to-date operating systems are a good thing, but it isn’t made clear what this has to do with either prototyping or the cloud.  There is a definite (and repeated) assertion that “bigger is better,” but this idea is presented as an article of faith, rather than demonstrated.   There is mention of the difficulty of maintaining core competencies, but no discussion of how you would determine that a large entity has such competencies.  Some of the content is contradictory: there are many statements to the effect that the cloud allows instant access to services, but at least one warning that you cannot expect cloud services to be instantly accessible.  Various commercial products and services are noted in one section, but there is almost no description or detail in regard to actual services or availability.

Chapter two does admit that there can be some problems with using cloud services.  Despite this admission some of the material is strange.  We are told that you can eliminate capacity planning by using the cloud, but are immediately warned that we need to determine service levels (which is just a different form of capacity planning).  In terms of preparation and planning, chapter three does mention a number of issues to be addressed.  Even so, it tends to underplay the full range of factors that can determine the success or failure of a cloud project.  (Much content that has been provided previously is duplicated here.)  There is a very brief section on risk  management.  The process outline is fine, but the example given is rather flawed.  (The gap analysis fails to note that the vendor does not actually answer the question asked.)  SAS70 and similar reports are heavily emphasized, although the material fails to mention that many of the reasons that small businesses will be interested in the cloud will be for functions that are beyond the scope of these standards.  Chapter four appears to be about risk assessment, but then wanders into discussion of continuity planning, project management, testing, and a bewildering variety of only marginally related topics.  There is a very terse review of security fundamentals, in chapter five, but it is so brief as to be almost useless, and does not really address issues specifically related to the cloud.  The (very limited) examination of security in chapter six seems to imply that a good cloud provider will automatically provide additional security functions.  In certain areas, such as availability and backup, this may be true.  However, in areas such as access control and identity management, this will most probably involve additional charges/costs, and it is not likely that the service provider will be able to do a better job than you can, yourself.  A final chapter suggests that you analyze your own company to find functions that can be placed into the cloud.

Despite the random nature of the book, the breadth of topics means it can be used as an introduction to the factors which should be considered when attempting to use cloud computing.  The lack of detail would place a heavy burden of research and work on those charged with planning or implementing such activities.  In addition, the heavily promotional tone of the work may lead some readers to underestimate the magnitude of the task.

copyright, Robert M. Slade   2011     BKABVCLD.RVW   20110323

Share

Shaw’s idiot spam filter again

And, once again, Shaw has cut off my outbound email.  For no reason that I can determine.  This time tech support aren’t even answering messages.

Maybe I should make the point that if I can’t answer my email, I have more time to blog about their lousy service …

Share

Shaw and Spamhaus

I seem to be back on the air.

A few observations over this whole affair:

(Sorry, I’ve not had time to put these in particular order, and some of the point may duplicate or relate …)

1) I still have absolutely no idea why Shaw cut me off.  They keep blaming Spamhaus, but the only links they offer me as evidence clearly show that there is no “bad reputation” in the specific IP address that I am currently using, only a policy listing showing one of Shaw’s address ranges.

2) I got absolutely no warning from Shaw, and no notice after the fact.

3) Shaw’s spam filtering is for the birds.  Today I got two messages flagged as spam, for no clear reason I could see.  They were from a publisher, asking how to send me a book for review.  The only possible reason I could see was that the publisher copied three of my email addresses on the same message.  A lot of people do that, but it usually doesn’t trip the spam filter.  Today it did.  (Someone else with Shaw “service” tried to send out an announcement to a group.  Since he didn’t have a mailing list server, he just sent out a bunch of messages.  Apparently that got *his* account flagged as spamming.)  I also got the usually round of messages from security mailing lists tagged as spam: Shaw sure has something against security.  And at least one 419 scam got through unflagged today, despite being like just about every other 419 in the world.  (Oddly, during this period I’ve noted a slight uptick in 419s and phishing in general.)

4) Through this episode I had contact with Shaw via email, phone, “live chat,” and Twitter.  I follow ShawInfo and Shawhelp on Twitter.  On Twitter, I was told to send them a direct message (DM).  I had, in fact, tried to do that, but Shaw doesn’t accept direct messages by default.  (Since I pointed that out to them, they now, apparently accept them from me.)  They sent me public messages on Twitter, and I replied in kind.  Through the Twitter account they also informed me that error 554 is “poor reputation” and is caused by sending too many emails.  They didn’t say how many is too many.  (Testing by someone else indicated something on the order of 50-100 per hour, and I’ve never done anything near that scale.)

5) The “live chat” function installs some software on your (the client) machine.  At least two of the pieces of software failed the digital signature verification …

6) The “information” I got from Shaw was limited.  The first (phone) support call directed me to http://www.senderbase.org/senderbase_queries/detailip?search_string=70.79.166.169  If you read the page, the information is almost entirely about the “network” with only a few (and not informative) pieces about the IP address itself.  (I did, separately, confirm that this was my IP address.)  The bulk of the page is a report on addresses that aren’t even in the same range as I am.  About halfway down the right hand side of the page is “DNS-based blocklists.”  If you click the “[Show/Hide all]” link you’ll notice that four out of five think I’m OK.  If you click on the remaining one, you go to http://www.spamhaus.org/query/bl?ip=70.79.166.169  At the moment, it shows that I’m completely OK.  At the time I was dealing with Shaw, it showed that it’s not in the SpamHaus Block List (SBL) or the XBL.  It was in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

7) The second (live chat) support call sent me to http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+  Again, this page showed a single negative entry, and a whole page of positive reports.  The single negative entry, if pursued, went to the same Spamhaus report as detailed above.

8) At the time, both initial pages, if followed through in terms of details, led to http://www.spamhaus.org/pbl/query/PBL164253 giving, as the reason, that “This IP range has been identified by Spamhaus as not meeting our policy for IPs permitted to deliver unauthenticated ‘direct-to-mx’ email to PBL users.”  Again, Shaw’s problem, not mine.  However, that page has a link to allow you to try and have an address removed.  However, it says that the “Removal Procedure” is only to be used “If you are not using normal email software but instead are running a mail server and you are the owner of a Static IP address in the range 70.79.164.0/22 and you have a legitimate reason for operating a mail server on this IP, you can automatically remove (suppress) your static IP address from the PBL database.”  Nevertheless, I did explore the link on that page, which led to http://www.spamhaus.org/pbl/removal/  Again, there you are told “You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server, and (B) if you have a specific technical reason for needing to run a ‘direct-to-MX’ email service, such as a mail server appliance, off the Static IP address. In all other cases you should NOT remove an IP address from the PBL.”  This did not refer to my situation.  Unfortunately, THESE TWO PAGES ARE INCORRECT.  If you do proceed beyond that page, you get to http://www.spamhaus.org/pbl/removal/form  This page does allow you to submit a removal request for a dynamic IP address, and, in fact, defaults to dynamic in the form.  It was only on the last part of the second call, when the Shaw tech gave me this specific address, that I found this out.  For this I really have to blame Spamhaus.

9) In trying to determine if, by some weird mischance, my computer had become infected, I used two AV scanners, one spyware scanner, and two rootkit scanners.  (All results negative, although the Sophos rootkit scanner could have been a bit clearer about what it had “found.”)  Of course, I’ve been in the field for over two decades.  How would the average user (or even a security professional in a non-malware field) even know that there are different types of scanners?  (Let alone the non-signature based tools.)

Share

Shaw Cable security (lack-of) support (2)

Well, multiple scanners say I have no malware, no spyware, and no rootkits.

http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+ says I’m clean except for Spamhaus.

Spamhaus shows that http://www.spamhaus.org/query/bl?ip=70.79.166.169 I’m clean and it’s Shaw that’s dirty.

Shaw’s support is as inane as ever:

GoToAssist (11:43:33):
Your representative has arrived.

Stephen – 6685 (11:43:37):
Thank you for choosing Shaw Internet Chat Support, my name is Steve.  I will be happy to help you today.Before continuing, would you please confirm your home telephone number and address so that I can bring up your account information?

[If you don't mind, I've elided this, but it's the only change I've made - rms]

Stephen – 6685 (11:44:57):
Thank you, one moment please
Stephen – 6685 (11:48:07):
from what we see on the notes, it looks like your email is being blocked to due a poor reputation which means its being blocked by spam protection companies,  im just looking into this a little further for you.

Rob Slade (11:49:16):
Do you have any idea of what that means?  When I talked to “Rowell” yesteerday, he did not know anything about anti-spam technology, and just kept handing me bafflegab.  If you do not have any knowledge in thsi area, please hand me to someone who does.
Rob Slade (11:49:46):
I should let you know that I *do* know what I’m talking about: look up “Robert Slade” on Wikipedia.

Stephen – 6685 (11:49:48):
your being blocked by spamhaus
Stephen – 6685 (11:50:02):

http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+

Rob Slade (11:50:18):
I’ve written two books on viruses and malware, the first book on software forensics, and a dictionary of information security.
Rob Slade (11:50:38):
I do know what spam is, and I am well aware of antipsam technology.
Rob Slade (11:51:08):
Per looking at senderbase yesterday, my specific IP address has nothing on it.  Just Shaw’s domain range.

Stephen – 6685 (11:52:03):
you would need to go here   http://www.spamhaus.org/lookup.lasso   type in your ip address to lookup, then  click the document it shows under the listed in red, and follow the steps to get it removed from spamhaus

Rob Slade (11:52:29):

http://www.spamhaus.org/query/bl?ip=70.79.166.169

Rob Slade (11:53:04):
See that it is only listed in the PBL, and if you look up the detail on that you will see that it is only the Shaw /22 range, and not my address.
Rob Slade (11:53:49):
Going back to your original list, you will see that it is *only* listed on Spamhaus (and therefore only on the PBL), and that *all* the other sites give me a clean bill of health.
Rob Slade (11:54:19):
In addition, why did I get absolutely no warning or notice from Shaw, just had my ability to send cut off without warning?

Stephen – 6685 (11:54:27):
its not blocked by us
Stephen – 6685 (11:54:31):
thats why we couldnt give warning
Stephen – 6685 (11:54:37):
its blocked by spamhaus

Rob Slade (11:54:49):
It is your SMTP server that refuses the connectionh.
Rob Slade (11:55:00):
You can’t blame Spamhaus.

Stephen – 6685 (11:55:14):
http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+   please review this,  it will show you based on a search of your ip address, its listed by spamhaus-zen….

Rob Slade (11:55:52):
That is the same list as before.

Stephen – 6685 (11:56:19):
yes it is

Rob Slade (11:56:36):
As I told you, it gives me a clean bill of health, except for Spamhaus, and Spamhaus only lists the Shaw /22 range in the PBL, not my IP address specifically.

Stephen – 6685 (11:56:37):
if you look at the top.. spamhaus-zen  to the right of that it shows as listed  which means its blocked by them
Stephen – 6685 (11:57:00):
its still being listed by them, otherwise it would come up saying OK  next to spamhaus
Stephen – 6685 (11:57:16):
if you login to webmail  and try sending an email out from there, it will work because its not associated with your computer
Stephen – 6685 (11:57:30):
its not working on your computer because your ip  address is blocked by spamhaus

Rob Slade (11:57:44):
Yes, and if you look at the detail, you will see that I am *not* lsited in the SBL, *not* listed in the CBL, and *only* listed in the PBL, and if you look at the detail for *that* you will see that it is *Shaw* that violates, not me.
Rob Slade (11:58:37):
Here. chew on these: http://is.gd/VbjOIh http://is.gd/ogefIX

Stephen – 6685 (11:59:31):
im not sure what i am suppose to be seeing in those links..   Error establishing a database connection
Stephen – 6685 (12:00:07):
http://www.spamhaus.org/pbl/query/PBL164253  from there, you will need to follow the steps from clicking on remove an ip from pbl

Rob Slade (12:01:20):
In the meantime, I will be writing up more blog posts on how Shaw has inconsitent spam filtering, does not say what kind of spam filtering it does do, has a weird relationship with the blacklisting outfits.
Rob Slade (12:02:09):
Obviously you have not read the page you sent me.  This is the procedure only if you are running an email server (MTA) yourself.  I don’t.  You guys do.

Stephen – 6685 (12:05:15):
yes, from the report, its showing that its being blocked due to not using smpt authentication, that gets addressed from our side, where we communicate with spamhaus to get that resolved, however also by having you follow the link from the remove my ip address can usaully help get it resolved quicker.
Stephen – 6685 (12:06:12):
it is blocked by spamhaus, not us, which is something that will get looked into, if it was just being blocked by us, we could easily resolve it for you, however because its being blocked by a 3rd party, it will take some time, in the meantime you can use webmail to send and receive emails

Rob Slade (12:06:19):
How so?  I don’t run an SMTP server, so I can’t give them full info in filling out that form.
Rob Slade (12:07:06):
Besides, it’s not a static address.
Rob Slade (12:07:45):
Obviously you do not know what you are talkign about.  Are you going to put me through to someone who does?

Stephen – 6685 (12:08:08):
yes i do know what i am talking about Rob

Rob Slade (12:08:45):
Then how come you are asking em to fill out a form when the instructions specifically state not to do it unless this is a static IP address and I am running my own mail server?
Rob Slade (12:09:36):
http://www.spamhaus.org/pbl/removal/ “You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server”

Stephen – 6685 (12:09:37):
i am just looking to see what more we can do on this right now, i will be a couple minutes.

Share

Shaw Cable security (lack-of) support

As noted, Shaw is not very helpful with spam.  I’ve been getting spam from Marlin Travel, and from a band of people selling recuriting seminars, for a number of years.  I have been reporting this spam (to Shaw, and their supposedly automated spam filters) on at least a weekly basis for years.  Occasionally they deign to mark one of the messages as spam, but not on anything like a consistent basis.

Spam filtering is not transparent.  You can turn it on, or off.  You can have the spam go to the bit bucket, or get flagged.  There are no other options, and you have no information on how it works (or doesn’t).  (Heck, Vancouver Community Net [formerly Free-Net] does better than that.)

On my non-support call with Shaw, the agent did correctly identify the IP address I am (currently) using.  I have no idea when last it was switched.  Looking it up on senderbase is not supremely informative: there doesn’t seem to be any information on the address itself, other than the fact that it’s not in the SpamHaus Block List (SBL) or the XBL.  It is in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

Meantime I have confirmed that, as I already knew, there is nothing malware or spam related on my machine.  Nothing that MSE detects.  Nothing that Vipre detects.  Nothing that Spybot detects.  At the moment I’m running the Sophos rootkit detector, and F-Secure’s Blacklight.  They haven’t found anything either.  I am, of course, morally certain that Shaw was lying to me about the possibility, but, unlike them, I’m not arrogant enough not to check.  I was right: they are idiots.  And, with their non-support, have cost me a lot of valuable time checking a clean machine.  (Plus not providing the Internet service I’m paying for.)

Share

“Extrusion Detection”, Richard Bejtlich

BKEXTDET.RVW   20101023

“Extrusion Detection”, Richard Bejtlich, 2006, 0-321-34996-2,
U$49.99/C$69.99
%A   Richard Bejtlich www.taosecurity.com taosecurity.blogspot.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-34996-2
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/0321349962/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321349962/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321349962/robsladesin03-20
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   385 p.
%T   “Extrusion Detection:Security Monitoring for Internal Intrusions”

According to the preface, this book explains the use of extrusion detection (related to egress scanning), to detect intruders who are using client-side attacks to enter or work within your network.   The audience is intended to be architects, engineers, analysts, operators and managers with an intermediate to advanced knowledge of network security.  Background for readers should include knowledge of scripting, network attack tools and controls, basic system administration, TCP/IP, as well as management and policy.  (It should also be understood that those who will get the most out of the text should know not only the concepts of TCP/IP, but advanced level details of packet and log structures.)  Bejtlich notes that he is not explicitly addressing malware or phishing, and provides references for those areas.  (It appears that the work is not directed at information which might detect insider attacks.)

Part one is about detecting and controlling intrusions.  Chapter one reviews network security monitoring, with a basic introduction to security (brief but clear), and then gives an overview of monitoring and listing of some tools.  Defensible network architecture, in chapter two, provides lucid explanations of the basics, but the later sections delve deeply into packets, scripts and configurations.  Managers will understand the fundmental points being made, but pages of the material will be impenetrable unless you have serious hands-on experience with traffic analysis.  Extrusion detection itself is illustrated with intelligible concepts and examples (and a useful survey of the literature) in chapter three.   Chapter four examines both hardware and software instruments for viewing enterprise network traffic.  Useful but limited instances of layer three network access controls are reviewed in chapter five.

Part two addresses network security operations.  Chapter six delves into traffic threat assessment, and, oddly, at this point explains the details of logs, packets, and sessions clearly and in more detail.   A decent outline of the advance planning and basic concepts necessary for network incident response is detailed in chapter seven (although the material is generic and has limited relation to the rest of the content of the book).  Network forensics gets an excellent overview in chapter eight: not just technical points, but stressing the importance of documentation and transparent procedures.

Part three turns to internal intrusions.  Chapter nine is a case study of a traffic threat assessment.  It is, somewhat of necessity, dependent upon detailed examination of logs, but the material demands an advanced background in packet analysis.  The (somewhat outdated) use of IRC channels in botnet command and control is reviewed in chapter ten.

Bejtlich’s prose is clear, informative, and even has touches of humour.  The content is well-organized.  (There is a tendency to use idiosyncratic acronyms, sometimes before they’ve been expanded or defined.)  This work is demanding, particularly for those still at the intermediate level, but does examine an area of security which does not get sufficient attention.

copyright, Robert M. Slade   2010     BKEXTDET.RVW   20101023

Share

REVIEW: “Inside Cyber Warfare”, Jeffrey Carr

BKCYWRFR.RVW   20101204

“Inside Cyber Warfare”, Jeffrey Carr, 2010, 978-0-596-80215-8,
U$39.99/C$49.99
%A   Jeffrey Carr greylogic.us
%C   103 Morris Street, Suite A, Sebastopol, CA   95472
%D   2010
%G   978-0-596-80215-8 0-596-80215-3
%I   O’Reilly & Associates, Inc.
%O   U$39.99/C$49.99 800-998-9938 fax: 707-829-0104 nuts@ora.com
%O  http://www.amazon.com/exec/obidos/ASIN/0596802153/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0596802153/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0596802153/robsladesin03-20
%O   Audience n Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   212 p.
%T   “Inside Cyber Warfare: Mapping the Cyber Underworld”

The preface states that this text is an attempt to cover the very broad topic of cyber warfare with enough depth to be interesting without being technically challenging for the reader.

Chapter one provides examples of cyber attacks (mostly DDoS [Distributed Denial of Service]), and speculations about future offensives.  More detailed stories are given in chapter two, although the reason for the title of “Rise of the Non-State Hacker” isn’t really clear.  The legal status of cyber warfare, in chapter three, deals primarily with disagreements about military treaties.  A guest chapter (four) gives a solid argument for the use of “active defence” (striking back at an attacker) in cyber attacks perceived to be acts of war, based on international law in regard to warfare.  The author of the book is the founder of Project Grey Goose, and chapter five talks briefly about some of the events PGG investigated, using them to illustrate aspects of the intelligence component of cyber warfare (and noting some policy weaknesses, such as the difficulties of obtaining the services of US citizens of foreign birth).  The social Web is examined in chapter six, noting relative usage in Russia, China, and the middle east, along with use and misuse by military personnel.  (The Croll social engineering attack, and Russian scripted attack tools, are also detailed.)  Ownership links, and domain registrations, are examined in chapter seven, although in a restricted scope.  Some structures of systems supporting organized crime online are noted in chapter eight.  Chapter nine provides a limited look at the sources of information used to determine who might be behind an attack.  A grab bag of aspects of malware and social networks is compiled to form chapter ten.  Chapter eleven lists position papers on the use of cyber warfare from various military services.  Chapter twelve is another guest article, looking at options for early warning systems to detect a cyber attack.  A host of guest opinions on cyber warfare are presented in chapter thirteen.

Carr is obviously, and probably legitimately, concerned that he not disclose information of a sensitive nature that is detrimental to the operations of the people with whom he works.  (Somewhat ironically, I reviewed this work while the Wikileaks furor over diplomatic cables was being discussed.)  However, he appears to have gone too far.  The result is uninteresting for anyone who has any background in cybercrime or related areas.  Those who have little to no exposure to security discussions on this scale may find it surprising, but professionals will have little to learn, here.

copyright, Robert M. Slade   2010     BKCYWRFR.RVW   20101204

Share

New computers and old network problems

Well, I don’t know if this is a continuation in the “new computers” series, or just rehashing an old problem.

I’ve noted before the problem of the complexity of trying to establish an ad-hoc network under Windows.  And, I’m trying various things with the new Mac.  So, in a situation, right now, where I have one network cable, and two computers downstairs, I decided to see what an ad hoc network was like with a Mac.

I remembered to do the bridging thing on Windows, and I’ve set up an ad hoc network with a pre-shared key.  (At least, I think I have.  That seemed to be the way it worked, and the Mac connected with a password, but, on the Windows machine, when I go back and look at it, it says it’s open.)  The Mac wouldn’t show the network when I looked at the list, but, when I gave it the name and password it seemed to connect just fine.

I got a Web site correctly on the Mac.  Then I went to connect to the Windows machines as servers, and that worked out fine.  Then I went to do some work on the Web, and … nothing.  The Mac wasn’t able to get onto the Internet.  I was still connected to the Windows servers, but couldn’t get a Web page.

And, then, suddenly, I could, again.  And then I couldn’t.  (At the moment, I can’t.)  (Sorry, started working again just before I finished this entry.)
I’ll have to give it a shot with the Mac connected to the cable, and see if I can set up an ad hoc wireless connection that the Windows netbook can use, but, at the moment, Mac networking is not working any better than Windows in the ad hoc environment.

Roll on PopulistNet.

Share

Internet shut off switch?

Reports are saying cell phones and Internet connections are off in egypt at the moment. Can a country really shut off its Internet connection?

China, who has placed restrictions on its Internet infrastructure from day 1 (meaning, the whole infrastructure for connecting to the Internet was built with government control in mind) and that develops a lot of its own networking equipment, is unable to really block users. When I’m in China, twitter and facebook are blocked in the hotel and in the office, but not on the blackberry. Most anonymizers work, and some twitter-over-instant messenger bots work as well. Most of the time, I can find the new list of working anonymizers on google, while I’m there – so there’s no special preparation involved. On my last visit I was introduced to a free VPN service that enables unrestricted access to facebook, twitter and other blocked sites, that seems to be quite popular in the country.

Egypt is not as big and certainly not as advanced as China, but is fairly big. As anyone who worked for a large company knows – it’s difficult if not impossible to track all incoming and outgoing connections. We know the DNS servers are refusing to resolve .eg domains – but what if we go into the inner-works. Are some of the IP’s inside Egypt reachable?

One glaring example is the Egyptian stock exchange. Its IP rotates, but at least some connections point to  217.139.183.2, which belongs to the ISP “the Noor group”, in Cairo. Other times it points to 41.222.175.2 that belongs to “Misr Information Services and Trading” in down-town Cairo. Both are clearly reachable and pingable; is every router on the way configured to route communication only to those IPs? Are there other routers, IP’s or servers that are still open for communication? I would imagine that some emergency lines run on IP-based infrastructure that must be kept on; some devices – military ones perhaps – might rely on IP infrastructure. Dial-ups might still exist. Speaking of which: can one dial from Egypt into a modem in Germany?
Also, one has to wonder about internal communication. Blocking the country’s gateways is one thing; but blocking all internal communication is extremely hard to do. If internal communication is available, is there a way to piggyback into those few holes in the dam to get external communication? Taking the egyptse.com example: if the perimeter routers only allow communication to/from the Noor network, can I route my connection through them?

We all know the Internet was designed to be resilient; and forty years after its initial deployment, it’s proving to be very hard to kill, even by those who believe they have their hand on the cut-off switch.

Share