|
sarnold | i'd like to welcome everyone to today's uninet's presentations; our first presentation of the day is a second from the hard sciences to present at UMeet |
sarnold | Dr Jose Nazario has long studied 'network effects' -- how does the internet react as a whole to certain events |
sarnold | his latest study is on the dynamics of internet trust |
sarnold | comments and questions should be directed to #qc; jose will answer them here. :) |
sarnold | spanish in #redes as usual; and today, unique, translation to french in #atei |
sarnold | how cool |
sarnold | so please welcome dr jose nazario :) |
jose_n_ | thanks sarnold :) |
jose_n_ | heh .. those "network effects" seth speaks about are my forays into network investigation via perturbations, ie "inject some packets, forge some things, play :)". |
jose_n_ | i have the text and slides up here: http://monkey.org/~jose/presentations/umeet02/ |
jose_n_ | i'll be referring to the slides from that set. |
jose_n_ | INTRODUCTION |
jose_n_ | [slide 1] |
jose_n_ | This talk will be on a survey I did earlier this fall of over 2000 software |
jose_n_ | archives with detatched signatures. Looking for undiscovered trojans, errors, |
jose_n_ | and a general feeling of how well the system was working, I obtained and |
jose_n_ | verified these archives and studied the data set I generated. |
jose_n_ | A little bit about me. I'm a Ph.D. biochemist who left |
jose_n_ | science to go work in software engineering. Years ago I |
jose_n_ | founded Crimelabs as a way to share ideas and resources. |
jose_n_ | My research interests include trust relationships (of which |
jose_n_ | this research is a part), source code and software analysis |
jose_n_ | techniques and tools, and network measurements and |
jose_n_ | performance. I work at Arbor Networks in Ann Arbor, MI, |
jose_n_ | USA. |
jose_n_ | [slide 2] |
jose_n_ | Very briefly, this talk will cover the research into looking |
jose_n_ | for trojans on the Internet. We define a trojan as a modified |
jose_n_ | binary, using the term "Trojan horse" to indicate an altered |
jose_n_ | package which appears normal. I will briefly discuss the |
jose_n_ | motivation behind this work, which compelled me to go |
jose_n_ | looking for the prevalence of how many modified archives |
jose_n_ | there are on the Internet. After a discussion of how I did |
jose_n_ | this, I'll show you the raw results and then a discussion on |
jose_n_ | that data set as well as the meta data I gathered in this |
jose_n_ | research. Lastly, I'll describe some of the future work in |
jose_n_ | this area, some of which I am hoping to work on. |
jose_n_ | [slide 3] |
jose_n_ | The whole approach to this study was to download and |
jose_n_ | verify the archives. This is a rather simplistic approach, but |
jose_n_ | it seems to have gotten the job done and provided some |
jose_n_ | interesting results. Briefly, I identified signed archives |
jose_n_ | available on the Internet, downloaded them and grabbed the |
jose_n_ | corresponding PGP key, verified the archive, and then |
jose_n_ | analyzed the data. Errors were, of course, investigated. |
jose_n_ | [slide 4] |
jose_n_ | This study was motivated by the series of high profile |
jose_n_ | archive modifications which occured in 2002. Specifically, |
jose_n_ | after the OpenSSH trojan this summer, I build a small tool |
jose_n_ | to verify packages and started thinking about the wide |
jose_n_ | scale analysis which would be needed on the Internet to |
jose_n_ | discover how widespread this phenonmenon has become. |
jose_n_ | Specifcally, this year saw packages such as Dug Song's |
jose_n_ | tools dsniff, fragrouter, and fragroute trojanned, the |
jose_n_ | OpenSSH source code was modified and injected into the |
jose_n_ | mirror system, Sendmail suffered an interesting attack, and |
jose_n_ | the latest was tcpdump and libpcap. This, of course, begs |
jose_n_ | the question of how often this is happening. |
jose_n_ | Also, PGP has been around for about 10 years. It's a big |
jose_n_ | success in terms of use, and it would be interesting to see |
jose_n_ | how well the web of trust is doing. The threat model in this |
jose_n_ | analysis is simple: if someone were to alter a software |
jose_n_ | package, the failure to verify correctly via a PGP signature |
jose_n_ | should appear immediately. Furthermore, if a false key is |
jose_n_ | injected into the web of trust, that should also be appearant |
jose_n_ | from the failure to have the right relationships based on |
jose_n_ | signatures. |
jose_n_ | [slide 5] |
jose_n_ | Briefly, doing this study is relatively easy. I identified |
jose_n_ | software archives with detached signatures by using |
jose_n_ | Google. I simply looked for the common terms used to name |
jose_n_ | the signatures, such as '.tar.gz.sig' and '.tar.gz.asc'. This |
jose_n_ | built a list of about 166 unique servers with over 2800 |
jose_n_ | archives. After the OpenSSH fiasco I built a small tool |
jose_n_ | called `extract' which easily automatically performs the |
jose_n_ | PGP check needed to verify an archive. I modified the tool |
jose_n_ | for the purposes of this study to simply report on the |
jose_n_ | success or failure of the verification process. I then |
jose_n_ | downloaded these identified archives (using wget), |
jose_n_ | checked them all, and then post processed the data. |
jose_n_ | [slide 6] |
jose_n_ | Extract is a small shell script wrapper for tar and gpg. It |
jose_n_ | looks for the detached signature for an archive when you |
jose_n_ | want to extract a file. Finding the archive, it then checks for |
jose_n_ | the key on the local keyring. If the key exists, it continues. |
jose_n_ | If the key doesn't exist, it fetches the key, adds it to the |
jose_n_ | keyring, and then restarts. Once the key is present, the |
jose_n_ | signature if verified with the key. If it checks out ok, the |
jose_n_ | archive is extracted. |
jose_n_ | Extract was designed to be small, efficient, and easy to |
jose_n_ | use. While GPG has a relatively easy to use interface, |
jose_n_ | compare: |
jose_n_ | extract openssh-2.4p1.tar.gz |
jose_n_ | ... |
jose_n_ | and how you would do it manually: |
jose_n_ | gnupg --verify openssh-2.4p1.tar.gz.sig openssh-2.4p1.tar.gz |
jose_n_ | gnupg --keyserver search.keyserver.net --recv-key (KEYID) |
jose_n_ | gnupg --verify openssh-2.4p1.tar.gz.sig openssh-2.4p1.tar.gz |
jose_n_ | tar -zxvf openssh-2.4p1.tar.gz |
jose_n_ | That assumes you don't have the key locally and must fetch |
jose_n_ | it as well. I really prefer tools that are streamlined in their |
jose_n_ | use, and attempt to write tools that fit that model. |
jose_n_ | [slide 7] |
jose_n_ | The actual act of downloading the archives took about 3 |
jose_n_ | days on my cable modem. This was because the model I |
jose_n_ | built operated only serially (only one archive was downloaded |
jose_n_ | at any one time). By comparison's sake I was |
jose_n_ | able to max it out by running 8 parallel fetches for the Linux |
jose_n_ | kernel archives and complete it overnight, demonstrating the |
jose_n_ | classic time-space tradeoff. The total storage required for the |
jose_n_ | archives was about 9GB of disk. |
jose_n_ | [slide 8] |
jose_n_ | Briefly, here's a graph showing the impact of the traffic on |
jose_n_ | my cable modem for a 1 day or so period. You can see that |
jose_n_ | the traffic spikes really outshone my normal traffic, visible |
jose_n_ | on the left. (this is from a firewall monitoring tool i built for |
jose_n_ | my gateway.) |
jose_n_ | [slide 9] |
jose_n_ | The analysis, which occured in bulk, started with an empty |
jose_n_ | GPG key ring. I wanted to see what ring characteristics |
jose_n_ | emerged after this analysis. I modified `extract-0.1' to only |
jose_n_ | report on the success or failure of the verification process, |
jose_n_ | and in using extract (over gpg itself) I was able to fetch |
jose_n_ | keys as neeeded. The process was driven by a small shell |
jose_n_ | script wrapper which finds all of the archives in the |
jose_n_ | directory and runs this modified extract tool on them. Data |
jose_n_ | analysis took about 3 or 4 hours on my K6-2/300 machine, |
jose_n_ | which I use for most of my data collection needs (it's |
jose_n_ | currently mapping the Internet). All of the actions were |
jose_n_ | logged, which was then postprocessed. |
jose_n_ | [slide 10] |
jose_n_ | The overall results are shown in this slide. Briefly, 2804 |
jose_n_ | archives were checked in this process, representing a total |
jose_n_ | of 1426 archives. 166 unique servers were downloaded |
jose_n_ | from, meaning that many act as a mirror server. Only 93 |
jose_n_ | keys were retrieved in the whole process, indicating many |
jose_n_ | authors have many releases of their software. |
jose_n_ | 2799 archives were a success, they verified OK in this |
jose_n_ | process. 5, however, failed to do so. |
jose_n_ | [slide 11] |
jose_n_ | Since these 5 were the really Interesting set for the first |
jose_n_ | stage of analysis, I had to look at them. |
jose_n_ | The first failure was due to a truncated download. A mirror |
jose_n_ | site cut me off prematurely and an OpenSSH ditribution file |
jose_n_ | was cut short, Hence, it didn't verify correctly. |
jose_n_ | The next two were false negatives. I don't know why they |
jose_n_ | failed, but they did. Manual reinspection showed that they |
jose_n_ | were OK. Note that `extract' fails to a FAILURE mode, not |
jose_n_ | a PASS mode. |
jose_n_ | Failures 4 and 5 were legitimate failures. The author was |
jose_n_ | contacted and the results were verified. It turns out that |
jose_n_ | Alex Brennan uploaded a new archive but didn't fix the |
jose_n_ | signature. As you would expect he appreciated the note. |
jose_n_ | [slide 12] |
jose_n_ | Some archives were a complete failure, however. The |
jose_n_ | CMU-SNMP packages were signed using an old key. This |
jose_n_ | old key format is incompatable with current standards |
jose_n_ | based GnuPG tools. I haven't contacted the authors, but is |
jose_n_ | a clear demonstration of a breakdown of the system. No |
jose_n_ | valid keys were ever found. |
jose_n_ | [slide 13] |
jose_n_ | Now we begin the metadata analysis which forms the bulk |
jose_n_ | of this paper. Basically this survey uncovered four |
jose_n_ | weaknesses in the signed archive system: |
jose_n_ | - inline key distribution |
jose_n_ | - a risk of a compromise of the key itself |
jose_n_ | - few signatures on some keys |
jose_n_ | - and a lack of trust in some keys |
jose_n_ | [slide 14] |
jose_n_ | By inline key distribution I refer to the act of placing the |
jose_n_ | PGP key used to sign the archives alongside the archives |
jose_n_ | and signatures themselves. The problem lies in the |
jose_n_ | temptation for the user to download the key as well as the |
jose_n_ | archive. For an attacker, the setup is interesting: basically, |
jose_n_ | when you modify the binary archive, you sign it using a |
jose_n_ | forged key which you also upload to the site. When people |
jose_n_ | download the archive and key pair, the signature will be |
jose_n_ | valid but the archive will not be. Notable abusers of this |
jose_n_ | include the OpenSSH portable team, SSH communications, |
jose_n_ | the Cyrus team, and the GnuPlot team. |
jose_n_ | [slide 15] |
jose_n_ | Next, this study revealed that some keys are at risk of |
jose_n_ | compromise by a determined adversary. Briefly, in the 93 |
jose_n_ | keys analyzed in this study, most were 3 or fewer years old. |
jose_n_ | However, some were as old as 10 years. While an older key |
jose_n_ | has been around longer and established more trust (you |
jose_n_ | know what to expect), it is also around longer for an |
jose_n_ | adversary to attack and factor. This also assumes that the |
jose_n_ | older, original PGP software generates truly safe keys. |
jose_n_ | Given how many weaknesses have been found in |
jose_n_ | cryptographic software in the past 10 years, weaknesses |
jose_n_ | are a likely possibility. Also, the sizes of the keys relates directly to |
jose_n_ | this as well. A shorter key can be factored more easily. |
jose_n_ | Most of the keys used to sign archives were 1024-bit RSA |
jose_n_ | and DSA keys, but some were 512-bit keys. This is now a |
jose_n_ | tractable size for an adversary who has an interest in |
jose_n_ | factoring any RSA encryption key pair (see Simon Singh's |
jose_n_ | Code Book and the resulting challenge). |
jose_n_ | [slide 16] |
jose_n_ | These key ages are shown here graphically. You can see |
jose_n_ | that most are from the year 1999, but many are from prior to that. |
jose_n_ | [slide 17] |
jose_n_ | Shown here is the distribution of the key sizes in bits. |
jose_n_ | Again, most are 1024-bit keys. Both RSA and DSA keys were grouped together for this graph. |
jose_n_ | [slide 18] |
jose_n_ | Lastly, when you correlate the age of keys and their sizes, |
jose_n_ | you can see a generic trend towards larger keys as the |
jose_n_ | software grows to support it. However, 1024-bit keys have |
jose_n_ | always been present and will probably also be present for a |
jose_n_ | long time to come. Perhaps it's time we change the default |
jose_n_ | setting in gpg. |
jose_n_ | [slide 19] |
jose_n_ | The next two points in the analysis of the data retrieved in |
jose_n_ | this study focus on the signatures on the key. The |
jose_n_ | signatures form the basis of the web of trust in the PGP |
jose_n_ | world. With fewer signatures on any key, it becomes harder |
jose_n_ | to verify the veracity of the key (ie does the owner really |
jose_n_ | own that key? is it who you think it is?). The first set of |
jose_n_ | analysis I performed focused in the number of signatures. |
jose_n_ | The average number of signatures per key was 21, while |
jose_n_ | some keys had no signatures and two had 261 signatures |
jose_n_ | per key. These last two are Debian developers and heavily |
jose_n_ | participate in key signing events. |
jose_n_ | [slide 20] |
jose_n_ | The results of that analysis are shown here in this figure. |
jose_n_ | The heavy bias to the left indicates that most keys have |
jose_n_ | only a handful of signatures. Very few have no signatures, |
jose_n_ | but most only have about 5 or 7 signatures. |
jose_n_ | [slide 21] |
jose_n_ | The next step in the analysis of the signatures on the key |
jose_n_ | was to try and establish the owner of the key. This was |
jose_n_ | inspired by a good set of conversations I have had with |
jose_n_ | Niels Provos. Basically, what you do here is you examine |
jose_n_ | the signatures on any given key and try and trace it back to |
jose_n_ | something you know. In this case, I try and tie the keys |
jose_n_ | back to the large, strong set identified by the initial analysis |
jose_n_ | by the folks at Dtype.org. This strong set is a set of keys |
jose_n_ | over 100,000 strong which are a self contained unit. Every |
jose_n_ | key in that set somehow references every other key and |
jose_n_ | nothing external to that set. |
jose_n_ | Of the 93 keys analyzed here, about 2/3 could be mapped to |
jose_n_ | the strong set. 36 keys failed to map back to the strong set |
jose_n_ | (using the key path server at |
jose_n_ | http://the.earth.li/~noodles/pathfind.html and the data from |
jose_n_ | Jason Harris at http://keyserver.kjsl.com/~jharris/ka/). By |
jose_n_ | tying a key back to the strong set we can safely assume |
jose_n_ | that the owner is correctly indicated on the key. |
jose_n_ | While this metric is considerably stronger than the mere |
jose_n_ | analysis of the number of signatures on any key, it relies |
jose_n_ | heavily on the motives of any signer. Some sign only with |
jose_n_ | full knowledge of the key holder and the link between that |
jose_n_ | person and the key, while others sign keys after a brief |
jose_n_ | introduction. This is a classic contrast of a strong trust |
jose_n_ | metric and a weak one. Using the weak links in the chain, |
jose_n_ | one could subvert the system with enough signatures on |
jose_n_ | any forged key. |
jose_n_ | sarnold asked in #qc if it is sufficient to have your key signed by someone in the strong set to be brought into the strong set. the answer is "yes". the set is held together with these signatures. |
jose_n_ | [slide 22] |
jose_n_ | The links of the keys identified in this study to the keys at |
jose_n_ | the center of the strong set (indicated in blue) are shown |
jose_n_ | here. For a better graphic have a look at |
jose_n_ | http://monkey.org/~jose/graphing/csw03/csw03.png . |
jose_n_ | The data from the Noodles path server was used to generate this graphic, and their work on getting this server up recently is greatly appreciated. |
jose_n_ | [slide 23] |
jose_n_ | This foray into the web of trust and its use isn't the first of |
jose_n_ | its kind, but I do think its the first to do a widespread |
jose_n_ | survey of signed archives. The `extract' tool is related to |
jose_n_ | Dug Song's `gzsig' tool and Marius' PGPwrap library. |
jose_n_ | Marius wrote that library after finding the license terms of |
jose_n_ | `GPGme' unacceptable (a typical monkey likes BSD code). |
jose_n_ | The detached signatures are related to the BSD ports tree |
jose_n_ | and the cryptographic checks made by the system. Briefly, |
jose_n_ | any distribution file is hashed using three cryptographic |
jose_n_ | hashes (MD5, SHA-1, and RMD160) to verify the intrigity |
jose_n_ | if the download. Note that this is the system that caught |
jose_n_ | most of the 2002 trojans, not the public keys system. |
jose_n_ | [slide 24] |
jose_n_ | So, while this study has shown that it appears that there |
jose_n_ | are few widespread trojans lying in wait for people in the |
jose_n_ | Internet, there are several weaknesses in the system which |
jose_n_ | can be exploited by an attacker. Ideally, I'd like to continue |
jose_n_ | to perform this check on a rolling basis. Right now I'm |
jose_n_ | looking to find a research partner, I need more bandwidth |
jose_n_ | and I need more storage space. |
jose_n_ | Ideally everyone would be a part of that strong set. Right |
jose_n_ | now there are a number of disconnected islands (note that |
jose_n_ | I'm not in the strong set). This would aid, hopefully, in |
jose_n_ | establishing the veracity of the keys. It would also be nice |
jose_n_ | to see tools incorporated into the PGP model, such as |
jose_n_ | 'extract' or `mutt-sigtrace' |
jose_n_ | (http://www.chaosreigns.com/code/mutt-sigtrace/) which |
jose_n_ | can aid in the checking of keys. Next, more signed archives |
jose_n_ | need to be out there, we need to know that this is what the |
jose_n_ | author intended to upload. And lastly, the world needs a |
jose_n_ | better system. There are simply too many holes in the |
jose_n_ | current one, I think it's time to do better. |
jose_n_ | [slide 25] |
jose_n_ | I really need to acknowledge several people here. Beth let |
jose_n_ | me destroy our cable modem's performance for a couple of |
jose_n_ | days; Marius, Dug, Niels, Alex, and Seth all provided |
jose_n_ | excellent feedback and ideas; the dtype.org people (the |
jose_n_ | participants on the disucssion list, and Jason Harris) have |
jose_n_ | been great in doing their work into the web of trust metrics; |
jose_n_ | the Umeet organizers, thank you for having me speak. |
jose_n_ | A big thanks to Mjesus, sarnold, Oroz, fernand0, and vizard (and so mnay others) for pulling this off. 100x for them! |
jose_n_ | And of course you, I appreciate your interest. Thanks! |
* MJesus sets mode: -m |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
jose_n_ | :) |
sarnold | jose_n_: thanks :) |
sarnold | clap clap clap clap clap |
sarnold | clap clap clap clap clap |
sarnold | clap clap clap clap clap |
sarnold | clap clap clap clap clap |
sarnold | clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap |
tarzeau | clap |
jose_n_ | lemme answer a question or two .. |
viZard | applause applause applause applause |
viZard | applause applause applause applause |
viZard | applause applause applause applause |
viZard | applause applause applause applause |
viZard | applause applause applause applause |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
viZard | applause applause applause applause |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
viZard | applause applause applause applause |
Arador | clap clap clap clap clap clap clap clap clap clap clap clap |
viZard | applause applause applause applause |
sarnold | jose_n_: hummm, the sigtrace website no longer has the signed.db.gz nor keynames.db.gz .. can you help? :) |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
Arador | plas plas plas plas plas pals plas plas plas plas plas plas plas |
jose_n_ | sarnold: are there any active 'projects' to try to map/close those disjoint sets? (speaking of the strong set, dtype.org analysis) |
tarzeau | jose_n_: do you have a homepage with other interesting works? |
jose_n_ | :) so much applause! |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
jose_n_ | sarnold: yes, the dtype.org discussion lists have periodically identified the number of smaller sets and the links within the strong set. bridges, narrow bridges, etc... along with the density of it. some really cool analysis in the archives, a very bright group of people |
viZard | jose_n, how does a Signature and Certificate Autority emisor can validade a home made key and signature with itīs own part of signature? |
jose_n_ | sarnold: i should have those files on my work laptop, i should upload them to my website |
jose_n_ | tarzeau: jose_n_: do you have a homepage with other interesting works? |
viZard | letīs hope i well expressed that |
jose_n_ | yeah, monkey.org/~jose/ has a lot of stuff |
jose_n_ | vizard: tahts a very tough question, but ideally they would be able to answer a handful of important questions: |
jose_n_ | a) is the key protected, ie is it safe from abuse by outsiders, and even insiders |
jose_n_ | b) is the key representative of who it claims to be |
jose_n_ | and c) is the key strongly unique, ie is it difficult to forge for an adversary (this includes attacks on the key itself as well as a forger) |
jose_n_ | those seem to be the central questions answered more or less ad hoc by the web of trust system |
viZard | let me put it this way, i just created a pgp key and a firm, and i want to that key to be validated by letīs say veriSign |
viZard | how do they do that ? if it can be done |
jose_n_ | a) is assumed, b) is enforced at signing time and c) is just plain hoped! |
sarnold | viZard: i don't think verisign does pgp.. they just do x509 |
jose_n_ | vizard: i dont know, i haven't looked at that ... i thought it was just x509 stuff, too |
viZard | ok, thanks Dr. |
jose_n_ | although it looks like x509 is being incorporated into pgp tools ... |
jose_n_ | (at least the commercial tools) |
viZard | say Hello to Chelsea for me :-=) |
jose_n_ | to "bridge the gap" if you will between the trust systems. |
sarnold | huh, i don't know if i like that or not :) |
viZard | Will GnuPG include that standard sooner or later? |
jose_n_ | yeah, i'm kind of leary too, but ... hopefully it wont be messed up ... |
sarnold | jose_n_: x509. how can it _not_ be messed up? :) |
jose_n_ | dunno, i dont keep track of gnupg development (too many politics for me) |
jose_n_ | sarnold: heh .. how true ... so many fiascos |
jose_n_ | by the way the prelim internet map from my house is on my site, as are some of the tools i used in this study. a draft of the paper is here: http://monkey.org/~jose/signed-archives/ |
jose_n_ | thank you again, everyone :) |
fernand0 | thanks to you :) |
jose_n_ | 100x to the umeet organizers, plas plas plplas plas plas plas plas as plas plas plas |
jose_n_ | MJesus: jose, and did you find any more trojans in all files downloaded ? |
jose_n_ | nope, no more trojans. the only way one can be sure is with signatures. |
jose_n_ | it would be nice to go through every archive and look for real subversions (ie uploaded sigs with a forged key) but thats hard to say |
jose_n_ | i mean, some poor quality code sometimes looks like a trojan :-/ |
jose_n_ | tarzeau: jose_n_: that ASxxx map are these devices on the internet doing important stuff? |
jose_n_ | (this is about my internet mapping projects) |
jose_n_ | each AS is an autonomous system, a large network of networks under some administrative control |
jose_n_ | i live in the blue box, AS22909. OARnet, for example, is AS600 (which includes my old school cwru.edu) |
tarzeau | how can i find out in what AS i live? |
jose_n_ | on the cheap: echo your network block (ie 129.22.0.0/16) into a netcat session with rr.arin.net port 43: |
jose_n_ | echo 129.22.0.0/16 | nc rr.arin.net 43 |
jose_n_ | you'll get an answer like this: |
jose_n_ | route: 129.22.0.0/16 |
jose_n_ | origin: AS600 |
jose_n_ | ... |
sarnold | jose_n_: oh how cool! |
jose_n_ | thats how tracepath does it |
jose_n_ | but basically autonomous systems are the units used in global backbone routing, BGP |
jose_n_ | ie "to get to some destination, go to autonomous system X, enter via address a.b.c.d" |
jose_n_ | then the autonomous system has more fine grained routing information |
jose_n_ | its how global routing tables (already millions of bytes large) are so "small" |
jose_n_ | (otherwise they're be much, much lagrer than they already are) |
jose_n_ | http://www.academ.com/nanog/feb1997/BGPTutorial/ <-- good ref slides |
jaxp | jose_n, do you accept silly questions? |
jose_n_ | yes :) |
fernand0 | a las 12 ? |
jaxp | jose_n, how was the monkey.org comprise done? dugsong said it was EPIC, gobbles said it wasn't... |
jaxp | (that's a silly one) |
jaxp | s/comprise/compromise/ |
jose_n_ | *hrm* not really my place to say, but the official stance is yeah, irc client. |
jose_n_ | we have full logs of the whole thing via some of our tools at arbor |
jaxp | jose_n, thanks for the answer :) |
jose_n_ | gobbles ... is gobbles. |
jose_n_ | we know who it was, we know what happened and ... *shrug* it sucked. |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
sarnold | viZard: some loser :) |
fernand0 | do you know what is the next talk about sarnold ? |
fernand0 | hehe |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
fernand0 | hehe |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
raul | clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap clap |
fernand0 | plas plas plas plas plas plas plas plas |
fernand0 | plas plas plas plas plas plas plas plas |
fernand0 | plas plas plas plas plas plas plas plas |
fernand0 | plas plas plas plas plas plas plas plas |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
MJesus | clap clap clap clap clap clap clap clap clap clap |
jose_n_ | :) thanks folks, its an honor to present in this company |
fernand0 | thank you jose_n, and thank you to all for comming |
sarnold | bonjour bug! :) |
jaxp | jose_n, thanks to you :) |
MJesus | sarnold talk in 90 minuts, isn't ? |
sarnold | MJesus: si |
fernand0 | time to have dinner |
sarnold | MJesus: maybe talks shouldn't be three hours apart! |
fernand0 | and send to bed the daughther |
fernand0 | hehe |
fernand0 | mmmm |
MJesus | :))) |
fernand0 | so |
fernand0 | you are proposing we have no dinner? |
sarnold | fernand0: better than me sitting at work for 1.5 hours on a sunday that I don't need to be here.... :) |
fernand0 | you are true |
fernand0 | maybe for your talk, next year |
MJesus | next umeet, two hours ... |
sarnold | fernand0 :) |
fernand0 | Sundays are not good days to stay alone in front of the computer |
fernand0 | you should have compelled the organizers to put your talk on a labor day |
sarnold | fernand0: actually, i asked for sunday, so I wouldn't have to turn down any work requests.... |
fernand0 | ooooooooh |
will | yes, an excuse to convince the boss to be one day out |
fernand0 | hehe |
fernand0 | see you later |
szicso | re |
fernand0 | see you later friends |
MJesus | see you fernnad0: at 21 UTC |
unimauro | BRavo |
viZard | uff, i finished the translation :-) |
MJesus | clap clap clap clap clap clap clap clap clap clap |
jose_n | vizard++ |
viZard | applause for Arador who translated the last part to french |
jose_n | arador++ |
szicso | :) |
viZard | :-) |
viZard | Dr. say hello to Chelsea for me :-) she is invited to .do anytime |
jose_n | will do :) |
szicso | which timezone is the UTC?:) |
viZard | you can com too ;-) |
viZard | you can come too ;-) |
Session Close: Sun Dec 15 15:40:12 2002 |