OpenBSD Journal
Contributed by Deanna Phillips on from the dept.
Swa Frantzen of the other ISC has written a guide on building secure web servers using OpenBSD.
"We want a well tested OS on the security side, developed by a small set of people who really get security and put security above usability, speed or anything else. We'd like the source code and the implementations to be vetted regularly. So we'll go for OpenBSD. There really is nothing else in the same league."
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Anonymous Coward (87.78.69.170) on
By Anonymous Coward (69.158.190.24) on
There seems to be a misconception in public opinion.
Comments
By Anonymous Coward (216.175.250.42) on
>
> There seems to be a misconception in public opinion.
It's quite possible that the public is confusing "introducing new bugs" with "usability" :)
By Anonymous Coward (66.11.66.41) on
They are not using x86 because hackers "know it better"? Hackers have no problem with architecture. Script kiddies might, but you can find exploits and shell code for other common arches (PPC, sparc) if you look. And most script kiddies are going to be screwed just because the exploit they downloaded was for linux, not openbsd. This security through obscurity nonsense needs to stop.
He's not installing compilers, based entirely on the brain dead linux myth of compilers hurting security. This shows 100% that he has no clue what he is doing.
He says not to run ssh on port 22, because that is "predictable". Seriously, even the most retarded of kiddies can run a port scan and find where you are running ssh. This does not help you at all, its just more stupid nonsense that a competant admin will have to undo when they take your job.
Comments
By Don (67.41.142.182) on
>
> They are not using x86 because hackers "know it better"? Hackers have no problem with architecture. Script kiddies might, but you can find exploits and shell code for other common arches (PPC, sparc) if you look. And most script kiddies are going to be screwed just because the exploit they downloaded was for linux, not openbsd. This security through obscurity nonsense needs to stop.
>
> He's not installing compilers, based entirely on the brain dead linux myth of compilers hurting security. This shows 100% that he has no clue what he is doing.
>
> He says not to run ssh on port 22, because that is "predictable". Seriously, even the most retarded of kiddies can run a port scan and find where you are running ssh. This does not help you at all, its just more stupid nonsense that a competant admin will have to undo when they take your job.
I don't think so. Security through layers is a well established principle. Not everyone will want to run ssh on a different port, but for management from a few machines, that might not be too bad. For me, I limit ssh connections to my home firewall to IP addresses from my work subnet, and none else. Thus I don't see any password guessing ssh attacks.
Would just doing the things you pointed out be enough? No, but it would be a start.
And any sort of attention OpenBSD gets can only help. I read this when it was first posted and thought it was good to get mentioned at all.
Comments
By Anonymous Coward (201.24.232.27) on
> And any sort of attention OpenBSD gets can only help. I read this when it was first posted and thought it was good to get mentioned at all.
>
Do you really mean, ANY sort of attention?
Comments
By freddy (71.229.238.65) on
> > And any sort of attention OpenBSD gets can only help. I read this when it was first posted and thought it was good to get mentioned at all.
> >
>
> Do you really mean, ANY sort of attention?
>
>
I think the software and documentation is so high quality, that it stands on its own. Let someone call it crap, anyone with half a brain will be able to recognize quality if they take the time to look at it.
Comments
By Anonymous Coward (193.63.217.208) on
> > > And any sort of attention OpenBSD gets can only help. I read this when it was first posted and thought it was good to get mentioned at all.
> > >
> >
> > Do you really mean, ANY sort of attention?
> >
> >
>
> I think the software and documentation is so high quality, that it stands on its own. Let someone call it crap, anyone with half a brain will be able to recognize quality if they take the time to look at it.
Sadly a great many out there do not have half a brain and/or will not take the time to look at it. These people will simply believe what is written in articles like this irrespective of accuracy and whether it is good or bad.
Comments
By Anonymous Coward (89.48.46.0) on
>
> Sadly a great many out there do not have half a brain and/or will not take the time to look at it. These people will simply believe what is written in articles like this irrespective of accuracy and whether it is good or bad.
A lot of what people do is based on intuition or instincts. It is a part of human nature, whether that intuition is betrayed will show itself over time. Noone ever said people weren't fools.
By Anonymous Coward (70.25.115.53) on
Demonstrating that you ALSO don't have any clue won't change anything. Security through layers is good. Adding obstacles to legitimate administration, that do not add any security is not good. It is brain dead. Removing compilers makes the system harder to admin, but does not add any layer of security at all. NONE. Same with changing the port ssh runs on. That just makes me have to add "-p stupid_port" every time I connect to the machine. It doesn't even slow a hacker down at all, they are going to port scan before they do anything regardless.
> Would just doing the things you pointed out be enough? No, but it would be a start.
A start at what? Wasting time and making life difficult for your competant replacement? None of those things add any layers of security. Get your head out of your ass and think about it instead of blindly defending stupidity like this.
Comments
By Anonymous Coward (71.229.238.65) on
[snip]
> they are going to port scan before they do anything regardless.
>
[snip]
> A start at what? Wasting time and making life difficult for your competant replacement? None of those things add any layers of security. Get your head out of your ass and think about it instead of blindly defending stupidity like this.
A port scan is about as subtle as a rock band, humppa around here.
The majority of port 22 activity is from automated ssh brute force attacks.
Instead of shouting "lame!" lay out a better plan.
Comments
By Anonymous Coward (70.25.115.53) on
A port scan can be plenty subtle if you do it slowly, and from random machines on your botnet. There's no reason you have to slam all ports in a few seconds from the same IP. And even if someone does that, what are you going to do about it? Self-DoS yourself with brain dead snort setups that firewall off portscanners?
> The majority of port 22 activity is from automated ssh brute force attacks.
> Instead of shouting "lame!" lay out a better plan.
Uh, have a reasonable password? Why does your ssh accept passwords anyways? If you think the shitty password guessing ssh attempts are a threat, then you need help.
Comments
By Anonymous Coward (198.6.50.144) on
I know how to enable/disable key based auth or passwords, but is there a way to REQUIRE both to login?
Seems like requireing a key and a password is the best option.
Comments
By Anonymous Coward (198.208.251.24) on
>
> I know how to enable/disable key based auth or passwords, but is there a way to REQUIRE both to login?
>
> Seems like requireing a key and a password is the best option.
>
>
set a passphrase for your key......
By Henrik Gustafsson (85.224.65.86) on http://expiretable.fnord.se/
> The majority of port 22 activity is from automated ssh brute force attacks.
> Instead of shouting "lame!" lay out a better plan.
<plug style="shameless"> PF overload tables and Expiretable :) </plug>
By Nick Holland (68.43.117.34) nick@holland-consulting.net on http://www.openbsd.org/faq/
Changing ssh ports should be doing nothing for your real security. If it does, you have a problem. You may, of course...
ON THE OTHER HAND...I'm not fond of the great volume of noise I see in the logs from the brute-force SSH attacks, either. So...I do simple and non-annoying things like all my admin machines are OpenBSD, so I use OS finger printing to block Linux or to pass only OpenBSD (depending upon my needs). Is this real security? Of course not, as someone could either grab an OpenBSD machine to attack me or change their OS's finger print. It only reduces the noise in the logs, which is my goal..but I don't fool myself by saying, "my box is now more secure". I also haven't hindered administration of the thing one bit.
One could also say, "If I am administering this machine, I should be coming in from ONLY these places", and block port 22 access from anywhere other than those places..like INSIDE your network (not outside). If this is a remotely administered machine, you better make sure you have MULTIPLE stable places you could be administering the machine from... This is probably a net win for security, and can be true layers...assuming you don't do something like use the same PW on the machine you are "protecting" and the machine you admin from.
One "special case" where moving the port or putting a "too many tries" trap in place might be a gain in security is where you have "ordinary" people (i.e., the "post-it note with password on the monitor" crowd) trying to access a box by remote for whatever reason. Usually, management has dictated that Bob Smith be let work from home, and the decision is made based on Bob's sales, not his security training. In that case, yeah, it might be good to limit how many times someone gets to try invalid accounts and PWs before you just lock out that IP address. No, actually, it is still a pretty lousy way to deal with the problem, but it may be the best you have available.
Don't fool yourself into thinking you changed the overall security situation much, however.
Given the choice, don't hide your soft spots, don't have any soft spots at all! SSH isn't the soft spot, it's untrained users using trivial PWs that are the soft spot. If your ssh access is secure, it doesn't really matter how many times someone tries invalid PWs...they won't be getting in.
The "front" door of my house is on the side of the house (the back door is, too. same side. Weird house). I don't tell myself that adds one bit to the security of my house because it isn't where people expect it to be. For that to deter a crook would require a pretty low level of intelegence on their part. Moving your SSH port is pretty much the same thing: assuming zero intelegence on the part of the attacker. A much better idea is to assume the attacker is at least as smart as you, and put a good lock on the door, keep it locked, and make sure you know where the keys are. Now you have delt with the dumb ones AND the smart ones.
By RC (71.105.39.54) on
> The majority of port 22 activity is from automated ssh brute force attacks.
Hah! So a portscan is obvious, but a brute-force attack on SSH is subtle?
By Anonymous Coward (203.10.110.133) on
>
> Demonstrating that you ALSO don't have any clue won't change anything. Security through layers is good. Adding obstacles to legitimate administration, that do not add any security is not good. It is brain dead.
Using sparc64 to avoid all the randomly fired x86 specific stuff doesn't hurt security or admin ability and can only help. You also get stackghost. Real serial consoles are good for admin too.
I don't consider using something other than x86, "security through obscurity". I'm just playing the odds a little better.
Comments
By Anonymous Coward (70.25.115.53) on
Like I said, using OpenBSD already stops any no-thought x86/linux autorooters. So your arch doesn't matter. And if someone is targetting you specifically, there's already been openbsd/sparc64 exploits and shellcode released, what makes you think it won't happen again?
> Real serial consoles are good for admin too.
What the hell does that have to do with the arch? Believe it or not, serial ports aren't arch specific. Any decent server hardware has serial console, x86 or not.
> I don't consider using something other than x86, "security through obscurity". I'm just playing the odds a little better.
Its hoping that people will blindly try to run the wrong exploit code to save you from being exploited. If you are vulnerable to an exploit, you are vulnerable. Period. Changing your arch isn't going to provide any additional security. If you really believe this nonsense, perhaps you would like to buy a tiger-repellant rock?
Comments
By Anonymous Coward (216.175.250.42) on
That all depends. Does it help stem the inevitable robot uprising as well?
By couderc (213.41.181.63) on
Production servers do not need any compiler at all, their CPU ressources are dedicated to process data, not more.
If you need to install new software you do it by using binary packages which is what they are intended for.
When you have a server farm you must always have the relative host that will build needed binaries packages.
If you compile on a production server you're just anything but a good admin.
Comments
By Anonymous Coward (66.11.66.41) on
>
> Production servers do not need any compiler at all, their CPU ressources are dedicated to process data, not more.
Strawman. Having a compiler doesn't hurt security at all, and removing it doesn't add security at all. That's what is being discussed here. Your bizzare linux-warped anti-compiler mentality doesn't matter, just facts.
> If you need to install new software you do it by using binary packages which is what they are intended for.
Which are not available for openbsd -stable's base system.
> When you have a server farm you must always have the relative host that will build needed binaries packages.
The article is not about a server farm. Of course you want to compile once and push out to all your machines if you have dozens of identical machines. This article is not about a server farm.
> If you compile on a production server you're just anything but a good admin.
If you make sweeping generalizations like this, you need to stop and think more.
Comments
By Anonymous Coward (24.46.21.20) on
> Strawman. Having a compiler doesn't hurt security at all, and removing it doesn't add security at all. That's what is being discussed here. Your bizzare linux-warped anti-compiler mentality doesn't matter, just facts.
[snip]
As if an attacker could not simply bring in a compiler or build something offsite first... The front door needs to be locked before you make sure that the tool chest is locked...
By The Way, it's not a Strawman fallicy, because the poster didn't actually build up a weaker argument to attack; instead, it's a Red Herring .Every once and a while a degree in philosophy helps =)
By Marc Espie (213.41.185.88) espie@openbsd.org on
>
> Production servers do not need any compiler at all, their CPU ressources are dedicated to process data, not more.
> If you need to install new software you do it by using binary packages which is what they are intended for.
You should also not install manpages on production servers, as they will
give useful hints to the attacker.
Seriously though, removing stuff from a production server makes little
sense. Auditing the machine for unwanted processes, sure. But unless you're
seriously limited for memory, you install the same stuff on the production
machines as on the build machine. You never know when you're going to
run into a stupid dependency, like applications using cpp for whatever
purposes.
Unless you're very limited for size, you usually try to have a very similar
setup for production and for final test machines, so that you can ensure
that deployment will go smoothly. And yes, this includes having the exact
same of tools installed. Just set the debug flags to nothing, but keep the
rest around. This makes for less annoying discrepancies to take care off,
and it allows you to focus on the really important stuff, and not the irrelevant details.
By squeege (192.139.71.69) on
I think you are being a litte harsh, given that the article is fairly high-level, not going into that much detail (seems like a work in progress), and many of the concepts discussed are quite sound.
I mean, a SANS ISC handler may not be infallible, but I doubt the guy is really a moron.
You may think it's nonsense because some of the tweaks described are not the most effective means to security - but they do help, even if only minimally. Making yourself a more obscure target discourages the casual/novice attacker.
It's your loss if you choose to get stuck on some contentious details and make broad general statements about how nonsensical the article is... if you're such an authority, why don't you publish something better?
Or are you just one of those people that knows the price of everything, and the value of nothing?
Comments
By Anonymous Coward (66.11.66.41) on
Because "publishing an article" isn't helpful. Security is not following the misguided and totally unfounded advice of 10 year old "hardening linux" books. Security is a process. Every piece matters as much as the rest. An article on how to be secure will always fail. Security requires experience, and the desire to think, reason, and learn. If you are not learning, you are falling behind.
If any of these knobs that don't know what they are doing WANTED to learn about security, there's tons of resources already out there for them. There is no need for me to add anything, the basics are well covered, and advanced stuff has to come from DOING, not READING.
Comments
By Anonymous Coward (198.208.251.24) on
I beleive this is the "Evolve or Die" philosophy of security. I agree 100%
By Nicolai (12.216.45.89) on http://www.nicolaibrown.com
Anyway, I respectfully disagree. Security through layering (including obscurity) makes for the most secure system.
If you disagree, I'm sure you'd be happy to publish the details of your accounts (usernames & passwords) here. After all, it's "nonsense" as you put it to maximise secrecy.
Comments
By Anonymous Coward (66.11.66.41) on
As its been pointed out already, there is no layers here. Removing a compiler does not add a layer of security, or even obscurity. It does not help anything at all.
> If you disagree, I'm sure you'd be happy to publish the details of your accounts (usernames & passwords) here. After all, it's "nonsense" as you put it to maximise secrecy.
No, its nonsense to do stupid things that do not help security. You already have my IP. I am not doing those stupid things like removing compilers or changing my SSH port. So h4x0rz me. Show me how weak my security is because I didn't do stupid things that make no sense and call it security.
By j (88.96.119.110) on
Well, I use OpenBSD to develop my stuff and on servers and it doesn't feel like I'm driving a freakin' tank; it's got all I care to use, it's comfortable too, and I don't wear a Stetson.
Comments
By Packetman (217.37.222.1) iamromer@yahoo.co.uk on
>
> Well, I use OpenBSD to develop my stuff and on servers and it doesn't feel like I'm driving a freakin' tank; it's got all I care to use, it's comfortable too, and I don't wear a Stetson.
OpenBSD rocks, sadly that article does not....