Re:The new compression method is pretty fantastic.
on
OpenSSH 4.2 released
·
· Score: 2, Informative
SSH compression is about 12 to 1. Even with improvements, it probably won't compete with NX compression, which is 60 to 1, and already makes X useable over a cable modem.
Kerberos is not secure / much less secure than PKI
on
OpenSSH 4.2 released
·
· Score: 1
Kerberos uses symmetric encryption. While unlike regular logins it doesn't sent password hashes across the network (just tokens encrypted with those hashes, that people who entered the right password can decrypt), it's still not secure in that it keeps credentials on the KDC. A compromise of the KDC therefore allows an attackers to pretend to be anyone they want.
No modern authentication system should store secrets on the server, This is the reason we have PKI - we store the certificates on the server, and each user is the only person who has their private key. This means:
- A compromise of the authentication server gives the attacker...public keys, that they could get from anywhere.
- It's more easy to hold a user responsible to accidential or deliberate disclosure of their credentials, because only the user has those credentials.
Kerberos was secure when it was invented, But there's no reason my bank needs to store my credentials on their servers, thank you very much, and there's no reason I feel like letting them be responsible for the security of my account any more than necessary. It's popular because of the single sign on aspect (users get an initial token at login time they can use to auth to NFS servers, mail servers, CVS/SVN servers, web servers, etc without needing to retype their password, at least till then login token expires). And lots of apps - every client/server for web, mail, CVS, SVN, NFS, etc in RHEL 4 for example, supports it. But ssh-agent is almost as convenient for SSO - I just wish more apps accepted digital signatures for logon.
So yeah, I can see why you'd use kerberos for network app support, but it's a poor second cousin to PKI when it comes to security.
Re:Oh, you think I'm the one who called it that?
on
All About Geocaching?
·
· Score: 1
The link I referred to was Google 'akamai geocaching'.
If you search for NT on Google you might get lots of articles about Windows NT or the Northern Territory in Australia, or other uses of 'NT'. That doesn't make one of them wrong. Nor does it mean I should come up with an OS and call it NT.
Re:Oh, you think I'm the one who called it that?
on
All About Geocaching?
·
· Score: 1
Why would you tell me to pick another word?
I didn't. That was you as in 'vous'. The collective one. I just wanted to post on top of the thread.
When I Google for geocaching, the first page is an article about the thing that's being talked about here, and it says the 'first thing I thought of was Akamai'. I expected you to do a little more research.
People have been using geocaching as a type of caching since before 2000. I guess Akamai are tired of people using their term. A technical site with an article that promises to be all about, say, DNS, should say 'road DNS' if they mean 'Driving Near Stuff'.
Cool. You train people with the cpaacity to learn. I employ people who can work straight away and have already demonstrated a capacity to learn.
If you want to work in a conservative organization you should get your advice from someone else. Perhaps a Minesweeper Consul.. er.. Microsoft Certified Systems Engineer.
And if I sound slightly annoyed there, that's because I expected an article and knowledgable comments on configuring Squid and BIND to perform geocaching. Not this unrelated random stuff.
It's like I decided to call the act of watching television 'dressing myself'.
Geocaching is transparently caching an origin server so that the content is being served from somewhere close to the person seeking it. It's what Akamai do for Microsoft and Yahoo and Apple etc. with their Linux boxes.
If I was looking for a Red Hat or general Linux system administrator, I'd look for evidence of Red Hat or general Linux skills. Which would include certifications I think are relevant, but also relevant experience, personal style, and other criteria. I am certainly not exclusively looking for RHCEs, I'm looking for someone with skills.
>>It seems pretty clear that you have a very limited range of experience.
>Okaaay, I think this discussion has pretty well run its course but there are a couple points I'll still respond to:
You've made a lot of statements that indicate that you're not familiar with large, conservative organizations. You haven't stated why you think a vendor with a few hundred thousand clients gives inferior technical advice than some random website. You still haven't responded with any techical justification for your LDAP claim - strong opinions without technical backing are another indication that you don't have much experierience in justifying your opinions and actions, again which makes me think you don't have a diverse range of experience in large organizations.
>>by the time you realize they've been boasting about their credentials, you've hired them.
>This is why organizations often have a trial period for new employees. Perhaps in your wide range of experience you've heard of the concept.
So you'd rather ignore skills proven by certification tests, hire someone for a trial period, pay them, fire them, and re-hire?
> LVM on root is brittle.
Again, I think this depends on the training. If something snaps in half, it might not be brittle, it might just have had sufficient force applied.
I suppose this is where our experience diverges the most. I see writing glue code as a major part of the sysadmin's job.
I know what glue code is. I don't consider a custom pam module to be it, though. You'll get better results by hiring a developer rather than a system administrator. And you'll get better system administrators by hiring someone that doesn't try and be a developer.
>I don't pay people to repetitively perform tasks they could automate.
Yeah, same here. So, as I asked before, in your systems rollout example, do you think training on how to do that could be useful?
>> easier to get a friend you worked with to lie on a resume
> This isn't high school. If you don't know the material you claim it becomes real obvious real fast.
Er, people don't use references to show off knowledge, they use it to show off experience. And people can indeed be easily fooled about experience. A certification is proof that you passed a test: whether that test provided the skills needed for the role if up to the employer to decide. It's easier to verify than experience.
> You might be able to fool me, maybe, but you can't fool the computer when the time comes to do your work.
What you've said is true, but by the time you realize they've been boasting about their credentials, you've hired them.
So maybe do some testing as part of your interview process? Sure, but do you think it would be more comprehensive than a practical exam?
>> Again, I'd consider NIS obsolete when I studied it three years ago, but people nevertheless still use it today. The fact you seem to think it's dead is indicate of a lack of experience in conservative (read: large) environments.
> Yeah, just like like people still use Cobol and Fortran.
No, NIS is a lot more popular. Alas. More like Sendmail. Like you I wish it'd go away, but we're training people for the real world. not an idealized technical heaven. I wish people used PKI rather than Kerberos, which I don't consider secure. But they do, and they need to know how.
> But hey, you're right: I work for a tiny organization, only 7,000 employees.
One organization doesn't represent a sufficient sample size. You know how your environment works, perhaps very well.
>> Red Hat are futher ahead of most distros when it comes to security, they're the first with a firewall enabled by default, the first with a DAC system, and the first to Kerberize every major service. Correct me if I'm wrong.
> Okay, you're wrong. During the past five years, the number of security incidents per installed server has been lower for Debian, Slackware and FreeBSD among others.
According to whom? And you're counting the number of security incidents - which I assume you mean as intrusions, rather than its proper meaning, events - which is meaningless. Perhaps you mean patches? In that case, you should probably be using Windows, which has lesss patches released for it than most Linux distros.
> But this is an attempt at a straw-man argument. The topic isn't selecting a secure distro, its selecting competent staff. Lets get back to it, shall we?
Sure, I only reponded to some out-of-band criticism of Red Hat. To finish off the topic, though, you need to tell me what the problem is with their recommended LDAP setup.
>> Teaching a lowest common denominator course would be stupid. We're aiming to teach RHEL, not Solaris.
> I could not have given a better reason for discounting the Red Hat cert if I tried. I'm not interested in hiring a Red Hat Administrator. I'm not even interested in hiring a Linux Administrator. I'm interested in hiring a System Administrator with skill in a broad range of systems, including Linux.
Do you really think one certification could measure all those things? If so, I'm very surprised. If not, then why criticise Red Hat for focusing on Red Hat?
> What you characterize as "teaching a lowest common denominator" I see as "teaching the fundamentals." Someone well grounded in the fundamentals is vastly more useful to me than a Red Hat specialist -- he comes in ready to learn our system while the specialist wants to change everything to match how he was trained.
Many organizations don't want to hire people to learn, they want to hire people to administer systems. Immediately. That said, passing the RHCE exam is indicative on ab ability to learn - not just rote facts like an MCSE exam, but actually apply that knowledge to a real system.
> Maybe they should use a technology that's not so fragile. But
Never played CoC, but there was an English freeware game where you took different types of drugs that made you hallicinate in different ways. I think it was called 'wasted' or something similar.
If you're that good, the rest of your resume will clue me in and the interview will clinch it.
It's easier to get a friend you worked with to lie on a resume than it is to cheat a well designed practical exam.
B) You successfully crammed knowledge for a bunch of technologies, half of which will be obsolete in three years.
Not crammed, utilised. There's a difference. You can't cram for a practical exam: at least in the tradtional sense - rote knowledge won't help, practical knowledge will. Very few people cram for all apsects of the RHCE. Most people who try fail. People study the areas they don't know.
So which, out of the following technologies I learnt when, has been obsoleted recently?
Apache HTTPd BIND Samba Postfix (I considered Sendmail obsolete when I studied it, and I was glad to have the opportunity to test my skills with Postfix instead - but others with major Sendmail deployments would disagree). vsftpd NFS Quotas Grub PAM
Go on, justify your opinion. Tell me which ones. Again, I'd consider NIS obsolete when I studied it three years ago, but people nevertheless still use it today. The fact you seem to think it's dead is indicate of a lack of experience in conservative (read: large) environments.
If you produced a PAM+LDAP configuration the Red Hat Way then you learned how to do it badly.
Why? If you have an opinion, justify it technically when you make it. It makes you look like a grown up.
Red Hat are futher ahead of most distros when it comes to security, they're the first with a firewall enabled by default, the first with a DAC system, and the first to Kerberize every major service. Correct me if I'm wrong.
And of course it goes without saying that the test machines are Red Hat. Good luck solving the same set of problems on Debian or Solaris.
Or Windows, or MacOS System 7. Yes, Solaris is another OS. It doesn't subscribe to the LSB, but merely a few System V and POSIX standards. Some RHCE tested skills would transfer to Solaris, but clearly not all. Teaching a lowest common denominator course would be stupid. We're aiming to teach RHEL, not Solaris. Most of our customers are moving from Solaris to RHEL. Others never have and never will use Solaris. Why put ifdefs in our courseware? Why not show how to do one thing well, rather than a few things badly? Why teach 2 init systems, one for Linux and Solaris.
Debian subscribes to the LSB. PAM, Quotas, Postfix, Samba, Linux NFS, etc. skills are all portable to Debian. But again, we're teaching RHEL. Not Debian. The LSB isn't comprehensive enough to make different Linux distributions not be fundamentally different.
Also, if you put your root partition on LVM then you're just asking for pain. I've watched folks screw this up, over and over again
Maybe they should learn how the LVM works. And have someone break it. And see if they can fix it. That'd be an accurate test of how well they can work with it.
The vendor way is often wrong.
Again, you haven't given any technical reasons why methods taught in Red Hat's classes are wrong, and I can't take you seriously until you do.
I'd much rather see someone who figured it out for himself.
I wouldn't. It's better to learn from a hundred thousand other people rather than one. I figured out Linux myself. But when I sat down and did some training I found quite a few gaps in my knowledge. And I see the same thing in classes. People know what they use, and what they've played with. They know what works, but not the best way to do things. - These guys disable SELinux because they don't understand it. - These guys partition servers really granularly not because they're putting the most accessed files on the fastest disks, but because of things that should be solved using disk quotas, but they don't know how disk quotas work - These guys make world writable directories everywhere because they don'
You didn't specify what the certifications were. if was an LPI level 1, it means he knows that the 'tac' command is cat backwards.
If it was an RHCE, it means he sat down on a machine that had 10 problems created on it, and was able to fix it with no other documentation other than that which comes with the distro.
It also meant he took a machine from bare metal to running a bunch of network services, with a particular RAID/LVM configuration, LDAP/NIS accounts, disk quotas, etc. to meet 70% around 40 requirements. In 3 hours.
Most Linux admins can't do that. Those that attempt to, on the RHCE exam, fail 32% of the time.
It's a hard exam. It's a realistic one too. Your machine breaks, you fix it, Sometimes peoples fixes screw up their machines even more. Too bad. Many people fail it.
I think the people that would fail it include both Cliff and you. Lots of people might know how to set up Apache HTTPD on BIND or whatever off the top of their head. Their knowledge though is focused: they have no idea how disk quotas, PAM, or LDAP, or the LVM works. A hard, realistic certification like the RHCE is proof the holder has passed a realitic test of a well rounded set of skills.
Disclaimer: I teach RHCEs, but I'm not speaking on Red Hat's behalf here. And I paid for my RHCE becfore I worked for Red Hat.
When using passphrases, people often wonder about users who leave their credentials on their monitor. What do you do when people leave their DNA all over their keyboard (that's skin fragments, you pervert).
Its relatively easy to spread someone elses DNA all over a crime scene (google 'DNA spray'). I don't think it'd be that difficult to do with DNA based biometrics.
Any system where a credential can't be changed is broken.
The only biometric I've seen with promise uses fingernail etchings. If your password is compromised, zero the old etching and use another fingernail. About 30K of data fits, apparently.
I'd still prefer a private key on disk or SecureID token.
As someone that is an admin, and interviews people for positions now and then, I can tell you that people with hair are useless. Far too many people who have hair are incompetant and unskilled.
The athor recommends users stick with Powerpoint due to the large amount of templates and artwork included in MS Office.
Some points:
- Professionally designed Powerpoint templates work in Impress, and are generally better quality than what MS produces, even more so because your presentation stands out more when you spend some cash on a unique looking template.
- OpenOffice.org really needs to hold a pre-2.0 design competition. . The best presentation templates created with OOo 2 beta should be included in the final, with links to the designers webpage.
Eg, under the bit where you select the template:
ModernFunkyThing v 2.7 by Professional Design Company inc. Visit www.professionaldesign.com for more info.
ProfessionalDesignCompany get good exposure for their other (paid for) designs, OOo gets templates better than MS Office and hence more users, users get better looking documents, everyone wins.
Yeah, NTLMv2 is MD4, which is broken, doesn't allow salting, and doesn't even need to be cracked anymore, just looked up in a Rainbow table.
My question for Windows admins: can I use kerberos for everything in Windows, so it never sends a hash, never ever, ever, across the network? Just TGTs and service tickets encrypted with that hash?
That's network logins, access to shares, and any other time a password may travel across the network.
Question two: So, describe your file checking process to me. I believe you may have been originally talking about the RPM hash checking. That only covers a portion of your files.
All the libaries and binaries and config files. As for non-executable stuff, like mail spools, documents, temp files, etc, it would indeed be possible to sneak exploit code into maliciously crafted mail messages, documents etc. But it seems Unix platforms in general seem to suffer from this problem less than Windows, mainly due to not using MSHTML.DLL.
Scripts I expect to be either installed from packages or created or at least read by the local admin, but I might be a little too hopeful there.
So, I would substitute a part of the boot sector or the next chain of sectors in the process. Instead of loading the next piece that gets us to the real grub, I load my modified grub, which I have hidden on the disk. My modified grub loads my modified kernel, which I have hidden on the disk. From there, I can use the rest of the real filesystem.
The trick is, if you boot from a CD and inspect the filesystem, you find the original grub and kernel files. If you try to check things once Linux is up, my modified kernel is feeding you a version of reality that matches what you expect. I.e. if you check grub and the kernel file from the running Linux, it hands over copies of the original files for you to inspect.
From memory: we're talking about root kits here, not buffer overflows. There are things like NX and memory randomization and safe programming to take care of that.
Or from a binary: How did this binary get onto the system? Did someone download it, check its signature, and it was OK? How does this binary, which is then erased, constitute a root kit? All its done is left something in the MBR, and deleted itself so you can't tell what installed it. How does it perform the tasks necessary to cover activity and maintain access once root is achieved? Again, this doesn't sound like a root kit.
If you can think of a way to maintain access from the point of having something installed merely in the MBR, and nothing left on the filesystem, I'm actually quite interested. Enlighten me (seriously - I'm not really into crappy Slashdot arguments, if you have some knowledge I don't have I'd be happy to hear it).
Slashdot Mirror
SSH compression is about 12 to 1. Even with improvements, it probably won't compete with NX compression, which is 60 to 1, and already makes X useable over a cable modem.
Kerberos uses symmetric encryption. While unlike regular logins it doesn't sent password hashes across the network (just tokens encrypted with those hashes, that people who entered the right password can decrypt), it's still not secure in that it keeps credentials on the KDC. A compromise of the KDC therefore allows an attackers to pretend to be anyone they want.
No modern authentication system should store secrets on the server, This is the reason we have PKI - we store the certificates on the server, and each user is the only person who has their private key. This means:
- A compromise of the authentication server gives the attacker...public keys, that they could get from anywhere.
- It's more easy to hold a user responsible to accidential or deliberate disclosure of their credentials, because only the user has those credentials.
Kerberos was secure when it was invented, But there's no reason my bank needs to store my credentials on their servers, thank you very much, and there's no reason I feel like letting them be responsible for the security of my account any more than necessary. It's popular because of the single sign on aspect (users get an initial token at login time they can use to auth to NFS servers, mail servers, CVS/SVN servers, web servers, etc without needing to retype their password, at least till then login token expires). And lots of apps - every client/server for web, mail, CVS, SVN, NFS, etc in RHEL 4 for example, supports it. But ssh-agent is almost as convenient for SSO - I just wish more apps accepted digital signatures for logon.
So yeah, I can see why you'd use kerberos for network app support, but it's a poor second cousin to PKI when it comes to security.
The link I referred to was Google 'akamai geocaching'.
If you search for NT on Google you might get lots of articles about Windows NT or the Northern Territory in Australia, or other uses of 'NT'. That doesn't make one of them wrong. Nor does it mean I should come up with an OS and call it NT.
Why would you tell me to pick another word?
I didn't. That was you as in 'vous'. The collective one. I just wanted to post on top of the thread.
When I Google for geocaching, the first page is an article about the thing that's being talked about here, and it says the 'first thing I thought of was Akamai'. I expected you to do a little more research.
People have been using geocaching as a type of caching since before 2000. I guess Akamai are tired of people using their term. A technical site with an article that promises to be all about, say, DNS, should say 'road DNS' if they mean 'Driving Near Stuff'.
Cool. You train people with the cpaacity to learn. I employ people who can work straight away and have already demonstrated a capacity to learn.
If you want to work in a conservative organization you should get your advice from someone else. Perhaps a Minesweeper Consul.. er.. Microsoft Certified Systems Engineer.
Perhaps you should consider a career in comedy.
And if I sound slightly annoyed there, that's because I expected an article and knowledgable comments on configuring Squid and BIND to perform geocaching. Not this unrelated random stuff.
It's like I decided to call the act of watching television 'dressing myself'.
Geocaching is transparently caching an origin server so that the content is being served from somewhere close to the person seeking it. It's what Akamai do for Microsoft and Yahoo and Apple etc. with their Linux boxes.
Geocaching is not wandering around with a GPS.
Pick another word.
If I was looking for a Red Hat or general Linux system administrator, I'd look for evidence of Red Hat or general Linux skills. Which would include certifications I think are relevant, but also relevant experience, personal style, and other criteria. I am certainly not exclusively looking for RHCEs, I'm looking for someone with skills.
>>It seems pretty clear that you have a very limited range of experience.
>Okaaay, I think this discussion has pretty well run its course but there are a couple points I'll still respond to:
You've made a lot of statements that indicate that you're not familiar with large, conservative organizations. You haven't stated why you think a vendor with a few hundred thousand clients gives inferior technical advice than some random website. You still haven't responded with any techical justification for your LDAP claim - strong opinions without technical backing are another indication that you don't have much experierience in justifying your opinions and actions, again which makes me think you don't have a diverse range of experience in large organizations.
>>by the time you realize they've been boasting about their credentials, you've hired them.
>This is why organizations often have a trial period for new employees. Perhaps in your wide range of experience you've heard of the concept.
So you'd rather ignore skills proven by certification tests, hire someone for a trial period, pay them, fire them, and re-hire?
> LVM on root is brittle.
Again, I think this depends on the training. If something snaps in half, it might not be brittle, it might just have had sufficient force applied.
I suppose this is where our experience diverges the most. I see writing glue code as a major part of the sysadmin's job.
I know what glue code is. I don't consider a custom pam module to be it, though. You'll get better results by hiring a developer rather than a system administrator. And you'll get better system administrators by hiring someone that doesn't try and be a developer.
>I don't pay people to repetitively perform tasks they could automate.
Yeah, same here. So, as I asked before, in your systems rollout example, do you think training on how to do that could be useful?
>> easier to get a friend you worked with to lie on a resume
> This isn't high school. If you don't know the material you claim it becomes real obvious real fast.
Er, people don't use references to show off knowledge, they use it to show off experience. And people can indeed be easily fooled about experience. A certification is proof that you passed a test: whether that test provided the skills needed for the role if up to the employer to decide. It's easier to verify than experience.
> You might be able to fool me, maybe, but you can't fool the computer when the time comes to do your work.
What you've said is true, but by the time you realize they've been boasting about their credentials, you've hired them.
So maybe do some testing as part of your interview process? Sure, but do you think it would be more comprehensive than a practical exam?
>> Again, I'd consider NIS obsolete when I studied it three years ago, but people nevertheless still use it today. The fact you seem to think it's dead is indicate of a lack of experience in conservative (read: large) environments.
> Yeah, just like like people still use Cobol and Fortran.
No, NIS is a lot more popular. Alas. More like Sendmail. Like you I wish it'd go away, but we're training people for the real world. not an idealized technical heaven. I wish people used PKI rather than Kerberos, which I don't consider secure. But they do, and they need to know how.
> But hey, you're right: I work for a tiny organization, only 7,000 employees.
One organization doesn't represent a sufficient sample size. You know how your environment works, perhaps very well.
>> Red Hat are futher ahead of most distros when it comes to security, they're the first with a firewall enabled by default, the first with a DAC system, and the first to Kerberize every major service. Correct me if I'm wrong.
> Okay, you're wrong. During the past five years, the number of security incidents per installed server has been lower for Debian, Slackware and FreeBSD among others.
According to whom? And you're counting the number of security incidents - which I assume you mean as intrusions, rather than its proper meaning, events - which is meaningless. Perhaps you mean patches? In that case, you should probably be using Windows, which has lesss patches released for it than most Linux distros.
> But this is an attempt at a straw-man argument. The topic isn't selecting a secure distro, its selecting competent staff. Lets get back to it, shall we?
Sure, I only reponded to some out-of-band criticism of Red Hat. To finish off the topic, though, you need to tell me what the problem is with their recommended LDAP setup.
>> Teaching a lowest common denominator course would be stupid. We're aiming to teach RHEL, not Solaris.
> I could not have given a better reason for discounting the Red Hat cert if I tried. I'm not interested in hiring a Red Hat Administrator. I'm not even interested in hiring a Linux Administrator. I'm interested in hiring a System Administrator with skill in a broad range of systems, including Linux.
Do you really think one certification could measure all those things? If so, I'm very surprised. If not, then why criticise Red Hat for focusing on Red Hat?
> What you characterize as "teaching a lowest common denominator" I see as "teaching the fundamentals." Someone well grounded in the fundamentals is vastly more useful to me than a Red Hat specialist -- he comes in ready to learn our system while the specialist wants to change everything to match how he was trained.
Many organizations don't want to hire people to learn, they want to hire people to administer systems. Immediately. That said, passing the RHCE exam is indicative on ab ability to learn - not just rote facts like an MCSE exam, but actually apply that knowledge to a real system.
> Maybe they should use a technology that's not so fragile. But
Never played CoC, but there was an English freeware game where you took different types of drugs that made you hallicinate in different ways. I think it was called 'wasted' or something similar.
If you're that good, the rest of your resume will clue me in and the interview will clinch it.
It's easier to get a friend you worked with to lie on a resume than it is to cheat a well designed practical exam.
B) You successfully crammed knowledge for a bunch of technologies, half of which will be obsolete in three years.
Not crammed, utilised. There's a difference. You can't cram for a practical exam: at least in the tradtional sense - rote knowledge won't help, practical knowledge will. Very few people cram for all apsects of the RHCE. Most people who try fail. People study the areas they don't know.
So which, out of the following technologies I learnt when, has been obsoleted recently?
Apache HTTPd
BIND
Samba
Postfix (I considered Sendmail obsolete when I studied it, and I was glad to have the opportunity to test my skills with Postfix instead - but others with major Sendmail deployments would disagree).
vsftpd
NFS
Quotas
Grub
PAM
Go on, justify your opinion. Tell me which ones. Again, I'd consider NIS obsolete when I studied it three years ago, but people nevertheless still use it today. The fact you seem to think it's dead is indicate of a lack of experience in conservative (read: large) environments.
If you produced a PAM+LDAP configuration the Red Hat Way then you learned how to do it badly.
Why? If you have an opinion, justify it technically when you make it. It makes you look like a grown up.
Red Hat are futher ahead of most distros when it comes to security, they're the first with a firewall enabled by default, the first with a DAC system, and the first to Kerberize every major service. Correct me if I'm wrong.
And of course it goes without saying that the test machines are Red Hat. Good luck solving the same set of problems on Debian or Solaris.
Or Windows, or MacOS System 7. Yes, Solaris is another OS. It doesn't subscribe to the LSB, but merely a few System V and POSIX standards. Some RHCE tested skills would transfer to Solaris, but clearly not all. Teaching a lowest common denominator course would be stupid. We're aiming to teach RHEL, not Solaris. Most of our customers are moving from Solaris to RHEL. Others never have and never will use Solaris. Why put ifdefs in our courseware? Why not show how to do one thing well, rather than a few things badly? Why teach 2 init systems, one for Linux and Solaris.
Debian subscribes to the LSB. PAM, Quotas, Postfix, Samba, Linux NFS, etc. skills are all portable to Debian. But again, we're teaching RHEL. Not Debian. The LSB isn't comprehensive enough to make different Linux distributions not be fundamentally different.
Also, if you put your root partition on LVM then you're just asking for pain. I've watched folks screw this up, over and over again
Maybe they should learn how the LVM works. And have someone break it. And see if they can fix it. That'd be an accurate test of how well they can work with it.
The vendor way is often wrong.
Again, you haven't given any technical reasons why methods taught in Red Hat's classes are wrong, and I can't take you seriously until you do.
I'd much rather see someone who figured it out for himself.
I wouldn't. It's better to learn from a hundred thousand other people rather than one. I figured out Linux myself. But when I sat down and did some training I found quite a few gaps in my knowledge. And I see the same thing in classes. People know what they use, and what they've played with. They know what works, but not the best way to do things.
- These guys disable SELinux because they don't understand it.
- These guys partition servers really granularly not because they're putting the most accessed files on the fastest disks, but because of things that should be solved using disk quotas, but they don't know how disk quotas work
- These guys make world writable directories everywhere because they don'
You didn't specify what the certifications were. if was an LPI level 1, it means he knows that the 'tac' command is cat backwards.
If it was an RHCE, it means he sat down on a machine that had 10 problems created on it, and was able to fix it with no other documentation other than that which comes with the distro.
It also meant he took a machine from bare metal to running a bunch of network services, with a particular RAID/LVM configuration, LDAP/NIS accounts, disk quotas, etc. to meet 70% around 40 requirements. In 3 hours.
Most Linux admins can't do that. Those that attempt to, on the RHCE exam, fail 32% of the time.
It's a hard exam. It's a realistic one too. Your machine breaks, you fix it, Sometimes peoples fixes screw up their machines even more. Too bad. Many people fail it.
I think the people that would fail it include both Cliff and you. Lots of people might know how to set up Apache HTTPD on BIND or whatever off the top of their head. Their knowledge though is focused: they have no idea how disk quotas, PAM, or LDAP, or the LVM works. A hard, realistic certification like the RHCE is proof the holder has passed a realitic test of a well rounded set of skills.
Disclaimer: I teach RHCEs, but I'm not speaking on Red Hat's behalf here. And I paid for my RHCE becfore I worked for Red Hat.
When using passphrases, people often wonder about users who leave their credentials on their monitor. What do you do when people leave their DNA all over their keyboard (that's skin fragments, you pervert).
Its relatively easy to spread someone elses DNA all over a crime scene (google 'DNA spray'). I don't think it'd be that difficult to do with DNA based biometrics.
Any system where a credential can't be changed is broken.
The only biometric I've seen with promise uses fingernail etchings. If your password is compromised, zero the old etching and use another fingernail. About 30K of data fits, apparently.
I'd still prefer a private key on disk or SecureID token.
As someone that is an admin, and interviews people for positions now and then, I can tell you that people with hair are useless. Far too many people who have hair are incompetant and unskilled.
Great post, one addition: grub supports NTFS too.
Unlike LILO and GRUB, I've never had a single problem configuring the Windows Boot Manager
Indeed. There's clearly a problem. I'll submit a feature request so Fedora wipes the parts of disk where NTLDR resides whenever it installs.
The athor recommends users stick with Powerpoint due to the large amount of templates and artwork included in MS Office.
Some points:
- Professionally designed Powerpoint templates work in Impress, and are generally better quality than what MS produces, even more so because your presentation stands out more when you spend some cash on a unique looking template.
- OpenOffice.org really needs to hold a pre-2.0 design competition. . The best presentation templates created with OOo 2 beta should be included in the final, with links to the designers webpage.
Eg, under the bit where you select the template:
ModernFunkyThing v 2.7 by Professional Design Company inc. Visit www.professionaldesign.com for more info.
ProfessionalDesignCompany get good exposure for their other (paid for) designs, OOo gets templates better than MS Office and hence more users, users get better looking documents, everyone wins.
Indeed, /etc/shadow. Had a braino :^).
http://www.google.com/url?sa=t&ct=res&cd=2&url=htt p%3A//www.blackhat.com/presentations/bh-asia-04/bh -jp-04-pdfs/bh-jp-04-seki.pdf&ei=iXUJQ4yLOK2UsAGU9 PzUDQ
Yeah, NTLMv2 is MD4, which is broken, doesn't allow salting, and doesn't even need to be cracked anymore, just looked up in a Rainbow table.
My question for Windows admins: can I use kerberos for everything in Windows, so it never sends a hash, never ever, ever, across the network? Just TGTs and service tickets encrypted with that hash?
That's network logins, access to shares, and any other time a password may travel across the network.
it's also VERY worthwhile to read about forcing Windows to store only the NTLM hash and drop the LM hash.
I thought NTLMv2 was MD4, which is still broken according to its inventors?
Most Linux distro that use MD5 salt the hashes in /etc/passwd or LDAP.
Question two: So, describe your file checking process to me. I believe you may have been originally talking about the RPM hash checking. That only covers a portion of your files.
All the libaries and binaries and config files. As for non-executable stuff, like mail spools, documents, temp files, etc, it would indeed be possible to sneak exploit code into maliciously crafted mail messages, documents etc. But it seems Unix platforms in general seem to suffer from this problem less than Windows, mainly due to not using MSHTML.DLL.
Scripts I expect to be either installed from packages or created or at least read by the local admin, but I might be a little too hopeful there.
So, I would substitute a part of the boot sector or the next chain of sectors in the process. Instead of loading the next piece that gets us to the real grub, I load my modified grub, which I have hidden on the disk. My modified grub loads my modified kernel, which I have hidden on the disk. From there, I can use the rest of the real filesystem.
The trick is, if you boot from a CD and inspect the filesystem, you find the original grub and kernel files. If you try to check things once Linux is up, my modified kernel is feeding you a version of reality that matches what you expect. I.e. if you check grub and the kernel file from the running Linux, it hands over copies of the original files for you to inspect.
Damn good point.
Thanks for an informative post.
From memory: we're talking about root kits here, not buffer overflows. There are things like NX and memory randomization and safe programming to take care of that.
Or from a binary: How did this binary get onto the system? Did someone download it, check its signature, and it was OK? How does this binary, which is then erased, constitute a root kit? All its done is left something in the MBR, and deleted itself so you can't tell what installed it. How does it perform the tasks necessary to cover activity and maintain access once root is achieved? Again, this doesn't sound like a root kit.
If you can think of a way to maintain access from the point of having something installed merely in the MBR, and nothing left on the filesystem, I'm actually quite interested. Enlighten me (seriously - I'm not really into crappy Slashdot arguments, if you have some knowledge I don't have I'd be happy to hear it).
How does that app, say a trojaned copy of grub stage 1, install itself to the bootsector?
With a binary.