Most of the VPN topics we cover translate easily and directly to other Unix systems. Some small difference are OS specific. You don't enable ip forwarding with/proc on solaris, for example, but the software configuration, routing examples, etc, are the same.
We discuss PPTP s.t. you can communicate with PPTP-only Windows clients. You can run IPSec software on more recent versions of Windows, however describing how to do so would probably increase the size of the book by several hundred pages, not counting the fact that we'd have lost some serious sanity in the process.
So when cross platform == unix-like systems, this book does it for you. When cross platform == non unix, you're on your own.
No offense, but anyone still relying on pty-redir should really use a more recent version of pppd which has the '-p' option to create a pty on it's own.
The ppp over (ssh/ssl) stuff in the book is much more complete, allowing you to make more than one connection, doesn't rely on best-guess 'sleep X' timeouts, and walks you through setting up ssh securely s.t. it can only be used to create the VPN, and doesn't require logging in as root from either endpoint.
I taught a number of programming courses at Northwestern University, and have offered group projects as an option for clasess. Those that wanted to do group projects - and I encouraged it - were allowed to do so, and said projects needed to be proportionally more complex than those submitted by individuals.
Part of the writeup for a group project would include a brief (1-2 line) explanation of who did what part. Knowing this was part of the material turned in, it encouraged the loafers to make sure they did enough to claim part of the project. I also stressed that they needed to know how all the pieces fit together, not just understand their standalone part.
The final exam for the class always was in a similar format as the midterms, with sample code to write, comment on, correct, questions about the topics covered, etc. This was worth 50% of the grade. The last 50% of the grade consisted of the following questions:
How did your program do what it did, explaining in some detail your sections of it.
Describe in detail the problems you had with your part of the project.
What do the following snippets of code do, and where are they found in your program.
The snippets would be taken from two sections of the actual project code, one which they (claimed) to have written, and one which they hadn't.
I was extreemly pleased to see that, in fact, most folks had divided up the work evenly, and had a good understanding of the project as a whole. Now this could have been due to other members of the team explaining it to them, rather then them figuring out the other participant's code manually, but isn't that what you'd do in the real world?
Those folks that could explain problems they'd encountered often noted that they asked for help from other members of the team. By this point in the class, I could already recognize the coding style of each student anyway, but I really appreciated the honesty, and how they did work together to produce something.
Yes, there were some (I'd say 5%) that were tricked up on the exam and showed that they didn't actually write much of the code, nor understand it. However overall folks did a good job acting like they would in an ideal group coding environment.
The only problem I had with group projects was with Thurston Howell (or at least that's what I called him in my mind, due to his attitude and voice) who had one of the classic coder failings. He got so caught up with getting the perfect interface -- being able to use emacs-style data entry editing abilities and such -- that he never got any of the backend stuff even started. Those in his group didn't know where to go, since they had nothing to plug their code into. Here's where a normal group may have a manager who could step in and help out, and they didn't quite have the real-world mentality that would have allowed them to come to me and tell me what was holding them up. But other than this one incident, group projects have always been an excellent thing.
Sorry to hear about the mix of english/portugese. The original authors don't do the translations. If we did then we'd need to rely on Babelfish anyway, and who knows how nasty it'd end up. Hmmn, let's try a random line from chapter 10:
English:
Most script
kiddies will not have the attention span or coding skills to
successfully trojan all the programs that are necessary to hide themselves.
Portugese via Babelfish: A maioria de kiddies do certificado não terão as habilidades da extensão ou do coding da atenção com sucesso a Trojan todos os programas que são necessários para se esconder.
Back to English: The majority of kiddies of the certificate nao terao the abilities of extensao or coding of atencao successfully the Trojan all the necessarios programs that sao to hide itself.
In case you haven't noticed, the media doesn't like making distinctions that may confuse them or their readers. Though we may think the subversion of 'hacker' into 'cracker/attacker/script kiddie/etc' is a genuine loss, they don't understand. And I don't know how to fix it, especially since most publishers aren't willing to make the distinction either.
Slashdot Mirror
Most of the VPN topics we cover translate easily and directly to other Unix systems. Some small difference are OS specific. You don't enable ip forwarding with /proc on solaris, for example, but the software configuration, routing examples, etc, are the same.
We discuss PPTP s.t. you can communicate with PPTP-only Windows clients. You can run IPSec software on more recent versions of Windows, however describing how to do so would probably increase the size of the book by several hundred pages, not counting the fact that we'd have lost some serious sanity in the process.
So when cross platform == unix-like systems, this book does it for you. When cross platform == non unix, you're on your own.
No offense, but anyone still relying on pty-redir should really use a more recent version of pppd which has the '-p' option to create a pty on it's own.
The ppp over (ssh/ssl) stuff in the book is much more complete, allowing you to make more than one connection, doesn't rely on best-guess 'sleep X' timeouts, and walks you through setting up ssh securely s.t. it can only be used to create the VPN, and doesn't require logging in as root from either endpoint.
Part of the writeup for a group project would include a brief (1-2 line) explanation of who did what part. Knowing this was part of the material turned in, it encouraged the loafers to make sure they did enough to claim part of the project. I also stressed that they needed to know how all the pieces fit together, not just understand their standalone part.
The final exam for the class always was in a similar format as the midterms, with sample code to write, comment on, correct, questions about the topics covered, etc. This was worth 50% of the grade. The last 50% of the grade consisted of the following questions:
The snippets would be taken from two sections of the actual project code, one which they (claimed) to have written, and one which they hadn't.
I was extreemly pleased to see that, in fact, most folks had divided up the work evenly, and had a good understanding of the project as a whole. Now this could have been due to other members of the team explaining it to them, rather then them figuring out the other participant's code manually, but isn't that what you'd do in the real world?
Those folks that could explain problems they'd encountered often noted that they asked for help from other members of the team. By this point in the class, I could already recognize the coding style of each student anyway, but I really appreciated the honesty, and how they did work together to produce something.
Yes, there were some (I'd say 5%) that were tricked up on the exam and showed that they didn't actually write much of the code, nor understand it. However overall folks did a good job acting like they would in an ideal group coding environment.
The only problem I had with group projects was with Thurston Howell (or at least that's what I called him in my mind, due to his attitude and voice) who had one of the classic coder failings. He got so caught up with getting the perfect interface -- being able to use emacs-style data entry editing abilities and such -- that he never got any of the backend stuff even started. Those in his group didn't know where to go, since they had nothing to plug their code into. Here's where a normal group may have a manager who could step in and help out, and they didn't quite have the real-world mentality that would have allowed them to come to me and tell me what was holding them up. But other than this one incident, group projects have always been an excellent thing.
English:
Most script kiddies will not have the attention span or coding skills to successfully trojan all the programs that are necessary to hide themselves.
Portugese via Babelfish:
A maioria de kiddies do certificado não terão as habilidades da extensão ou do coding da atenção com sucesso a Trojan todos os programas que são necessários para se esconder.
Back to English:
The majority of kiddies of the certificate nao terao the abilities of extensao or coding of atencao successfully the Trojan all the necessarios programs that sao to hide itself.
Yeah, that's bad.
Divining who made said requirements is left as an exercise to the reader.
In case you haven't noticed, the media doesn't like making distinctions that may confuse them or their readers. Though we may think the subversion of 'hacker' into 'cracker/attacker/script kiddie/etc' is a genuine loss, they don't understand. And I don't know how to fix it, especially since most publishers aren't willing to make the distinction either.
You can't win against the publisher/editor. We tried. We fought for almost the whole time we were writing. We lost.
See our take on it at hackers_vs_crackers on our website.
Trust me, we were not pleased either.