Posts Tagged ‘network security’

« Older Entries

moxie’s proxy

Sunday, January 22nd, 2012

Moxie Marlinspike, a security researcher probably best known for his SSL proxy tool, likes google even less than I do. His googlesharing website says:

“Google thrives where privacy does not. If you’re like most internet users, Google knows more about you than you might be comfortable with. Whether you were logged in to a Google account or not, they know everything you’ve ever searched for, what search results you clicked on, what news you read, and every place you’ve ever gotten directions to. Most of the time, thanks to things like Google Analytics, they even know which websites you visited that you didn’t reach through Google. If you use Gmail, they know the content of every email you’ve ever sent or received, whether you’ve deleted it or not.

They know who your friends are, where you live, where you work, and where you spend your free time. They know about your health, your love life, and your political leanings. These days they are even branching out into collecting your realtime GPS location and your DNS lookups. In short, not only do they know a lot about what you’re doing, they also have significant insight into what you’re thinking.”

His solution to this problem was interesting. He came up with the idea of a proxy system which would intercept all google queries, strip off identifying material (such as cookies and UserAgent strings and other HTTP headers) substitute new identifiers and mix the requests up with those from other users before forwarding to google. Implementation depended upon a Firefox addon (nothing for other browsers) which identified google queries and forwarded them to the proxy. All other traffic was untouched.

image of googlesharing proxy

I stopped using google (except via scoogle) some time ago, and when Moxie’s new proxy first surfaced I thought it interesting but susceptible to the same problem I discussed in mid 2009 when writing about Hal Roberts’ experience of GIFC – all you are doing is shifting knowledge of your searches from google to a new intermediary. However, Moxie later addressed this problem with the release of version 0.20 of his addon so I thought I’d take another look at it. Unfortunately the addon won’t work with FF 9 (which I am using). Moxie’s proxy is not the only one out there however. Because he released the code under an open source licence, others have picked it up. I found one at gs.netsend.nl. They also provide an updated FF addon which will work with versions up to 15 (i.e. probably around next wednesday given the speed with which Mozilla is currently shipping new FF releases).

Once the addon is installed, it gives you two proxy options in the preferences settings – one is the original proxy.googlesharing.net, the other is gs.netsend.nl itself. In testing I found that the original googlesharing proxy seemed to be off-line, but when using the netsend.nl proxy I was reassured to see the message “Search results anonymized by GoogleSharing” added to the google homepage. I was even more reassured that my sniffer showed a connection to vps1101.pcextreme.nl on 31.21.98.201 and not to any known google network.

So, will I use it? Maybe. But the proxy mechanism seems to be unreliable. In many tests, the proxy connection seemed to be bypassed and the connection was obviously made direct to google (as evidenced by my sniffer). I think this failure is doubly unfortunate because it does not fail safe (i.e. the connection does not simply fail with an error message, it passes you direct through to google). This could lead the unwary to think that they are protected when in fact they are not.

I prefer not to use google at all. And in those cases where I do want to compare results with another search engine I prefer to do so via tor. But it is one more option in my toolkit if used carefully. And if using it pisses off google, then it is worth it occasionally.

Tags: , , , , , , , ,
Posted in free software, net tools, network (in)security, privacy, tips, tricks and howtos, trivial musing | 4 Comments »

t-mobile resets its policy?

Thursday, January 12th, 2012

As I have mentioned in other posts here, I run my own mail server on one of my VMs. I do this for a variety of reasons, but the main one is that I like to control my own network destiny. Back in October last year I noticed an interesting change in my mail experience with my HTC mobile (actually my wife first noticed it and blamed me, assuming that I had “twiddled with something” as she put it). Heaven forfend.

My mail setup is postfix/dovecot with SASL authentication and TLS protecting the mail authentication exchange. My X509 certs are self generated (and so not signed by any CA). I pick up mail over IMAPS (when mobile) and POP3S (at home – for perverse reasons of history I like to actually download mail to my main desktop over POP3 and archive it to two separate NAS backups). I send via the standard SMTP port 25 but require authentication and protect the exchange with TLS.

