Why can't SMTP be secured? What's that you say? SMTP AUTH? That only prevents a specific subset of malicious behavior. Likewise with DNS. "Secured" is a very vague term. There are lots of attacks against different portions of the DNS (root and GTLD servers, authoritative servers for 2nd-level domains, local resolvers, and stub resolvers), and the security measures required are of course going to vary depending on what components you want to protect and from what flavors of attack.
Is BIND really that pathetic, or are they just not using it correctly?
The attack in question is orthogonal to the software running on the servers used in the attack. (I'm sure some of them were running BIND, though.) It's certainly a configuration problem, no matter what software is involved.
I was actually going to say something very similar, and then I realized that I use telnet over netcat for certain purposes, because telnet notifies me when it actually connects. However, a couple minutes ago I realized I was being an idiot, because 'nc -v' does the same thing.
Also, if you haven't already, check out nmap-ncat.
Hear, hear. My vote is definitely for Python. It's my language of choice in general, but it also has a lot of qualities that make it great for introducing to programming. A few of my favorites:
helloworld is literally a one-liner -- don't have to wrap it in a function (or, god forbid, a class *cough*Java*cough*) or import any I/O libraries
The syntax is ludicrously simple; eliminates bugs like "if(foo); {do_stuff();}"
The standard library is substantial and reasonably well-documented
After students have the basics (variables, conditionals, loops, functions, etc.), you can introduce OOP and/or functional programming
The introductory programming course at my alma mater (a rigorous four-year math/science/engineering school) has been taught in Java for years, but it's being rewritten in Python. Go Python!
I was a grader last semester for an upper-division operating systems course that I'd taken a couple semesters earlier. Here's my implementation of a certain function:
int lock_do_i_hold(struct lock *lock) { return curthread == lock->holder; }
Here's how it was implemented in one of the assignments I was grading:
int lock_do_i_hold(struct lock *lock) { /* if am holding the lock to this thread */ if (lock->curthread == curthread) { /* returns true if the lock is being held */ return 1; } else { /* false if not */ return 0; } }
It took great strength of will to keep my grading comments civil.
Except that with BuddyZoo, you had to upload your buddy list to the site, so it could only calculate based on the data that users voluntarily uploaded. This site, on the other hand, was done by AOL and therefore has access to ALL buddy lists!
True, but BZ also does more interesting things with the data (cliques, visualization, etc).
An interesting note on BuddyZoo and degrees of separation -- it was created by one of the creators of Synapse, the other co-creator being the creator of thefacebook.com, with whom I worked on a small project several years ago.
He's also a high school acquaintance of a good friend of mine from college:P
Having recently graduated from a rather rigorous undergraduate institution with a degree in CS, and planing on going into the Ph.D. program at another well-respected school this fall, I find myself taking the "science" part of "computer science" pretty seriously. Somebody more famous than me once said, "Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes." That might not be strictly true, but it's the right idea. In my mind, being a computer scientist implies that one is engaged in real scientific research. A degree in computer science should come with an understanding of the history and theory behind the actual systems we use every day, an awareness of the open issues in the field, etc.
Somehow I get the idea (and feel free to correct me if you know better) that a "CS" degree from DeVry might not match my understanding of the term. That's not to say that there isn't a place for this sort of education -- I'm all in favor of competent entry-level programmers, web designers, DBAs, whatever it is that DeVry actually trains one to be. But to use a (probably flawed) analogy to other disciplines, this sort of education is to CS as auto repair is to engineering. It takes a not insignificant amount of skill and knowledge to be a decent auto mechanic; I'm not trying to knock DeVry graduates. But I wouldn't expect a mechanic to be able to do fundamentally new things in the space of automotive design any more than I would expect a DeVry CS major to do real computer science.
(Yeah, I have some idea of how pretentious and condescending that sounds. Go ahead and mod me down.)
Does anybody have a source for the "BitTorrent is the highest-volume application-level protocol on the 'Net" statistic besides a single slide from a year-old marketing presentation? I'm willing to give the benefit of the doubt, but I would also like to see the data confirmed by a more reputable, less biased source.
It seems like somebody at Sony BMG doesn't understand the threat model. Preventing 99% of consumers from circumventing the DRM on the physical media does pretty much no good, because as soon as a few enterprising individuals do manage to circumvent said DRM, there will be DRM-less digital copies on $P2P_NET_OF_THE_DAY, and once that happens, nobody who wants an illicit copy of the media in question will do it by trying to rip from CD. Seems like a no-brainer to me, but maybe Sony BMG is looking at it from some other angle.
Schmidt: Transparency is not necessarily the only way you achieve security. For example, part of the encryption algorithms are not typically made available to the open source community, because you don't want people discovering flaws in the encryption.
I hope he didn't really mean that; I had a fairly good opinion of him, but that statement is (IMO) a pretty serious misunderstanding of The Way Things Should Be. We (the security-loving Internet elite) want maximal transparency for all of our systems, cryptographic and otherwise, so problems are found and fixed... right?
Ever hear the saying, "given enough time a room full of monkeys could type out Shakespeare"?
Never in my life have I heard that saying. Not once, in all of my years on the Net, have I come across any reference to typing monkeys. What a concept!
"ATM machine"!? "PIN number"!?!? Really, I would've expected the slashdot crowd to be the last ones to perpetrate these redundancies. Among my geek friends, we always rag on one another when one of us says something like that...
I find it hard to believe you even attempted to read the article when you complain about no links to the authors, yet the sidebar contains both links to the authors and mailto:s pointing to each of them.
If the client is coded st00pid like it is now, then yes. (No insult to the people that actually developed this... it's a great idea, and the implementation is reasonable, but not how I would've done it.)
The problem is that a new socket is created for each knock, so you have a different address (=IP/port pair) for each knock. If the knocks from one access attempt all came from the same port, we'd be golden.
So how do we fix this? Well, we could try binding to the same (though random between executions) high port for each knock. I haven't experimented enough to see if this can be done reliably on a busy system, but it might be possible.
Also, the daemon would have to take the source port into account for verifying access attempts.
These ESA folks show a stunning lack of basic network knowledge. You'd think that if they were trying to apply a technical solution (net robot) they might have some clue, but this makes you wonder...
I use python for everything more complex than a couple lines of shell. ~/proj/assorted_hacks/ contains stuff like a parser for libpcap dumps of AIM sessions, a script that pulls quotes out of a quotefile, a script which (using a module I wrote to parse a certain flavor of XML document) pretty-prints my bookmark URLs... I've also written a converter from the contact list format of my IM client of choice to '.blt', and at work I've written a substantial amount of CGI and some moderately tricky security-related scripts.
Strengths: Much, much nicer to look at than perl; think "executable pseudocode" as opposed to "executable line noise". Object oriented if you want it to be. Very easy to learn, at least for someone with my background. (It took me one workday to go through the tutorial and play enough to have a decent clue what was going on; at the time I had two semesters of undergrad CS classes under my belt.) Has a good deal of the "do what I mean" quality. Development is typically very fast.
Weaknesses: The canonical python weakness is speed, or lack thereof. I don't notice. If you're coding up something performance-intensive, don't use python. Some people don't like the indentation-as-syntax thing.
It's worth learning another language because it'll take you just a few hours, and it's really fun.
Neverwinter Nights. When they say that there is a Mac port on the way, I think they're lying;)
Oh, and on a completely unrelated note, why is every single newspost I see about this convinced that there are only 4 maps? There are actually 5: 2 DM (one outdoors (shiiiiny), one indoors), 2 CTF (CTF-Citadel and CTF-Orbital2 or something like that, space-station-esque), and one BR.
I guess I can understand the benefits (as minor as they may be relative to price), but the thing that bothers me the most is why does it take 4 years and NSF funds to come up with something that seems so obvious?
First, a wee bit of background. The research is the thesis project of An-I Wang, a grad at UCLA. One of his advisors is Geoff Kuenning, who teaches at my school, Harvey Mudd College. I went to Geoff's presentation here.
If you'd seen the performance statistics, you wouldn't be calling the benefits "minor." It stomps all over XFS, ext2, and ReiserFS in pretty much every test, and as opposed to ramfs actually has the capability to store more than what fits in RAM.
Also, a big part of what they did was matching the FS behavior to typical usage patterns. All small files are in RAM because they are the most frequently used. Most large files are read mostly-sequentially: in the example of MP3s, tags are read from the last few dozen bytes, then the player application reads the rest of the file straight from the beginning to the end. Also, most large files (media being the main example) are written once and rarely or never modified.
So, my point is, Conquest is designed to perform optimally for a desktop user. That was a nontrivial task, and while it seems an obvious idea in retrospect, it seems plain to me that there was in fact a substantial amount of research that went into this design.
I'm a sophomore CS major at Harvey Mudd College. (For those of you who don't know, Mudd is a small math/science/engineering school in Claremont, CA; we're part of the same consortium as Pomona College and Claremont Mckenna College.) I was a straight-A student in high school, even taking all the AP and honors courses that I could. My cumulative GPA at Mudd is 2.76. The grade-inflation trend elsewhere is almost a running joke in Mudd circles; I very quickly learned that getting an A in a course actually requires significantly above-average effort. You get C's for average effort, which as far as I know is the way the system was originally designed. When Mudders see stories like these, we just laugh bitterly. There's some satisfaction to knowing that one has actually earned a good grade, but at the same time, being a B/C student puts one in a different light than being an A/B student. More A's given to mediocre students at schools like Duke means that above-average students at schools like Mudd have a harder time of it in terms of grad school, etc.
Well, the rough outline of this document has been posted already, but check it out. A lot of it is bureaucratese, but there are some interesting bits. We (my labmates and I) started looking into this topic last summer, and found data on one of our HDs that was ~2 years old (cached search results for the IE4 installer). The drive had been through at least one erasure and OS install, and the machine had been in fairly regular use since then.
Slashdot Mirror
See the first few graphics in kc claffy's presentation to ARIN. Poke around caida.org for more tasty data.
I refer you to Gabe's experience with such.
Why can't DNS be secured?
Why can't SMTP be secured? What's that you say? SMTP AUTH? That only prevents a specific subset of malicious behavior. Likewise with DNS. "Secured" is a very vague term. There are lots of attacks against different portions of the DNS (root and GTLD servers, authoritative servers for 2nd-level domains, local resolvers, and stub resolvers), and the security measures required are of course going to vary depending on what components you want to protect and from what flavors of attack.
Is BIND really that pathetic, or are they just not using it correctly?
The attack in question is orthogonal to the software running on the servers used in the attack. (I'm sure some of them were running BIND, though.) It's certainly a configuration problem, no matter what software is involved.
disallow non-expected source IP addresses from interfaces in the first place
p df 3 /papers/park.pdf
This is much easier said than done. Cf.:
http://www.lasr.cs.ucla.edu/save/save_to_infocom.
http://www.lasr.cs.ucla.edu/classes/239_1.spring0
more proof
You misspelled "evidence".
I was actually going to say something very similar, and then I realized that I use telnet over netcat for certain purposes, because telnet notifies me when it actually connects. However, a couple minutes ago I realized I was being an idiot, because 'nc -v' does the same thing.
Also, if you haven't already, check out nmap-ncat.
- helloworld is literally a one-liner -- don't have to wrap it in a function (or, god forbid, a class *cough*Java*cough*) or import any I/O libraries
- The syntax is ludicrously simple; eliminates bugs like "if(foo); {do_stuff();}"
- The standard library is substantial and reasonably well-documented
- After students have the basics (variables, conditionals, loops, functions, etc.), you can introduce OOP and/or functional programming
The introductory programming course at my alma mater (a rigorous four-year math/science/engineering school) has been taught in Java for years, but it's being rewritten in Python. Go Python!I was a grader last semester for an upper-division operating systems course that I'd taken a couple semesters earlier. Here's my implementation of a certain function:
/* if am holding the lock to this thread */
/* returns true if the lock is being held */
/* false if not */
int lock_do_i_hold(struct lock *lock)
{
return curthread == lock->holder;
}
Here's how it was implemented in one of the assignments I was grading:
int
lock_do_i_hold(struct lock *lock)
{
if (lock->curthread == curthread)
{
return 1;
}
else
{
return 0;
}
}
It took great strength of will to keep my grading comments civil.
BuddyZoo
Having recently graduated from a rather rigorous undergraduate institution with a degree in CS, and planing on going into the Ph.D. program at another well-respected school this fall, I find myself taking the "science" part of "computer science" pretty seriously. Somebody more famous than me once said, "Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes, or chemistry is about beakers and test tubes." That might not be strictly true, but it's the right idea. In my mind, being a computer scientist implies that one is engaged in real scientific research. A degree in computer science should come with an understanding of the history and theory behind the actual systems we use every day, an awareness of the open issues in the field, etc.
Somehow I get the idea (and feel free to correct me if you know better) that a "CS" degree from DeVry might not match my understanding of the term. That's not to say that there isn't a place for this sort of education -- I'm all in favor of competent entry-level programmers, web designers, DBAs, whatever it is that DeVry actually trains one to be. But to use a (probably flawed) analogy to other disciplines, this sort of education is to CS as auto repair is to engineering. It takes a not insignificant amount of skill and knowledge to be a decent auto mechanic; I'm not trying to knock DeVry graduates. But I wouldn't expect a mechanic to be able to do fundamentally new things in the space of automotive design any more than I would expect a DeVry CS major to do real computer science.
(Yeah, I have some idea of how pretentious and condescending that sounds. Go ahead and mod me down.)
What is this "power the machine off" you speak of? ;)
Does anybody have a source for the "BitTorrent is the highest-volume application-level protocol on the 'Net" statistic besides a single slide from a year-old marketing presentation? I'm willing to give the benefit of the doubt, but I would also like to see the data confirmed by a more reputable, less biased source.
It seems like somebody at Sony BMG doesn't understand the threat model. Preventing 99% of consumers from circumventing the DRM on the physical media does pretty much no good, because as soon as a few enterprising individuals do manage to circumvent said DRM, there will be DRM-less digital copies on $P2P_NET_OF_THE_DAY, and once that happens, nobody who wants an illicit copy of the media in question will do it by trying to rip from CD. Seems like a no-brainer to me, but maybe Sony BMG is looking at it from some other angle.
Schmidt: Transparency is not necessarily the only way you achieve security. For example, part of the encryption algorithms are not typically made available to the open source community, because you don't want people discovering flaws in the encryption.
I hope he didn't really mean that; I had a fairly good opinion of him, but that statement is (IMO) a pretty serious misunderstanding of The Way Things Should Be. We (the security-loving Internet elite) want maximal transparency for all of our systems, cryptographic and otherwise, so problems are found and fixed... right?
Ever hear the saying, "given enough time a room full of monkeys could type out Shakespeare"?
Never in my life have I heard that saying. Not once, in all of my years on the Net, have I come across any reference to typing monkeys. What a concept!
"ATM machine"!? "PIN number"!?!? Really, I would've expected the slashdot crowd to be the last ones to perpetrate these redundancies. Among my geek friends, we always rag on one another when one of us says something like that...
I find it hard to believe you even attempted to read the article when you complain about no links to the authors, yet the sidebar contains both links to the authors and mailto:s pointing to each of them.
If the client is coded st00pid like it is now, then yes. (No insult to the people that actually developed this... it's a great idea, and the implementation is reasonable, but not how I would've done it.)
The problem is that a new socket is created for each knock, so you have a different address (=IP/port pair) for each knock. If the knocks from one access attempt all came from the same port, we'd be golden.
So how do we fix this? Well, we could try binding to the same (though random between executions) high port for each knock. I haven't experimented enough to see if this can be done reliably on a busy system, but it might be possible.
Also, the daemon would have to take the source port into account for verifying access attempts.
>Infringement Detail:
...
>IP Port: 21
>Network: FTP
>Protocol: FTP
These ESA folks show a stunning lack of basic network knowledge. You'd think that if they were trying to apply a technical solution (net robot) they might have some clue, but this makes you wonder...
I use python for everything more complex than a couple lines of shell. ~/proj/assorted_hacks/ contains stuff like a parser for libpcap dumps of AIM sessions, a script that pulls quotes out of a quotefile, a script which (using a module I wrote to parse a certain flavor of XML document) pretty-prints my bookmark URLs... I've also written a converter from the contact list format of my IM client of choice to '.blt', and at work I've written a substantial amount of CGI and some moderately tricky security-related scripts.
Strengths: Much, much nicer to look at than perl; think "executable pseudocode" as opposed to "executable line noise". Object oriented if you want it to be. Very easy to learn, at least for someone with my background. (It took me one workday to go through the tutorial and play enough to have a decent clue what was going on; at the time I had two semesters of undergrad CS classes under my belt.) Has a good deal of the "do what I mean" quality. Development is typically very fast.
Weaknesses: The canonical python weakness is speed, or lack thereof. I don't notice. If you're coding up something performance-intensive, don't use python. Some people don't like the indentation-as-syntax thing.
It's worth learning another language because it'll take you just a few hours, and it's really fun.
Neverwinter Nights. When they say that there is a Mac port on the way, I think they're lying ;)
Oh, and on a completely unrelated note, why is every single newspost I see about this convinced that there are only 4 maps? There are actually 5: 2 DM (one outdoors (shiiiiny), one indoors), 2 CTF (CTF-Citadel and CTF-Orbital2 or something like that, space-station-esque), and one BR.
First, a wee bit of background. The research is the thesis project of An-I Wang, a grad at UCLA. One of his advisors is Geoff Kuenning, who teaches at my school, Harvey Mudd College. I went to Geoff's presentation here.
If you'd seen the performance statistics, you wouldn't be calling the benefits "minor." It stomps all over XFS, ext2, and ReiserFS in pretty much every test, and as opposed to ramfs actually has the capability to store more than what fits in RAM.
Also, a big part of what they did was matching the FS behavior to typical usage patterns. All small files are in RAM because they are the most frequently used. Most large files are read mostly-sequentially: in the example of MP3s, tags are read from the last few dozen bytes, then the player application reads the rest of the file straight from the beginning to the end. Also, most large files (media being the main example) are written once and rarely or never modified.
So, my point is, Conquest is designed to perform optimally for a desktop user. That was a nontrivial task, and while it seems an obvious idea in retrospect, it seems plain to me that there was in fact a substantial amount of research that went into this design.
I'm a sophomore CS major at Harvey Mudd College. (For those of you who don't know, Mudd is a small math/science/engineering school in Claremont, CA; we're part of the same consortium as Pomona College and Claremont Mckenna College.) I was a straight-A student in high school, even taking all the AP and honors courses that I could. My cumulative GPA at Mudd is 2.76. The grade-inflation trend elsewhere is almost a running joke in Mudd circles; I very quickly learned that getting an A in a course actually requires significantly above-average effort. You get C's for average effort, which as far as I know is the way the system was originally designed. When Mudders see stories like these, we just laugh bitterly. There's some satisfaction to knowing that one has actually earned a good grade, but at the same time, being a B/C student puts one in a different light than being an A/B student. More A's given to mediocre students at schools like Duke means that above-average students at schools like Mudd have a harder time of it in terms of grad school, etc.
Well, the rough outline of this document has been posted already, but check it out. A lot of it is bureaucratese, but there are some interesting bits. We (my labmates and I) started looking into this topic last summer, and found data on one of our HDs that was ~2 years old (cached search results for the IE4 installer). The drive had been through at least one erasure and OS install, and the machine had been in fairly regular use since then.