Re: Wireless car in Christchurch?
I see that Firefox built-in a Google API geo-location function. Basically G uses the common IP country allocation blocks but refines this using what local wireless networks (SSIDs) your browser/machine can see. As per http://en-us.www.mozilla.com/en-US/firefox/geolocation/ - see 'How It Works' I'm guessing that this is Google (or competor) war-driving using an unmarked car to avoid privacy issues. On Thu, Nov 26, 2009 at 3:10 PM, Adrian Mageanu adrian.mage...@totalimex.com wrote: Looks dodgy to a knowledgeable eye, probably is. Haven't seen the car, but if it looked suspicious enough to me, I'd call the authorities. Worst that can happen is a news snippet at 6pm saying that a car belonging to a legit organisation doing some work in town was so poorly equipped that it raised the suspicion of the tech savvy Christchurch public enough to call the police. Best case scenario you stop dead a scam in progress. On Thu, 2009-11-26 at 14:46 +1300, Craig Falconer wrote: Lee Begg wrote, On 26/11/09 13:59: Paul Swafford wrote: maybe checking for over-boosted WiFi antennae ? Or building a wireless coverage map (not necessarily WiFi)? The aerials looked like simple $10 magnetic base ones, with cables snaking loose over the roof and into a rear door. Not exactly industrial quality.
REMINDER: Christchurch NZPUG Meetup This Friday 4 December
Hi all, Just a reminder that we've got the following event Friday this week. Details are as follows: Date: 4 December 2009 Time: 5:30-7:30pm URL: http://nzpug.org/MeetingsChristchurch/Dec2009 Talks: * Kevin Alcock: An Intro to Google App Engine * Morris Johns: Python on the wifi router (5 minutes) * Tim Knapp: ContentMirror - Manage Your Web Content In Plone and Serve It Up In Insert Favourite Server Costs: As per our previous meetings we'll order some pizzas on the night and get some donations (usually a few dollars) towards this then. RSVP: As per previous meetups, please send an email to meeting-christchurch AT nzpug DOT org to let me know, so we can make plans for after preso nibbles/etc. Look forward to seeing you all there! Kind regards, Tim
Subtle Info Leak of the Year...
We're mucking about with openwrt routers and we stumbled across this curious scenario... We couldn't ping the router yet we could see the ethernet mac address in the arp cache. Clear the address out of the cache, check it's not there, ping, the ping fails, check the arp cache, and lo, the mac address is there again! The critical clue was the router could ping the PC. Solution? The router has a fairly fancy firewall thingy that was rejecting the incoming ICMP ip packet, but the arp is handled at the ethernet MAC layer _below_ the ip layer. Hence the subject line... subtle info leak of the year. Firewalls leak tiny bits of info at the mac level, even if they reject everything at the IP level. John Carter Phone : (64)(3) 358 6639 Tait ElectronicsFax : (64)(3) 359 4632 PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz New Zealand
Re: Subtle Info Leak of the Year...
The MAC address of the router must be visible on the upstream link, or the router is useless. Isn't that the only information that is being leaked? The router is only trying to prevent pinging of boxes _behind_ the firewall. As a side effect, you can't ping the router. John Carter wrote: We're mucking about with openwrt routers and we stumbled across this curious scenario... We couldn't ping the router yet we could see the ethernet mac address in the arp cache. Clear the address out of the cache, check it's not there, ping, the ping fails, check the arp cache, and lo, the mac address is there again! The critical clue was the router could ping the PC. Solution? The router has a fairly fancy firewall thingy that was rejecting the incoming ICMP ip packet, but the arp is handled at the ethernet MAC layer _below_ the ip layer. Hence the subject line... subtle info leak of the year. Firewalls leak tiny bits of info at the mac level, even if they reject everything at the IP level. John Carter Phone : (64)(3) 358 6639 Tait ElectronicsFax : (64)(3) 359 4632 PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz New Zealand __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __ === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. ===
Re: Subtle Info Leak of the Year...
On Tue, Dec 1, 2009 at 5:22 PM, John Carter john.car...@tait.co.nz wrote: Firewalls leak tiny bits of info at the mac level, even if they reject everything at the IP level. That's probably because the 'firewall' employed by Linux/OpenWRT is called 'IP Tables', and has to receive an IP packet in order to decide what to do; and on Ethernet that means ARP has to complete first. Real network-level firewalls give you much lower-level controls, should you need them. There are still some limits regarding what you need to do in order to receive data, and some hacks to get around that; but in an Ethernet network that leakage can be restricted to just the nearest switch. IP Tables is basically a host firewall, and the host can also be a router if it likes; but that doesn't make it real network equipment. However, if all you're doing is running IP networks, the difference is small enough to be ignored in most cases. Oh, and as an aside; please allow your network edge devices to respond to ping. It's very difficult telling the difference between an ISP-link failure (i.e. a non-IP network) and a firewall failure if the damn firewall won't respond to ping when everything is working normally ... -jim
Re: Subtle Info Leak of the Year...
On Tue, 1 Dec 2009, Douglas Royds wrote: The MAC address of the router must be visible on the upstream link, or the router is useless. Isn't that the only information that is being leaked? The router is only trying to prevent pinging of boxes _behind_ the firewall. As a side effect, you can't ping the router. Not much info of value is being leaked except... * Existence. ie. If you thinking of a firewall as being invisible if it isn't jabbering, you're mistaken. * Nature. ie. You can infer the manufacturer from the mac address. Looking at the arp stream going by me with wireshark at the moment I can tell there are vmware virtual environments, cisco routers, toshiba, sun, intel,... As I said, it's subtle. Nothing great.. Just enough to confuse the hell out of me for a while. A sort minor WTF moment. How could arp be getting through but not ping? Well, now I know. John Carter Phone : (64)(3) 358 6639 Tait ElectronicsFax : (64)(3) 359 4632 PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz New Zealand
Re: Subtle Info Leak of the Year...
On Tue, 1 Dec 2009, Jim Cheetham wrote: Oh, and as an aside; please allow your network edge devices to respond to ping. It's very difficult telling the difference between an ISP-link failure (i.e. a non-IP network) and a firewall failure if the damn firewall won't respond to ping when everything is working normally ... I _love_ ping and never willingly harm my very very helpful little friend. Alas... the out of the box defaults for more and more things are getting quite hostile. Sigh! John Carter Phone : (64)(3) 358 6639 Tait ElectronicsFax : (64)(3) 359 4632 PO Box 1645 ChristchurchEmail : john.car...@tait.co.nz New Zealand
Re: Subtle Info Leak of the Year...
On Tue, 2009-12-01 at 18:23 +1300, John Carter wrote: On Tue, 1 Dec 2009, Jim Cheetham wrote: Oh, and as an aside; please allow your network edge devices to respond to ping. It's very difficult telling the difference between an ISP-link failure (i.e. a non-IP network) and a firewall failure if the damn firewall won't respond to ping when everything is working normally ... I _love_ ping and never willingly harm my very very helpful little friend. Alas... the out of the box defaults for more and more things are getting quite hostile. Sigh! rfc 1122 3.2.2.6 Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. Steve -- Steve Holdoway st...@greengecko.co.nz http://www.greengecko.co.nz MSN: st...@greengecko.co.nz GPG Fingerprint = B337 828D 03E1 4F11 CB90 853C C8AB AF04 EF68 52E0 signature.asc Description: This is a digitally signed message part
