June 2006 - NANOG - lists.nanog.org

IPv6 Transit?
by Mat Sharpe 15 Jun '06

15 Jun '06

Hi, Does anyone have any info on IPv6 deployment at the Tier-1 / Tier-1.5 level? We are multi-homed to both Level3 and Abovenet in the UK and Level3 only in the US. Level3 did have a promising sounding beta program last year but that seems to have stalled. Abovenet apparently have no schedule to deploy v6 at the moment. I would like to be able to v6 enable our network but without a transit provider that’s going to prove a bit tricky. Any thoughts appreciated! Cheers, Mat Sharpe Qube Networks Ltd P.S. I hope I’m not about to re-start the who is/is not a Tier-1 / Tier-2 argument! :)

7 6

Re: Interesting new spam technique - getting a lot more popular
by Hank Nussbacher 15 Jun '06

15 Jun '06

> * A spamware daemon is installed on the dedicated server, to keep >the network interface in promiscuous mode > > * The daemon determines which IP addresses on the local subnet are >not in use. It also determines the addresses of the network routers. >One or more unused IP addresses are commandeered for use by the >spammer. > > * The perp server sends unrequested ARP responses to only the >gateway routers, so that the routers never have to ask for a layer-3 >to layer-2 association -- it's alway in the ARP cache of the routers. >Nobody else sees this traffic in an EtherSwitch fabric, so ARPWATCH >and its kin are defeated. Pings and traceroutes also fail with "host >unreachable.". The daemon then only has to watch on the NIC, in >promiscuous mode, for TCP packets to the hijacked address on port 80, >and pass them down the tunnel to the remote Web server. > > * Finally, GRE and IPIP tunneling is used to connect the stolen IP >addresses to the spammer's real servers hosted elsewhere. > >The end result is that the spammer has created a server at an IP >address which not even the owners of the network are aware of. And if one went to http://www.senderbase.org/ and monitored their own IP block, wouldn't the spammer appear there? Or just plain monitoring spikes in outgoing port 25 traffic should alert someone that something is amiss. -Hank

1 0

RE: Interesting new spam technique - getting a lot more popular.
by Church, Chuck 14 Jun '06

14 Jun '06

Since this technique requires a IPinIP or GRE tunnel, wouldn't blocking these two protocols to/from the hosts be sufficient? Assuming of course the customer's host isn't using that normally. Chuck Netco Government Services has recently acquired Multimax and is changing its name to Multimax Inc. Visit http://www.multimax.com for more information.

3 2

Re: wrt joao damas' DLV talk on wednesday
by Paul Vixie 14 Jun '06

14 Jun '06

> Is there a better way to have handled the situation? Perhaps. indeed, i should have registered as a speaker and sat behind joao while he spoke. > The positive outcome of this issue is that we are discussing how to handle > "drop-ins" (freebie conference attenders?). agreed, there's a salient issue underlying all of this chaff. for example, if someone only wants to come to nanog for the hallway discussions and not attend any of the meetings or bofs (or eat any of the food, or use the wireless), are they welcome? before last week i'd've said "yes." manners in this case means "what should others be allowed to do" rather than "what each of us would like to be able to do", or in other words, "what will scale?" > I still don't see that you fall into this category with regard to this > incident. from my personal e-mail so far, that view is in the minority. ("this is not your grandfather's nanog.") on the other hand i really would rather talk about DLV than "meeting manners."

13 27

wrt joao damas' DLV talk on wednesday
by Paul Vixie 14 Jun '06

14 Jun '06

