So after having received yet another telemarketing call about switching my local service away from Bell, I called Bell and asked if there were any checks and balances in place. You know, to prevent fraud. The kind of fraud the US has been dealing with for 25 years.

Short answer: no. They simply trust the other guy, and let them take your service away from Bell. There’s a CRTC mandate that the new company formally obtain consent, but a) that can be in several different easy-to-forge formats, and b) apparently Bell doesn’t bother verifying consent except in disputes.

I’m not sure who the imbeciles are here (I suspect the CRTC, but it could be Bell Canada), but there’s one somewhere.

You’d think we’d at least attempt to learn from the mistakes of our neighbours to the south with all of these attempts at deregulation, but no. That would require that intelligence trump greed.

I’m appalled…

posted at 2:32 pm on Tuesday, July 05, 2005 in Rants, Security | Comments Off on Slamming comes to Canada

Today I’m feeling like throwing in the towel on this web server business: there’s just too much crap to deal with.

A friend’s server was broken into and defaced last week by a script kiddy. I’ve been double-checking my box over the last few days, and I’m astonished at the amount of crap flowing in from the Internet. As a security professional I knew it was bad, but I was fooling myself; I didn’t know it was this bad!!!

I monitor the site regularly, mainly to ensure that we’re not abusing bandwidth that is generously donated, but also to make sure everything is working, and to watch for obviously suspicious activity. In the last week a major portion of the traffic to this server has been:

referrer spam (which doesn’t do anything for the spammer, since I don’t display referrers anywhere; it only abuses my bandwidth). About 15% of my bandwidth for the last month has been referrer spam; they seem to breed faster than I can block them out!

people trying comment spam on weblogs with no comments (and no comment script!). This includes attempts to invoke old security holes in Movable Type.

people probing for security defects in software that I don’t even have installed.

people probing for security defects in software that I do have installed (fortunately that was password protected, so they didn’t get in :).

probes for network sockets (both for software with vulnerabilities, and for software installed by hackers). This box is heavily firewalled (in both directions; blocking outbound traffic has saved my bacon more than once!), but I still see the logs.

password guessing attempts (mainly via SSH, which has been locked down to a small number of IP addresses for months now, since the last major SSH vulnerability).

The promise of Open Source software was that more eyes staring at code would lead to fewer defects. I’m seeing the opposite; it seems that the rate of vulnerability annoucements, and resulting patches, is increasing. Just last week I just upgraded three packages here as a direct result of security announcements (and, as mentioned above, caught someone probing for one of them…)

The Internet has become the cesspool predicted in several recent science fiction novels (notably Peter Watt’s Behemoth, which specifically mentions automated virus / hacking activity). After three days of looking two closely at my logs I feel like pulling the plug. If it were just me using the server, I probably would…

Several times we’ve woken up to a dead cfrq.net server, and (ignoring one disk crash) it’s always been runaway Movable Type comment scripts causing the system to thrash, until some important process gets killed because of the resulting out-of-memory condition. It invariably happens on a Saturday, which means we all get to wait until Monday morning for the server to get manually rebooted.

Comments have been disabled
Due to a huge influx of comment spam, I have disabled comments on tnir. This affects all blogs hosted on tnir, including Luisa’s and David’s. If you try to post a ccomment, it will let you type it in, but when you click “post” it will give you some…

Amateur radio operators keep track of all of the countries they’ve had contact with.

I’m going to start keeping a list of all the countries I’ve received Nigerian fraud (aka 419 spam) messages from.

Nigeria

Liberia

Senegal

Mauritius

UK (London)

Hong Kong (China) (20041110)

Sierra Leone (20041110)

Cote d’Ivoire (20041119)

South Africa (20041120)

Burkina Faso (20041124)

Togo (20041124)

Benin Republic (20041124)

Korea (20041125)

Brazil (20041231) (wow, that was a long gap!)

South Africa (20050113)

Russia (!!!) (20050114)