My mail had been working fine ever since I set it up some years ago, but as I said, back in October my wife complained that she could no longer send email from her HTC mobile (we both use t-mobile as the network provider). She was at work at the time so away from my home network. Both our phones are setup to use use wifi for connectivity where it is available (as it is at home of course). When my wife complained I checked my phone and it could send and receive without problem. But when I switched wifi off, thus forcing the data connection though the mobile network, I got the same problem as my wife reported. On checking my mail server logs I read this:

postfix/smtpd[28089]: connect from unknown[149.254.186.120]
postfix/smtpd[28089]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer
postfix/smtpd[28089]: SSL_accept error from unknown[149.254.186.120]:-1
postfix/smtpd[28089]: lost connection after STARTTLS from unknown[149.254.186.120]
postfix/smtpd[28089]: disconnect from unknown[149.254.186.120]

(the ip address is one of t-mobile’s servers on their “TMUK-WBR-N2″ network)

Everything I could find about that sort of message suggested that the client was tearing down the connection because there was something wrong with the TLS handshake and it was not trusted. Checking earlier logs, I found that t-mobile’s address had apparently changed (to the address above) recently. So I assumed that some recent network change following the Orange/T-mobile merger had been badly managed and all would be well again as soon as the problem was spotted. Wrong. It persisted. So I had to investigate further. As part of my investigation of the error, I tried moving mail from port 25 to 587 (submission) because that sometimes gets around the problem of ISPs blocking, or otherwise interfering, with outbound connections from their networks to port 25, No deal. In fact it looked as if t-mobile were blocking all connections to port 587 (I assumed a whitelisting policy block, or again, a cockup).

So, the scenario was: mail works when connecting over wifi and using my domestic ISP’s network, but doesn’t when using t-mobile’s 3G network. Symptoms point to a lack of trust in the TLS handshake. Tentative conclusion? There is an SSL/TLS proxy somewhere in the mobile operator’s chain. That proxy sucessfully negotiates with our phones, but when it gets my self certified X509 cert from the server. it can’t authenticate it and decides that the connection is untrusted so tears it down. My server sees this as the client (my phone) tearing down the connection. [As it turns out, this conclusion was completely wrong, but hey].

I said in an email at the time to a friend whose advice I was seeking, “I suspect cockup rather than outright conspiracy, but if my telco is dumb enough to stick a MITM ssl proxy in my mail chain, they really ought to have thought about handling self signed certs a little better. Otherwise it sort of gives the game away.”

In response, he very sensibly suggested that I should run a sniffer on the server and check what was going on. At that time, I was busy doing something else so I didn’t. And because the problem was intermittent (and my wife stopped complaining) I never got around to properly investigating further. (I should explain that I rarely send mail from my mobile nowadays. I just read mail there and wait until I get home to a decent keyboard and can reply to whatever needs handling from there. My wife just gave up bothering to try).

I should have persisted because of course I wasn’t the only one to experience this problem.