i intended to be present for the Q&A after joao's DLV talk but i was told that being there without having registered was rude. as i was exiting the room, i heard sam weiler at the Q&A mic repeating his prior comments as to how ISC should not be a DLV registry, and i saw mark kosters in line at another mic probably as a followup to my followup to his earlier question. i apologize for the length of this note, and for the fact that it says more about DNS bits and kibble than anybody really ever wanted to know, and also for my rudeness in attending joao's talk without having registered for nanog. first, sam weiler's question. let me answer, here on the mailing list where rudeness is an art form, that ISC intends to follow through on DLV. while we solicited (and got!) much design input (from sam weiler among others including david conrad who gave me the idea for DLV in the first place), ISC holds "change control". this isn't an IETF effort. just a cooperative based on some source code. both the source code (bind9.3 and bind9.4) and the DLV specification are completely forkable in the BSD tradition-- anyone else who wants to do this differently is welcome to any of the ideas or code ISC has published. and if someone else with similar resources and similar trust tells me that they are going to run a DLV registry (starting immediately-- ours is open NOW) then we would possibly re-evaluate the need to do a DLV registry inside ISC. none of that appears likely. to me, continued nondeployment of dnssec is what seems likely, seasoned with periodic 11th hour "oh no, the secure dns spec isn't done, let's re-open all the issues we thought were closed" parties. sam also wanted to know how ISC planned to verify zone ownership for the purpose of knowing whether or not we should accept a proferred key for, say, "bankofamerica.com". i think sam also echoed randy bush's earlier concern as to how we would secure our DLV registry against data loss, hacking, and so on. joao damas already answered those, and he's the programme manager for DLV, so we can all trust his answers. so i've heard sam's comments before, and had i actually registered for nanog i would surely have answered them as i've answered before, and now you all know what i would have said. second, mark kosters' additional question. i have no idea what mark kosters' additional question was, but if it had to do with my followup to his previous question, it was probably "what's the real difference, if any, between a TLD registry putting their key in ISC's DLV registry vs. running a DLV registry themselves?" if so, then i'm glad he asked, it's a favorite topic of mine. if a TLD registry (such as mark kosters' employer, verisign, for "COM" and some other TLDs) wants to sign their zone but their desire is irrelevant because the root zone is not yet signed, then they could meet some of the same requirements by sending ISC a DLV RR. their customers (VIX.COM in my case) would not have to do anything special -- we could just sign our zones and send our keys to our registrar (alice's registry in my case) who would then forward them to the TLD registry via some proposed EPP extensions. this is the best case scenario since there's only one key held by DLV, which is the one for COM, and once IANA gets around to signing the root zone, the only change will be that verisign will send its COM key to IANA rather than to ISC. no registrar or registrant ("zone holder") would have to know or make any changes to their software or procedures. if on the other hand a TLD registry (such as verisign) was not planning, for reasons such as subdomain enumeration or size-of-metadata (both of which are proposed to be solved by NSEC3, now in early preproduction), to sign their TLD (for example, COM), then that registry would have no key to send to IANA (if the root was signed) or to ISC for the DLV registry (if the root remains unsigned, as appears likely for the near term.) in this less-than-best case, registrars could send ISC blocks of registrant keys for the DLV registry, or registrants could send ISC zone keys directly. the reason this is less-than-best is that ISC would have to verify zone ownership before publishing a zone's key, unless we can get registrars to do this for us and send us blocks of keys). since we aren't charging any fees for DLV registrations, we're currently putting the burden of proof of zone ownership on the zone owners. (they have to contact joao damas or come to ISC's main office and present credentials, ideally using strong-chain PGP.) there is some question in my mind as to why a TLD registry would choose to run a DLV registry rooted at their TLD, rather than just signing their TLD. perhaps it's because DLV, even as ugly as it is, avoids the same subdomain enumeration ("zone walking") and metadata-size problems that NSEC3 avoids, but DLV is in its late stages whereas NSEC3 is in its early stages. or perhaps a TLD registry might not want to see other companies, even 501(c)(3) public benefit companies like ISC, carrying data for their registrants or having direct relationships with their registrants and registrars. i dunno. but to now repeat my earlier answer with this additional context: if every TLD registry wants to run its own DLV registry, then the world's validator population will probably experience "cut and paste fatigue". there are about 250 TLD's, and there are potentially many millions of validators. if one TLD per month needs to update its static DLV validation key, that's a whole lot of cutting and pasting that'll never happen after month 2 or so. that's why a clearinghouse, such as IANA for the root zone as called for in the dnssec-bis specification, or ISC's DLV registry until the root zone is signed, is necessary. ISC's actions in undertaking this without sharing change control in the usual IETF way have been called controversial. my advice to those of you who think we are doing the wrong thing is, pick one of the following and execute: 1. figure out why the root zone isn't signed and fix whatever it is. 2. design your own version of DLV (as sam weiler has done, long before ISC's although i didn't learn this until later), publish it, and urge adoption (find someone to run a DLV registry, implement the validator side, and so on.) 3. rubber-stamp ISC's DLV design, adopt our BSD-licensed source code for the validator side, start your own DLV registry. 4. go to IETF and say "i think something DLV should be a standard but i don't like ISC's, so let's make an RFC together." what you should note in common with all of these things is that ISC could never prevent alternatives from coming into existence (nor would we wish to), and indeed all of our work on DLV is directly forkable/leveragable by any alternative effort, even potentially proprietary or commercial ones. so, go for it! (my concern is, DLV is an evolutionary dead end, a deployment aid, and pissing away even more time and money on it seems like a waste of time compared to finishing NSEC3, signing the root, y'know, important stuff.)

12 20

RE: Interesting new spam technique - getting a lot more popular.
by John van Oppen 14 Jun '06

14 Jun '06

It sure seems like this is a good demo of the best practice of having customers on their own VLANs with their own subnets. We have been doing this since we started offering colo services, is this less common than I thought? John -----Ursprüngliche Nachricht----- Von: Christopher L. Morrow [mailto:christopher.morrow@verizonbusiness.com] Gesendet: Tuesday, June 13, 2006 9:23 PM An: Suresh Ramasubramanian Cc: NANOG Betreff: Re: Interesting new spam technique - getting a lot more popular. On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: > That was not my advice btw - just forwarding on what I saw. > oh,. apologies, i did cut the message down quite a bit :( I understood you were quoting from the spamdiaries website, I apologize to the other listeners (readers?) if it confused the issue. > What you say does seem like a "must do" all right - but putting ARP > filters in is actually a reasonable idea. > Atleast it'd trim down the 'problem' to the single customer subnet, I assume that dedicated hosting folks don't just drop machines behind a switch on one big flat subnet? That's probably a naive assumption though :( Perhaps this is clue #12 that that is a 'less than good' option? :) > On 6/14/06, Christopher L. Morrow > <christopher.morrow(a)verizonbusiness.com> wrote: > > > > On Wed, 14 Jun 2006, Suresh Ramasubramanian wrote: > > > > > > http://thespamdiaries.blogspot.com/2006/02/new-host-cloaking-technique-used… > > > > > > * Monitor your local network for interfaces transmitting ARP > > > responses they shouldn't be. > > > > how about just mac security on switch ports? limit the number of mac's at > > each port to 1 or some number 'valid' ? > > > > > -- > Suresh Ramasubramanian (ops.lists(a)gmail.com) >

3 2

re" howto deploy DNSSEC [was: Re: wrt joao damas' DLV talk on wednesday]
by Martin Hannigan 14 Jun '06

14 Jun '06

>I'm ashamed to call myself a participant in NANOG, IETF and ICANN. > >every once in a while I get to participate in something that moves >forward the network just a bit; > >please refrain from this thread -- a few folks are attempting to >move DNSSEC ahead; we will fail, but would appreciate any >constructive criticism on the pitfalls to deploy before we are all dead. > > >-rick I'm not. Consensus usually comes after the party, not before. -M< -- Martin Hannigan (c) 617-388-2663 Renesys Corporation (w) 617-395-8574 Member of Technical Staff Network Operations hannigan(a)renesys.com

2 1

Day tickets
by Henk Uijterwaal 13 Jun '06

13 Jun '06

On the DLV thread, but not responding to anybody in particular. As soon as you allow people to attend 1 talk for free, then you opened the door for people attending without paying. OTOH, I don't think that it is fair to ask people to pay the whole $350 if they only want to attend a few talks. For the RIPE meeting, this has been solved by introducing day tickets. People who don't want to attend the whole meeting, can buy tickets for individual days. They can attend the sessions they want, without feeling guilty about using resources but also without having to pay the full fee to attend only a few talks. Maybe this can be considered for NANOG as well Henk ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400. Watch this space...

3 2

2006.06.07 NANOG-NOTES Lightning talk notes
by Matthew Petach 13 Jun '06

13 Jun '06

(I think these were the toughest to take notes on, since they went by so fast; took the most cleaning up afterwards. But they were also the best talks of the 3 days. I wish we could have flipped, and taken more time on Tuesday for them so we really could have dug in and asked the questions we were itching to ask. ^_^; --Matt) 2006.06.07 Lightning talks Marty Hannigan, Renesys: [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/1-hannigan.pdf Critical infrastructure, root server location analysis Where to stick your servers. :) he took some public info out there on root-servers.org talked to some people, extrapolated from larger set of data. operator demographics. in US: 3 corp a, c, j 2 edu b and d 1 mil g 2 research e/h 3 nonprofit f, i, l autonomica is responsible for l, but hosts "some" instances on a CDN; CDN is a US formed entity in EU: 1 non profit k asia/japan: 1 nonprofit m 92% of system operated in US, 8% non-us; 5% margin of error +-. US entity type non-us 8% us corp 39% us mil 23% us edu 15% us nonprofit 15% where? in 54 countries all religions all methods of governance politically: 79% are democratic governments 21% in other forms of government global diversification for security and performance instances spread across continents different networks different proceedures different software different hardwware different weaknesses weaknesses become strength, since they are diverse; no one weakness knocks out all servers. little less open to insider malfeasance Global distribution NA 38% EU 35% Asia 12% AUs 8% east EU 3% LA 2% Africa 2% ANT 0% getting reasonable coverage in the world situating a root server relationship 101 who you know ICANN, operator, IX, and RIR relationships regulators how you spin it national pride performance and security betterment of user experience Threats no different from anyone else direct attacks proxy attacks botnets easy money miscreants masking other activities Not sure what motivations to attack root servers; can't extort money from nonprofits let's attack a root server target $-root location; eu hosting facility multi-post cabinet config with cabling and power under floor unlocked cabinet, single factor facility entry physical attack open cabinet door access to power hijack attempt advertise a route return bad answers network attack spoof source random host queries packet floods summary: root system is less likely to be subject to insider attack or weakness but can be attacked by layer 3 there is likely good resarch data coming across those interfaces trend towards a collapsed root system, where root and TLD share same hardware or networks should be more closely examined. slides will be up soon, talk to him in the hallway NEXT, Anton Kapela Network RTTs [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/2-kapela.pdf I'm pinging 10: high rate active probes we're pinging stuff really quickly adjusted host kern.hz to 1000 select() gets pretty accurate +-1ms emmission accuracy stuff is responding Interesting 0.001% of data relates to end-to-end queuing what has been sampled? some cisco 7513s IOS 12.3 mainline linux 2.4.20 freebsd 4.8 NT4 sp6 various end-to-end paths on u-wisc network raw data isn't terrible interesting. in adaptive link layer protocols, see rate shifting manifested in RTT wireless, HPNA/HCNA, powerline ethernet 10,30,60,90 second peaks fourier transforms, wavelet transforms, frequency domain 1000 seconds at 10ms intervals break into composite, aggregate graph at top, 0-50hz span on x axis, y axis is contribution summary of entire graph. bottom right graph is rough 200 samples of a range from 0-5hz, 100pps, deduce delay at half that sampling rate. delay is not a simple boring thing; has scheduler delays, path dynamics not visible before to see queue depths. shark fins showed up; congestion events do occur, are quite measurable. when links are hot, queues are obvious, esp. on highly multiplexed links. bottom left, cubic resonance, several tens of thousands of multiplexed flows hitting odd resonance. pinging windows machine, composite spectral fingerprint; 10,20,25,30 spikes Linux fewer spikes freebsd low and flat IOS is 10, 20, 30 and grass of 1hz spacing below 10hz. win32 delay spectrum also has 1hz fuzz below 10hz. Sampled RTT and performed signal analysis of it; now what? is network time continuous? is round trip time discreet or continous? no changes in revealed as you go down lower is delay a "signal' anyway what's with the 0 hz DC component in the FT output? could this be used for fingerprinting? yes, could be like next nmap. packet-level fingerprinting is trivial to fake; but IP stack scheduler behaviour doesn't change so easily. NEXT: Mikael Abrahamsson Affect on traffic from the TPB bust with Kurtis Lindqvist [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/3-abrahamsson.pdf Bittorrent background p2p protocol for filesharing. text string, upload to tracker, get IPs of other clients that have done the same thing, clients connect to each other, develop a swarm. clients communicate even when tracker vanishes. just can't get new clients joining Thepiratebay.org run by a handful of individuals aged 22 to 28 used ~100mb at peak peaked at 2M concurrent users stats code in tracker indicated that total p2p traffic was close to 100gig/sec thus far, largest bittorrent site/tracker in world photo slide showing the physical gear 10 high-end small servers in half a rack in stockholm, sweden web frontends, db servers, trackers on the stats not an exact science at least a german ISP had an outage at the same time bust was around 12.00 CET may 31st (euro time) data collected from Euro-IX members some saw no difference. Netnod aggregated, biggest drop, about 10+Gb drop very quickly in Netnod stockholm *very* visible. stats server was slashdotted, lost an hour of stats. LINX London, saw about 5Gb drop out of 80Gb AMSIX dropped about 5Gb out of 160Gb DECIX frankfurt, germany, drop before noon, FCIX, helsinki, Finland drop fairly visibile NIX, in norway, drop also visible. doesn't show private exhanges/private peerings Brussels (BNIX) also saw drop. netflow export from big US ISP, large chunk of bittorrent traffic packets faded off. Thepiratesbay.org was back online 72 hours later in Amsterdam, Netherlands and traffic started coming back June 6th is a holiday, watch the stats this coming week. :) Aftermath Police took ALL hosted equipment at the same site by the same hosting company (small one, only a few racks), caused quite a few community web sites to go down plus commercial customers Has spawned a lot of discussion in Sweden regarding all issues involved. Front page material every day, even video surveillance of the raid from surveillance cameras has been posted on youtube.com Accusations of police/politicians being influenced by White House and MPAA and others Q: Bill Norton: what about other tracker sites, why didn't traffic just shift to them? A: some did, but torrent files have the tracker hard coded in them, so they can't just flip over to other tracker sites on their own. Q: Roland Dobbins, back up in several countries now including Russia, is traffic back? A: Keep watching the graphs. And if you want to see the bust, search for "pirate bay" and "police", there's one link on youtube. NEXT: Alex Pilosov/Pilosoft Adam Rothschild/Voxel Nathan Patrick/Sonic.net [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/4-pilosov.pdf Passive Metro WDM how it works single mode fiber: mutiple wavelengths also called "colours" or "lambdas" coexisting separately pluggable optics as enabler low cost for passive optical equipment, particularly grey market Dark fiber IRUs are very cheap. low opex/capex how does it work? O band Original 1260 - 1360 E band Extended 1360 - 1460 S band Short 1460 - 1530 C band Conventional 1530 - 1565 L band Long 1565 - 1625 implementation options active WDM cisco 15xxx, cienna, movaz, others passive WDM using optical filters self-assembled patch panels complete systems (CUBO) pictures of components GWDM/WWDM wideband multiplexing (1350/1550) 2GE fdx per pair, 1 GE fdx per strand single strand networking the receiver is *always* wideband low cost for transcievers (LX/ZX, <$500) 10GE possible (ER/LR) Active xWDM beyond this scope everyone knows how to do it, it just costs more. Passive CWDM wavelength, wide channels, 8 channels 1470-1610 conventional 1270-1470 low range cost is cheap ~$1000 per strand per end for CUBOs, $300-$1000 per GBIC depending on quality (CUBO, Taiwanese hw manufacturers) no Xenpaks, GBICs only 20nm channel spacing low availability on 'low range' GBICs/SFPs Passive DWDM each channel is narrow 0.8nm == 24 dense channel per single coarse channel 160 channels easily 25Ghz spacing research at 12.5Ghz Xenpaks available $9k+ few GBICs at $1500+ Filters: build/add as you grow by mixing and matching available in various ranges (center wavelength, bandpass width) Going from GWDM to GWDM/CWDM to GWDM/CWDM/DWDM Testing and management optical power meter communication is key OOB access: HOOTS, cell phone you need to talk site-to-site to coordinate make sure cell phones don't depend on fiber optical power monitoring/APD receivers in GBICs (show interface blah trans) spectrum analyzer Caveats few complete commercial systems available systems require clue and duct tape to put together need to tune with attenuators if signal is too strong, attenuators differ with wavelength flaky GBIC/SFP vendors small-time passive optical vendors expensive equipment for testing (spectrum analyzer, light sources, etc) lack of operational expertise (get hit by a bus) Exotic options Circulators (same wave both ways) Interleavers (half the light, double the waves) CWDM light into DWDM channel (similar to above) 10GE LX4/LR multiplexing Simple Economics 2GE GWDM ~$1k 8GE CWDM ~$5k-10k 2*10GE ~$5k-10k N*10GE DWDM ~N*$10k prices include passive and active components, per end, fdx over one pair Prices an order of magnitude lower than commercial systems from Cienna, Cisco. List of vendors Cloudy YAYA, Orient DONG, [lots of names on slide, go read it yourself] Questions? mail them! alex(a)pilosoft.com asr(a)voxel.net np(a)sonic.net Q: Martin, what do you about timing? A: No need for timing, each channel is separate, no timing needed to run this. Q: mike hughes, linx; one thing to look at if you're looking at GWDM/WWDM, or going bidir on one strand, watch out for back reflections--running several channels bidir would see itself reflected back, would declare linkup A: don't run two waves bidir on it--just don't do it, it's not worth it, it's too ghetto. NEXT: Mohit Lad Alerting prefix owners of hijacks in near-realtime UCLA, joint work with a bunch of other names [slides are at: http://www.nanog.org/mtg-0606/pdf/lightning-talks/5-lad.pdf PHAS project? Three properties of a security solution ability to see "bad" information ability to distinguish between "good" and "bad" info incentive to fix the problem The PHAS (prefix hijack alert system) approach use updates from existing BGP monitors (route views and RIPE RIS) if false origination, send notification. push complexity of detection to user look at email registration to decide who is allowed to announce prefixes. don't filter out false vs real changes. PHAS origin monitor 131.179.0.0/16, UCLA block recommend multiple email addresses, including some that are *not* on your blocks! Message Delivery apply local rules before generating alarms you shouldn't recieve duplicates of notifications due to topological mesh-ness, it's difficult for a hijacker to get all notifications for a block. Evaluation: messages per AS Dec 2005 map prefixes to origin AS using routing table most AS receive less than 100 messages per month most less than 10 local filters can limit legitimate origin changes. readily deployable routeviews and RIPE RIS already collect data alarm generation not dependent on cooperation from other networks monitoring or knowing correct origins alarm authentication: single source low overhead. summary comprehensive study using archived data developing near-realtime system interested in receiving notifications send email to: mohit(a)cs.ucla.edu massey(a)cs.colostate.edu ongoing efforts covered prefix hijack false last hop reference: PHAS: usenix security 2006. Q: Danny McPherson--that's associated with origin AS, and origin AS could be spoofed, does it look at combination of prefix, origin, and next hop up? A: they are doing it on origin AS and next hop, they'll do some more thinking about that case. NEXT: Rick Wesson, Support Intelligence [hehe] Understanding abuse, aggregate it, push it back to operators, let them know what they're doing to other people. [no slides, he does a live presentation of his tool] How do I believe you? realtime data visualization, Feb 8th, 2006 visualization. 130 different data sources, 90% passive; 10,000 domain aggregated spam trap, very evil SMTP that filters and bans IP for some time. 1.2million events per day aggregated, about 700,000 unique IPs for the global internet. BGP peers, aggregate based on announcements made. Put into tool so network operators can visualize their prefixes, drill in, and see abuse each prefix generates. hover over point, it shows the operator, IP address, and what the problem was (spam, insecure web server, etc) This shows problem areas that need to be addressed! disseminate this information, help ISPs clean up their networks. Can also pass along information of abuse that has happened to you. If you have an AS, he can tell you what your AS has been used for, abused for, owned, etc. email him for more info...except he didn't list his email info. ^_^; Break! short!

3 2

RE: Tracing network procedure for stolen computers
by Mike Callahan 13 Jun '06

13 Jun '06

Actually, it seems this his how you get stolen items back in the internet age ;-). http://www.evanwashere.com/StolenSidekick/ -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Michael.Dillon(a)btradianz.com Sent: Tuesday, June 13, 2006 5:32 AM To: nanog(a)nanog.org Subject: Re: Tracing network procedure for stolen computers > Earlier this month my daughters Ibook was stolen, oh well that is life I > guess. > Anyway updated mail server software for full debug and IP log since noticed > that mail account was accessed yesterday. It's a UNIX machine. You own it. You know the password. If you had only set up an SSH server on it, you would now be able to log in and collect additional information about the current user. Interesting things can happen when intelligent devices find themselves stolen... http://www.evanwashere.com/StolenSidekick/ --Michael Dillon

1 0