Dubai (20050117)

Senegal (20070717) (after another long gap…)

Iran (!!!) (20080212)

I’m slowly collecting most of that part of Africa…

Update: it appears that these fraudsters are the only ones left trolling web pages for email addresses. My active campaign against bandwidth abusing spiders appears to be cutting down on the spam at the same time…

posted at 12:52 pm on Sunday, November 07, 2004 in Personal, Security | Comments Off on Nigerian Fraud Countries

I’ve visited lots of old fortresses in Canada, and a few in Europe, and I remember learning about defense in depth. This is the idea that your assets should be surrounded by multiple separate layers of defenses to make it harder for the barbarian hordes (or Americans :-) to break in. Ideally the defenses should be different, so that if a simple technique of defeating one is discovered, it doesn’t help against the others.

The forts I’ve visited are typically on a hill (so that you can see the enemy coming and prepare. But they’re also sunk into the hill, with sloping outer walls, to defend the inner walls against artillery. They’re surrounded by open fields (no trees or brush). The outer wall has gun emplacements, to mow down anyone trying to cross those fields. There is a deep trench between the inner and outer walls, deep enough that attackers must climb down, slowing them down. The inner walls are full of small, narrow windows to allow the defenders to shoot at anyone trying to cross the trench. The inner walls usually have towers that project into the trench, so that people trying to climb the inner walls aren’t hidden from defenders inside the walls; those attackers can be attacked from the towers. The important buildings inside the inner walls have their own defenses. And so on.

Of course, a few carefully placed shells from a battleship and the fort is history; but that’s progress for you.

pobox.com has completely revamped their spam filtering service since I last looked; I can now monitor rejections, forward messages to myself, and add whitelist entries, all through a fairly simple interface. I’ve switched it on; so far one spam has gotten through, with no false positives…

It is very easy to setup a self-contained network, with a Domain Controller, using Active Directory. Too easy, in fact; I’m on my third attempt :-).

I’m using cloned hard disk images under Microsoft Virtual PC, which caused my latest problem; Active Directory let me register a computer in the domain with the same name as the domain controller. Needless to say, nothing worked after that. The reason this happened was because I tried to rename the image and join the domain at the same time; Windows 2000 apparently joins the domain first, then attempts to rename the computer. This surprised me :-)

Fortunately, I had a master disk image, so it was trivial to restart from a fresh install and rebuild the domain controller (which, thanks to Microsoft’s wizards, is easy). But then I had to rebuild the two child domain controllers, since they refused to “demote” themselves when the domain master was unavailable.

Sadly, all of this is time consuming, even when the host is a P4 2.8 with 1Gb of memory and oodles of disk bandwidth…

It’s simple, actually. One of my 9 desktops masquerading as servers is not under a desk; it is instead sitting on the floor in front of all of the other computers under the desk. Despite the fact that this is not in a corridor or anything else vaguely resembling anything other than a desk, this is apparently a Class B Safety Hazard (insert ominous music here :-)

I can’t find it now, but I remember reading recently about another “cross-discipline” team that discovered all sorts of interesting things, because each member of the team had a different way of looking at the data. Now a PKI research group has attached a sociologist to the team, and that is starting to produce insight:

A recent survey found that 75 percent of Dartmouth students have shared their network passwords. “They like having people who know their password,” explained Denise Anthony, a sociologist who spoke at the PKI summit conference I attended earlier this month. “They like having someone who can check their e-mail for them or log them in to places where they’re supposed to be.”

Professor Anthonyâ€™s talk was dramatically different and showed why it was a really smart move to attach a sociologist to Dartmouthâ€™s PKI research group. As security technologists, weâ€™re easily dazzled by our shiny cryptographic swords. But while weâ€™re brandishing our swords, our users â€” like Indiana Jones in that famous scene from Raiders of the Lost Ark â€” might simply pull out their guns and shoot us. Better security protocols alone canâ€™t thwart such game-changing behavior. We need to understand what motivates the behavior and figure out which carrots and sticks will influence it.