Back in November, a member of the t-mobile discussion forum called “dpg” posted a message complaining that he could not connect to port 587 over t-mobile’s 3G network. In response, a member of the t-mobile forum team suggested that dpg might reconfigure his email so that it was relayed via t-mobile’s own SMTP server. Not unreasonably, dpg didn’t think this was an acceptable response – not least because he would then have to send his email in clear. He then posted again saying that “the TLS handshake fails when the mail client receives a TCP packet with the reset (RST) flag set.” (This is a bad thing (TM). Further, he posted again saying that he had set up his own mail server and repeated earlier tests so that he could see both ends of the connection. At the client side he posted mail from his laptop tethered to his phone which was connected to the t-mobile 3G network. By running sniffers at both ends of the connection he was able to prove to his own satisfaction that something in the t-mobile network was sending a RST and tearing down any connection when a STARTTLS was seen. Again, in a later post in response to one from another poster who apparently manages several mail servers and had been looking at the same issue for a client, dpg says:

“I must say I’m not too pleased to discover that T-Mobile may be snooping all traffic to check for SMTP messages. I have demonstrated that they may be doing this by running a SMTP server on a non-standard port and finding that they still sent TCP reset packets during TLS negotiation – so they must be examining all packets and not just those destined for TCP ports 25 and 587.

I’m also not that keen on T-Mobile spoofing/forging TCP resets. This is the sort of tactic resorted to by the Great Firewall of China (http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-great-firewall-of-china/) and also by Comcast back in 2007 (https://www.eff.org/wp/packet-forgery-isps-report-comcast-affair) until the US FCC told them to stop (http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-08-183A1.pdf).”

Then 9 days ago, dpg posted this message:

“I finally got to the bottom of this. I was contacted by T-Mobile technical support today and was told that they are now actively looking for and blocking any TLS-secured SMTP sessions. So, it is a deliberate policy after all, despite what the support staff have been saying on here, twitter and on 150. They told me it is something they have been rolling out over the last three months – which explains why it was intermittent and dependent on IP address and APN to begin with.

So, the only options for sending email over T-Mobile’s network are:
- unencrypted but authenticated SMTP (usually on port 25)
- SSL-encrypted SMTP (usually on port 465)
- unauthenticated and unencrypted email to smtp.t-email.co.uk

TLS-encrypted SMTP sessions are always blocked whether or not they are on the default port of 587.”

(As an aside, there is, of course, another alternative. You can ditch t-mobile as your provider and pick one which doesn’t use DPI to screw your connections. You pays your money….)

Following this, a new poster called “mickeyc” said this:

“I’ve been experiencing this exact same problem. I run my own mail server which has SSL on port 465 and also uses TLS on port 587. I used wireshark to confirm that the RST packets are being spoofed. This is the exact same technology used by “The Great Firewall of China”. I have two t-mobile sims. One is about a year old and doesn’t experience this problem (yet), one is a few weeks old and does.”

He went to say that he had also experienced problems with his OpenVPN connections and would be blogging about the problem (damned bloggers get everywhere) and sure enough, Mike Cardwell did so at grepular.com. That blog post is worth reading because it has an interesting set of comments and responses from Mike appended.

Mike’s post seems to have been picked up by a few others (El Reg has one, and as Mike himself has pointed out, boingboing.net has a particularly OTT post which seems to say that he is accusing t-mobile of something he clearly isn’t.

Finally, two days ago, dpg posted this:

“I’m pleased to report that T-Mobile is no longer blocking TLS-secured email on port 587. As a follow-up to an email exchange over the Christmas period I was contacted today to say that, contrary to what I had been told previously, it was never a deliberate policy to block TLS-secured outgoing email. There was a problem with some equipment after all, which was resolved yesterday.”

I tried again myself today. Initially, I got the same old symptoms (“lost connection after STARTTLS”) then I rebooted my ‘phone and lo and behold I could send email.

Like Mike, I tend to the cockup over conspiracy theory, it’s more likely for one thing. IANAL, but it seems to me that it would be in breach of RIPA part I, Unlawful Interception, for the telco to intercept my SMTP traffic in the way it seems to have been doing. That is not likely to be a deliberate act by a major UK mobile network provider.

But I’ll still keep an eye on things.

Tags: , , , , ,
Posted in network (in)security, networks and networking, privacy, security, trivial musing | No Comments »

tunnelling X over ssh

Monday, December 19th, 2011

OK, yes, I know there are probably already a gazillion web pages on the ‘net explaining exactly how to do this, but I got caught out by a silly gotcha when I tried to do this a couple of days ago, so I thought I’d post a note.

Firstly, X is not exactly a secure protocol, nor is it easy to filter at NAT firewalls, so the ability to tunnel it over ssh is hugely welcome. In fact, ssh can be used to tunnel practically any other protocol you care to name, so it should be your first port of call should you wish to connect to a remote system using an insecure protocol. (I use it to wrap rsync for example).

I don’t run X on my VMs (there is no need, they don’t run desktop software) and I had not previously seen the need to run X based graphical programs on those servers. However, a couple of days ago I thought it would be really useful to run etherape on one particular remote server so that I could watch the traffic patterns. Normally I use iptraf (which is ncurses based) when I want to monitor network traffic in real time, but etherape is pretty cool and gives a nice graphical view of your network connections. But it runs on an X based gui.

So. I changed the remote server’s sshd_config to enable X forwarding (“X11Forwarding no” becomes “X11Forwarding yes”) and restarted sshd. On my desktop I similarly changed my local ssh_config file to allow X forwarding (“ForwardX11 no” becomes “ForwardX11 yes”) to obviate the need to use the -X switch on the command line. I then installed etherape on the remote server and fired it up only to get the message “Error: no display specified”. Sure enough “echo $DISPLAY” showed nothing. But I had thought (and everything I had read confirmed) that ssh should take care of setting the appropriate display when X11 forwarding was set.

So I then tried setting a display manually (export DISPLAY=localhost:10.0 on the remote server) and then got the response “Error: cannot open display: localhost:10.0″. So, still no deal. I spent some time scratching my head (and reading man pages) and sent off a query to my local Linux User group in parallel asking for advice. They were gentle with me.

The first, and rapid, response, said:

On the server:

sudo apt-get install xauth

Then disconnect and reconnect the client.

Jobs a good un.

Thank you Brett.

So the moral is, make sure that you have X authorisation working properly on the remote system (check for the existence of $HOME/.Xauthority) if you experience the same symptoms I did.

Tags: , , , , ,
Posted in coding and admin, free software, linux and unix, network (in)security, networks and networking, security, tips, tricks and howtos, trivial musing | No Comments »

who are you going to call

Monday, July 18th, 2011

Like most email users I get my fair share of spam and other internet crud. Mostly I ignore it, but I received an intriguing email a couple of days ago which purported to be a mailer daemon “Delivery Status Notification” informing me of a failed delivery to some address I had not even heard of. Mostly this sort of junk results from backscatter from mailers responding to spammers spoofing your email address in the outgoing mail. I get a lot of this to the “info@baldric.net” address as I’ve mentioned below.

However, this particular email interested me because the message-id in the headers said it came from a machine calling itself mx1.rlogin.net. Now I own and control that domain and I know that I have no such machine. So I concluded that the machine at the address in question (which looks to be at the end of a commercial cable line) was either deliberately being used incorrectly by its owner, or (much more likely) had been compromised and was being used illegally to send spam mail designed to look like it came from my domain. Either way, I’m not overly happy about that so I decided to contact the ISP and let them know that they might have a customer with a problem.

The normal way to do this is to send email to the “abuse@domain.name” address which is usually listed in the whois record for the network owner. There is even an RFC which codifies this practice. However, on searching a variety of whois records I couldn’t find any obvious address to use. Worse, speculative email to “abuse@the-likeliest-relevant-domain” was simply returned as undeliverable. What to do?

Well as it happens I found a very helpful utility called abuseEmail which automates searches of whois records for likely addresses. Better yet, some helpful people at cyberabuse.org give a web based front end to the abusEmail php script so that you don’t have to run your own.

Tags: , , , , ,
Posted in mail and mail lists, network (in)security, trivial musing | No Comments »

damn, I think I got hit by a 419er

Sunday, January 23rd, 2011

I am normally pretty careful about my on-line security and privacy. I take a lot of care to ensure that my home network is nailed down tightly and all the clients and servers on it are also nailed down as well as I know how. I don’t use software which is susceptible to the majority of the malware out there; my browser is nailed down as tightly as I can get it whilst still allowing it to be useful (roll on HTML5, I hate flash, but it is so damned useful); I do some, very specific, browsing (such as on-line banking) from within a VM and do not use that browser or machine for anything except that specific activity; I routinely bin cookies and flash LSOs (in fact I find it better to disallow all LSOs in the first place); this blog does not include any email addresses harvestable by ‘bots; my email client is a niche (i.e. minority) product and is configured only to allow text (no HTML or embedded images or webbugs); I use tor when I want to be as anonymous as possible; my local DNS server blocks access to a whole range of addresses I don’t like; and I never respond to unsolicited email.

But I got phished. Damn.

Here’s what happened.

I advertised an unwanted mobile phone on gumtree. I chose gumtree in preference to ebay because a) adverts are free, and b) gumtree allows you to target the advertising to a specific location. I like this idea because it means you can say “I’ve got a doohickey for sale in South London. Come and see it and pay cash if you want it”. My ad gave details of the item for sale and, as is recommended, I chose to have responses emailed to me. Here I made mistake number one – I used my normal email address rather than a disposable one. To be fair, gumtree don’t expose any of your private details, they just forward any responses to the address you give. Here’s where I made mistake number two, I responded to queries about the ad from the address given to gumtree. Damn. Idiot. So stupid.

So why do I think the responses weren’t kosher? Well there were a number of giveaways. Firstly the requests were for information already in the ad (“how much do you want?”); secondly, there were a suspiciously high number of “spilling misteaks” in the emails; thirdly, the correspondent wanted me to mail the ‘phone to a location outside the UK (“Thanks for your quick respond actually i will love to buy the Ad for my Daughter who is currently studying at British international college (BIC) in West Africa so am willing to pay you additional £48.76 for the shipping via Express Air Mail.” (sic)); fourthly, the respondents all seemed desperately keen for me to accept paypal as the preferred payment option. I’m normally quicker on the uptake than this, but sadly it took me four or five emails to realise that there was a pattern here and that the people after the phone seemed to be following a script and were completely ignoring my responses. Here’s a sample:

Someone calling him or her self “Janet Mason”:

“Hello Seller,
Can I know the condition of the item? I think you will accept PayPal. And I will pay the postage and packing cost for the item. If you can send me paypal payment request now and I will make the payment straight away without any delay. Hope to hear from you very soon.”

My response:

“Janet

As the ad say, the phone is in “as new condition”. This means what it says. The phone is completely clean and has no visible markings or scratches.”

“Janet’s” reply:

“Ok send me your paypal Payment request now so that I can make the payment now.”

My response:

“I’d like a bit more detail first please.

Where are you? (Full address and telephone mumber so that I can confirm that I am sending to “Janet Mason”.

Details of your confirmed paypal account (so that I know that Paypal have verifed you).

If you want to know why I am concerned please read the paypal guidance for sellers – particularly the bit about sending only to UK or US based addresses and getting signatures on receipt of goods.

I have received several requests to send the phone to “my daughter/son/nephew” or whatever in various Countries outside the EU. I am naturally suspicious.”

“Janet” then says:

“Hello, 
Am in London right now but due to the nature of my work here in London I will not be able to post the item to my Business Partner Daughter in Nigeria as a New Year Gift. But I will pay for the postage and packing cost via FedEX. Get back to me with your paypal payment request now so that I can make the payment now and get the item posted out tomorrow Morning.”

Correspondence ends…..

Now whilst I have not lost the ‘phone, I have verified a usable email address to a bunch of scammers. I expect my spam volume to that address to increase dramatically. Never mind though, I’m not alone in losing out to the bad guys, and at least I haven’t lost any passwords in the process.

Still, I’m pretty pissed off.

Tags: , , , , , , ,
Posted in privacy, security, trivial musing | No Comments »

professional ability

Saturday, September 25th, 2010

I was skimming through a series of security related sites last week when I came across an article referring to someone described as something like “A Person, M.Inst.ISP, CISM, CISSP, MBCS, CITP, BSc, Director of etc…..” and I found myself wondering what that all actually meant. Yes, I know what the letters stand for, hell I’ve even got a few of them myself, but what do they actually mean in the real world? And because of those letters, would you believe that person knew anywhere near as much about software security as say David Litchfield (Jr), or Charlie Miller, or Thomas Dullien?

Just wondering.

Tags: , ,
Posted in security, trivial musing | No Comments »

autossh – or how to use tor through a central ssh proxy

Sunday, August 1st, 2010

Since I first set up a remote tor node on a VPS about this time last year, I have played about with various configurations (and used different providers) but I have now settled on using two high bandwidth servers on different networks. One (at daily.co.uk) allows 750 Gig of traffic per month, the other (a new player on the block called ThrustVPS) allows 1000 Gig of traffic. These limits are remarkably generous given the low prices I pay (the 1000 Gig server cost me £59.42, inc VAT, for a year. OK, that was a special offer, but they are still good value at full price) and they allow me to provide two reasonably fast exit servers to the tor network. Both suppliers know that I am running tor nodes and are relaxed about that. Some suppliers are less so.

I fund fast exit nodes as a way of paying something back to the community – but as I have pointed out before, they also allow me to have a permanent entry point to the tor network which I can tunnel to over ssh, thus protecting my own tor usage from snoopers. For some time I used a configuration based on tyranix’s notes documented on the tor project wiki. But eventually I found that to be rather limiting because it meant that I had to remember to run an ssh listener on each machine I used around the house (my laptop, netbook, two desktops, my wife’s machine etc) and to configure the browser settings as necessary. Then I hit upon the notion of centralising the ssh listener on one machine (I used the plug) in a sort of ssh proxy configuration. This meant that I only had to configure the local browsers to use the central ssh listener as a proxy and everything else could be left untouched. It also has the distinct advantage that my wife no longer has to worry about anything more complex than switching browser when she wants to use tor.

But I hit a snag when initially setting up ssh on the plug. For some reason (which I have never successfully bottomed out) the ssh process dies after an hour of inactivity. This is not helpful. Enter autossh. Using autossh means that the listener is restarted automagically whenever it dies so I can be confident that my proxy will always be there when I need it.

Here’s the command used on the plug to fire up the proxy:

autossh -M 0 -N -C -g -l user -f -L 192.168.57.200:8000:127.0.0.1:8118 tornode

That says:

- M 0 – turn off monitoring so that autossh will only restart ssh when it dies.
- N – do not execute a command at the remote end (i.e. we are simply tunneling)
- C – compress traffic
- g – allow remote hosts to connect to this listener (I limit this to the local network through iptables on the plug)
- l user – login as this user at the remote end
- f – background the process
- L 192.168.57.200:8000 – listen on port 8000 on the given IP address (rather than the more usual localhost address)
- 127.0.0.1:8118 tornode – and forward the traffic to localhost port 8118 on the remote machine called tornode

Of course “tornode” must be running ssh on a port reachable by the proxy. Again, I use iptables on tornode to limit ssh connections to my fixed IP address – don’t want random bad guys knocking on the door.

Now on tornode I have polipo listening on port 8118 on localhost. I used to use privoxy for this, but I have found polipo to be much faster, and speed matters when you are using tor. My polipo configuration forwards its traffic to the tor socks listener on localhost 9050. I also disabled the local polipo cache (diskCacheRoot = “”) because leaving it enabled means that the cache (by default /var/cache/polipo) directory will contain a copy of your browsed destinations in an easily identifable form – not smart if you really want your browsing to be anonymous (besides, my wife deserves as much privacy as do I).

The final bit of configuration needed is simple. Set your chosen browser to use the proxy on port 8000 on address 192.168.57.200. Since I use firefox for most of my browsing, I simply use opera for tor and I have that browser stripped to its basics and locked down as much as possible. Using tor is then simply a matter of firing up opera in place of firefox. This means that I always know when I am using tor or not (and just to reassure myself, the opera homepage is the torcheck page).

You can’t be too careful.

Tags: , , , , , , , ,
Posted in networks and networking, privacy, security, tips, tricks and howtos, trivial musing | 4 Comments »

zf05

Sunday, August 2nd, 2009

I really missed the old phrack magazine. Some of the “loopback” entries in particular are superb examples of technical nous, complete irreverance and deadpan humour. One of my favourites (from phrack 55) appears in my blogroll under “network (in)security”. I am particularly fond of the observation that details of how to exploit old vulnerabilities are “[ As useless as 1950's porn. ] “. As I said, sorely missed (but now, with issue 66 back in action after over a year since the last release).

It would seem, however, that I have been missing a new kid on the block who follows in phrack’s footsteps. A group called zf0 (zero for owned) appears to publish a ‘zine in the mold of the phrack of old. And their latest release, zf05.txt has been causing something of a stir because it relates details of the compromise of systems owned and/or managed by some high profile and well known personages such as Dan Kaminsky and Kevin Mitnick.

The ‘zine bears reading. The style is unmistakably “underground” and “down with the kids” and it is (unnecessarily in my view) filled with unix-geek listings of bash history files and such like, but its authors still manage to make the sort of pertinent comments that I so loved in phrack.

“It’s the simple stuff that works now, and will continue to work years into the future. Not only is it way easier to dev for simple mistakes, but they are easier to find and are more plentiful.”

How well patched are you?

Tags: ,
Posted in linux and unix, networks and networking, security, trivial musing | No Comments »

more DNS silliness

Wednesday, December 24th, 2008

I came across an interesting post on Avert labs site recently. That post pointed to an earlier SANS posting, which in turn, referenced a Symantec discussion of a new Trojan called Trojan.Flush.M. This trojan is an interesting variant of a class of trojans which hijack local DNS settings to force the compromised machine to use a hostile DNS server. The hostile server will then redirect the user to fake sites – usually Banks in an attempt to extract identification and authentication credentials. As the Avert post says, there have been various types of DNS changing tactics employed in the past, but the clever tactic used by this latest trojan is that it subverts the use of DHCP on any network which uses that protocol to manage client system settings. Once the trojan has been installed on a (windows) PC it creates a new service on that PC which allows the machine to send fake DHCP offer packets to any requesting client on the network. The DHCP offer includes the address of a hostile DNS server outside the network. The neat point here is that any client system on the network, regardless of the operating system in use, can then be subverted – and without some network traffic analysis it will be very difficult to find out how the subverted machine was compromised.

But, and this is a big but, the whole attack fails when faced with a properly designed and well managed network. Consider: for the attack to be succesful the subverted client must be able to make DNS requests directly to the hostile server. But no corporate network should allow a client system direct access to the net. All DNS requests should be answered by a local DNS server and that server should be the only machine which is allowed to forward DNS requests to the outside world. Indeed, that server should probably only forward DNS requests to specific servers on the company’s service provider network. The bad news of course, is that any home or SOHO network is unlikely to be well designed and protected.

One of the respondents to the Avert post seems to have missed the point entirely though. He said “All the more reason to consider using trusted third party DNS networks, such as OpenDNS.”. Oh dear, that is so wrong in so many ways. Just think that through will you Jason?

Tags: , , , , ,
Posted in networks and networking, security, trivial musing | No Comments »

backtrack 3 released

Friday, June 20th, 2008

Any half decent sysadmin will routinely test the security of his or her own systems. A good, and sensible, sysadmin will follow up those tests with an independent security audit by a professional company – preferably one which is a member of a recognised industry body (such as CREST). Finding the holes in your security mechanisms (and there will be some – probably more than you will be happy about) before the bad guys do is essential if you want to sleep at night (and keep your job).

There are a huge number of security testing tools available for free if you know where to look. Most sysadmins keep a toolbox of their favourites (nmap, nessus, ettercap, dsniff et al.) to hand ready for testing any new build. But it can sometimes be difficult to know just which tool to use, and where to get it. Enter backtack. I first came across this collection of tools as recently as february 2006 and found it an excellent resource. Essentially backtrack is a collection of all the security testing tools you are likely to need packaged into one linux distribution. Think of it as a knoppix for security testing. A complete list of all the tools in the collection can be seen here.

Bactktrack Version 3 has just hit the streets. Get it here.

(Oh, and don’t think that using a toolset like this makes you a pen-tester. It doesn’t. What it might do is make you more security aware, and a better sysadmin.)

Tags: , , , ,
Posted in linux and unix, networks and networking, security, tips, tricks and howtos | 2 Comments »

« Older Entries