Itâ€™s a given that most people take the path of least resistance. So, for example, two-thirds of Dartmouth students never change their passwords during their four years of enrollment. And most reuse their internal passwords for external sites such as The New York Times and Amazon.com. How do they perceive the risk associated with such behavior? According to Anthony, itâ€™s a tragedy of the commons. The network is a collective resource, but people connected to the network feel that theyâ€™re consuming a private good. Their subjective view, she says, is this: â€œIâ€™m in my office. Iâ€™m using my computer. It doesnâ€™t feel like Iâ€™m part of a group. I donâ€™t recognize how my behavior affects you.â€

Ok, so it turns out that all (well, 125 of 126 :) of the spam I’m getting these days is coming through my pobox.com address. The greylisting is working fine, in other words :)

It’s been great having a portable email address, but now that I pay real money for my own domains, maybe it is time to switch over. I can do more accurate spam filtering on my personal server than they can on their shared servers Unfortunately, the massive spam volumes floating around these days are forcing us to these drastic measures. I’m beginning to believe the pessimists; e-mail is dying…

So maybe I spoke too soon; in greylist results I said that my spam volume had gone way down. Well, it has come back up again. I’ll have to write scripts to prove it, but I have a theory.

Machines owned by spammers are being used relatively infrequently, maybe to reduce the chances of getting detected and blacklisted? So the first time a spam host shows up, it gets greylisted. But if they show up again a day or a week later, they get past the greylist filter, because they’re now in the cache (but haven’t been expired yet).

Maybe a fix would be to put two cache timeouts in; the first would be for machines that have not yet successfully delivered a message i.e. by retrying the original delivery), and would be relatively short, probably less than a day. The second would be the existing long timeout for machines that have already passed the first test.

That would eliminate spam machines that only show up infrequently. I don’t know whether it is worth the effort, though.

On the plus side, greylisting is still keeping out the virus traffic…

posted at 12:18 pm on Sunday, August 08, 2004 in Security, Site News | Comments Off on greylist results revisited

Fortunately for the internet, my mom’s on dialup. But unfortunately for the internet, your mom has cable. And your mom is just as obstinately ignorant as my mom. You might as well try to convince them to change their own oil as to keep their computers maintained.

In short: trying to teach Mom about computer security is a lost cause. Which leads to the obvious conclusion; we’re not going to fix the problem until we don’t have to teach Mom about computer security…

posted at 12:00 pm on Monday, August 02, 2004 in Security | Comments Off on Mom brought Google to its knees

Bluetooth proponents have been saying for a long time that Bluetooth security isn’t that big of a deal, because the range is so short. Now a group of enthusiasts has demonstrated that it is possible to setup a 1km, line-of-sight Bluetooth connection by modifying only one side of the connection:

Some idiot script kiddy wiped out our bandwidth again today. He could have an automated tool, or he could be doing it manually. He’s trying to post comment spam to blog.org, but he’s repeatedly fetching pages over and over again (presumably to see if his comments are getting published or not).

The problem is that David’s pages are large (and getting larger all the time); an average of 200Kb each. So this spammer has single-handedly downloaded at least 70Mb of data today!

It’s one thing to try to abuse my server to get a site ranked higher in Google. It’s another thing entirely to waste my bandwidth in the process!

64.57.64.0/19, 66.154.0.0/18, and 66.154.64.0/19 just made it into the blackhole list…

I was kept busy removing the comment spam this created on the other end today as well (unfortunately, the script kiddies are starting to randomise their IP addresses and choose from long lists of URLs so IP address or URL blocking is less effective). Makes me think the only long-term solution to comment spam may be one of these type in the numbers from an image plug-ins. Though apparently determined spammers are actually doing it by hand! AARGH!

So the first time I fired up the VPN client, the rules on the firewall allowed the ISAKMP negotiation, but not the ESP data. I fixed that and tried again. This time, the firewall no longer rejects packets, but doesn’t pass them through, either. Debugging ensues. Debugging is made extra challenging by the fact that the VPN client disallows split tunnelling, thus killing the SSH session to the firewall each time it is started. Lots of running tcpdump in the background is required.

Eventually I gave up and ate supper.

I tried again after supper. The VPN comes up perfectly; the spiffy intranet portal appears. Apparently something previously cached has been un-cached. However, the connection only lasts about 5 minutes, then dies. Debugging does not follow; it’s time to play Euchre.

The next evening arrives. I fire up tcpdumps and a script to monitor /proc/net/ip_conntrack, under the assumption that connection tracking isn’t working properly (leading to the 5 minute timeout). I start the VPN client. Everything works; no session timeouts, no firewall issues. Hours of rapturous intranet browsing follows. I also play with using SSH through the VPN, out the corporate firewall, and back to the home firewall :-).

While I’m happy that everything’s working, I could live without the whole “attempt to debug problems that later mysteriously vanish” thing…

posted at 3:06 pm on Saturday, November 22, 2003 in Security | Comments Off on Debugging the VPN

A little bit of search engine spider traffic, and a bunch of hack attempts. “Fascinating”, as Spock would say…

The /sumthin fetch is apparently from a couple of trojans looking for 404 pages, because they often identify the webserver (and its weaknesses). nsiislog.dll is a known buffer overflow. The POST to port 25 is a spammer looking for an open proxy, and the CONNECT 1.3.3.7:1337 is apparently a newer version of the same scanner (looking for the 405 error on the CONNECT, presumably).

As mentioned before, I run scripts that searches my logs for common hack attempts and blacklists (or RBLs) the source. Now I’ve got some new patterns to search for.

Today Sensity posted Coventry Cathedral. I love his photpgraphy! I don’t remember how I tripped over his photoblog; if I recall correctly, it was right around the time he built a new studio in the attic. Anyway, I’ve been reading (viewing?) it ever since.

“Coventry” is one of the classic stories of information warfare. To maintain secrecy, the Germans used a complicated machine called Enigma to encrypt their radio communications. They believed (with good reason) that Enigma was unbreakable. By the later part of 1940, the Allies had cracked the code, thanks to the work of brilliant cryptologists at Bletchley Park. It is easy to argue that this project (codename Ultra) won us the war; it’s amazing what you can do when you know the enemy’s plans in advance.

Back to Coventry. On the night of November 14/15, 1940, German bombers substantially destroyed the city center of Coventry, including the 14th century cathedral. 545 civilians were killed; 4,865 were injured. The city’s infrastructure (buildings, gas mains, transit) was destroyed.

Thanks to Ultra, Churchill knew that the raid was coming, some say as early as November 12th. However, if the Allies had acted on this knowledge, the Germans would have known that Enigma was broken, and changed their codes. In order to protect the secret of Ultra, Command chose not to defend Coventry. Many lives were lost, and a city destroyed.

It’s a good story, but it’s not true. The reality is both mundane and more plausible. The Allies knew a raid was coming, but they didn’t know exactly when, and had four different potential targets. The Germans used radio beams to guide the bombers to their targets; it was only shortly before the raid that the RAF determined that the beams intersected over Coventry. Jammers were sent out to disrupt the radio signals bit their equipment was incorrectly set. RAF fighters sent to intercept the bombers downed only one plane (out of over 500). Some believe that this last point is what led to the myth; claiming that Coventry was destroyed to protect Ultra is better than admitting that the RAF completely failed to stop (or even slow down) the attack.

Still, the lesson is a valuable one. Intercepting enemy communcation (encrypted or not) is only part of the problem; the other part is hiding your interceptions from the enemy. If your opponent discovers that an important plan has been intercepted, he’s goign to change that plan (or worse, start deliberately feeding you false information).