Slashdot Mirror
Installing A Secure FreeBSD Box
ltwally writes "The guys over at LittleWhiteDog have a how-to on securing FreeBSD. Topics range from the basics to custom kernels, blowfish encryption, smtp, and custom firewall scripts. Definitely worth a look if you're running a FreeBSD box, or are interested in *nix security in general."
sniff, sniff - I think something crawled up Taco's ass and died.
I hope high gas prices are depriving your children, you fucking dumbass.
.. it is very hard to get activity out of the dead....
Oh, I've got to stop this trolling sometime.
The last time I tried to use FreeBSD as a firewall [circa FreeBSD 4.8.x], you had to recompile the kernel just to get a NAT router.
Recompile the kernel? Give me a friggin' break. And there were like a gazillion how-to's all over the web, no two of which bore any resemblance whatsoever.
Where the hell is SECURE?
I also had to compile in IPv4-to-IPv6 translation support. It wasn't even in the default kernel! Give me a friggin' break. And I suppose I'm going to have to read something to figure out how recompile my kernel!
To parent: I think I see a nice shiny new Windows box in your future! You don't have to understand security with Windows. And don't worry, I think they got the last of the bugs worked out. No more security problems now!
What's so bad about the Linux updating system? Well, you need to keep in mind that the BSD distros are mostly source-based, from the packages you install to updating the operating system. And when you're dealing with source-based you can completely configure the application to do what you want and not what the person who made the package intended. So when you're using services such as up2date, you're using pre-packaged binaries that just don't suit my needs.
Uhm, maybe he means "What's wrong with RED HAT". Sounds like he needs to give gentoo or Debian a spin. In fact Gentoo and FreeBSD are pretty similar if you squint at them the right way.
Also, I remember the glory days when I would customize the packages. It sure was fun .. until I had to admin 20 boxes and continuously merge my changes into each upgrade. Then I decided it was best to work with what they give you.
So, if nothing else, you should have learned what a monopolizing and cheating corporation Microsoft is and that should drive you even more to switch over to FreeBSD or some other non-monopolizing company's operating system.
Yeah, I hate Microsoft too but I usually make slightly more persuasive arguments than showing photoshopped pictures of Bill Gates and calling Microsoft names. I don't think my boss would really "get" those, ya know?
Let's start off by working with sendmail.
Ha, okay, I guess I see now, this is a joke by some high school student. Nobody would title a document "how to secure a BSD system" and put this sentence in it on purpose.
If you didn't, it is a good option to include, as it logs all attempts to closed ports.
My boxes log enough crap as it is.. please turn that shit OFF.
I like to change the default algorithm used when encrypting a user's password to the Blowfish algorithm, as it provides the highest security at the greatest speed.
*rolls eyes* Yeah man, using blowfish to encrypt passwords instead of MD5 will totally lock down your box. Thank goodness you sealed that gaping hole.
For example, my login prompt looks like this: I'm a node in cyberspace. Who the hell are you?
Hackers, look out! This guy is TUFF AS NAILZ.
Please note if you're running versions earlier than 5.2 the name changed.
Rule of thumb: pre-stable unreleased versions of an OS are GREAT for security. No not really.
Sendmail is installed by default on FreeBSD systems and unless configured properly, it is extremely insecure.
Ho ho, he redeems himself! Well, here's how to configure it properly: chmod 000 /usr/libexec/sendmail/sendmail
Originally, I planned on making this document a lot more in-depth specifically towards IDS, setting up various other services. Then I got burned out and I just don't feel like it anymore.
That explains a lot..
Well this article was "okay" but it REALLY needs a good editor to trim the fat and fix a few spots......
The *BSD Wailing Song
What's left for me to see
In my ship I sailed so far
What can the answer be
Don't know what the questions are.
And after all I've done
Still I cannot feel the sun
Tell me save me
In the end our lost souls must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low.
Who knows what's really true
They say the end is so near
Why are we all so cruel
We just fill ourselves with fear.
And heaven and hell will turn
All that we love shall burn
Hear me trust me
In the end our lost sould must repent.
I must know it is for certain
Can it be the final curtain
As long as the wind will blow
I'll be searching high and low
Final curtain
Final curtain
Never heard of Gentoo? How about LFS? How about downloading the source and compiling it yourself?
I didn't know that packages in FreeBSD were actually source! I thought ports were source?
Why not just write your own code, after all, you wouldn't want to do what the author wanted to do, now would you?"Now that just hurts. Obviously there is no consideration of SRPMS? What about Portage? It can't be THAT bad, after all, they did port it to FreeBSD.
Format over it and install Linux. Then again every hacker is too good to hack the dead filth that *BSD is, so there really is no problem.
Isn't a *BSD box called "a coffin" ?
But unless one really needs something special out of FreeBSD ( eg, SMP ) why not start with OpenBSD?
/me likes OpenBSD :)
OpenBSD's security is alot more than just services disabled by default, and is usefull well beyond a firewall.
"You don't have to understand security with Windows"
You got that right. "Not understanding security" is the dominant paradigm form the very top of Microsoft on down.
...still needs work.
NitPick 1: a cvsup cron job every 3 hours? Cvsup traffic is always high at the top of the hour because everyone does this. Fix: Look at the second hand / second readout on your watch right now. Pick that value as the minute your cron job does its thing. It's a simple psuedo-randomizer that makes things a little easier on the cvsup.freebsd.org servers.
NitPick 2: a cvsup cron job every 3 hours? (Is there an echo?) freefall.freebsd.org is the authoritative cvsup source. Its only client is cvs-master.freebsd.org, which checks freefall every 6 minutes. Official mirrors are allowed access to cvs-master, and generally update between 1 hour and 4 hours. If you're updating more often than once a day via cron, maybe you need to think about becoming a mirror. Besides, the smart thing to do is do a cvsup on your src and ports trees and keep it back a day and watch the mail lists to see if anyone else's machine burnt their toast. If there aren't (m)any complaints, go for it.
Nit 3: An official warning and a gruff "who the heck are you" getty message aren't going to keep kids from nmapping you. Try Fooling Nmap for Whatever Reason. If you're worried your OS and your kernel version will give you away, maybe you aren't keeping as up-to-date on your security lists?
Nit 4: Sendmail. Sure. You could run sendmail, but why not look into qmail, written by djb. While you're there, check out djbdns if you need DNS services.
What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0
Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.
Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.
These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.
As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.
The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.
On the contrary, the BSD's are truly great operating systems. They are fast, stable, and reliable. If you are sick of GNU/Linux boxes crashing all the time, give *BSD a try today! You won't regret it!
*BSD is alive and well. By saying otherwise, you have shown that you clearly do not know what you are talking about! If you ever come to your senses and realise that *BSD is truly great, Slashdot will be glad to hear about it.
Recently I had an experience to use FreeBSD. I had heard many great
things about it, and was excited to replace a dead Linux firewall with
this OS. Unfortunately as things turned out, FreeBSD proved to be more
nightmare than solution.
When not attending classes at my community college to get my
humanities degree, I work part-time at a printshop. Our Linux box
there finally gave up the ghost. I'd heard that FreeBSD was incredibly
secure so I talked my boss into putting that on as a replacement.
Part of the appeal of FreeBSD was its history. A fork of the Linux
kernel, it was originally intended for Steve Job's failed NeXT cube.
Recently, its found a home amongst the ignorant and easily-fooled as a
firewall OS (later on, we'll see how Job's reached back to use FreeBSD
in OSX. This will be important later!) BSD was also famous for an
incident in the early 80s, where they were sued by Microsoft when the
BSD developers stole the TCP/IP stack from Microsoft's PC-DOS.
Once my boss gave approval, I quickly headed over to FreeBSD.com and
downloaded the ISOs from the web site. Our box was pretty
state-of-the-art, a two-CPU'ed Pentium III. Installing it went pretty
flawless and I had high hopes for our new firewall.
Almost immediately however I began to have concerns. I noticed no
where did FreeBSD display the terms of the GPL. Since its based on
Linux, this should be a requirement. Apparently the history of theft
amongst the BSD developers still continues!
I was even more shocked to learn that the ipchains rules we'd
carefully setup on our Linux box would not work on FreeBSD! Perhaps
FreeBSD is still using a SHARE-based networking security from the DOS
TCP/IP stack! Or more likely they just haven't caught up to Linux and
are still using iptables.
Whatever the case, almost immediately our box was rooted. FreeBSD
proved to be aptly named as the box was "free to be hacked" by the entire world.
Later on I would find out that despite its claims of being secure,
FreeBSD's default configuration appears to start up every service
known to man! I find it shocking that an OS commonly used for
firewalls would have BIND running by default.
Then there was the OpenSSH holes. I would later learn that FreeBSD has
a history of remote exploits. Perhaps they should work with the team
at RedHat, as RH knows how to secure their distros.
After spending a week trying to patch a leaky firewall, I gave up. I
found an Mac SE/30 and put OSX on it. I then installed Norton Personal
Firewall. That became our firewall and I'm proud to say that its been
happily running for two weeks without a single incident. I find it
funny that despite FreeBSD users arrogant claims of superiority, a
humble SE/30, running an OS that's loosely based on FreeBSD, performed
much better. Perhaps its another failing of open source versus
commercial software. Whatever the case, its clear that FreeBSD has a
long ways to go before it can be taken seriously.
An objection I have to the 'standard' OpenBSD install is the 'kill a process with processor time' problem.
Named - running along fine than BLAM! Dead process.
Or rsync as another example.
I understand the 'why' - denial of service concerns via run away processes. But to deny a service you want by killing it? Naw, sorry. The cure is worse than the problem.
Sorry about being off topic.
To the guy I got into an argument with, and subsequently won: what do you think about this? eh?
Yep, just show me one comparison in the last six months in which FreeBSD beats Linux. What was that? You have nothing?
Thought so.
Well taking recent events remove ssh and sendmail. Access via telnet only. No one will ever see my password that way
Rus
Cheap UK and US VPS
*generic BSD troll*
This is one of the most comprehensive articles I've ever seen about locking down a FreeBSD box. It covers stuff I didn't expect, including using schg to deny the ability to overwrite files.
:).
The but is that I felt it could have included more information about *why* you'd do these kinds of things instead of just how. This information would help people who are newer to FreeBSD understand how to expand on this. While it is comprehensive, I feel it could give people a little more idea of the 'why' rather than the 'how' so that people could do some securing of their own
www.sitetronics.com/wordpress
It is common knowledge that *BSD is dying, that ever hapless *BSD is mired in an irrecoverable and mortifying tangle of fatal trouble. It is perhaps anybody's guess as to which *BSD is the worst off of an admittedly suffering *BSD community. The numbers continue to decline for *BSD but FreeBSD may be hurting the most. Look at the numbers. The loss of user base for FreeBSD continues in a head spinning downward spiral.
OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of BSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.
Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.
All major marketing surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among hobbyist dilettante dabblers. In truth, for all practical purposes *BSD is already dead. It is a dead man walking.
Fact: *BSD is dying
I don't want to start a holy war here, but what is the deal with you BSD fanatics? I've been sitting here at my freelance gig in front of a BSD box (a PIII 800 w/512 Megs of RAM) for about 20 minutes now while it attempts to copy a 17 Meg file from one folder on the hard drive to another folder. 20 minutes. At home, on my Pentium Pro 200 running NT 4, which by all standards should be a lot slower than this BSD box, the same operation would take about 2 minutes. If that.
In addition, during this file transfer, Netscape will not work. And everything else has ground to a halt. Even Emacs Lite is straining to keep up as I type this.
I won't bore you with the laundry list of other problems that I've encountered while working on various BSD machines, but suffice it to say there have been many, not the least of which is I've never seen a BSD box that has run faster than its Windows counterpart, despite the BSD machines faster chip architecture. My 486/66 with 8 megs of ram runs faster than this 800 mhz machine at times. From a productivity standpoint, I don't get how people can claim that BSD is a "superior" machine.
BSD addicts, flame me if you'd like, but I'd rather hear some intelligent reasons why anyone would choose to use a BSD over other faster, cheaper, more stable systems.
Just wandering what sendmail uses port 587 for? I haven't disabled it in the past as I assummed it was need for sendmail to work, but maybe not according to this article!
%cat /etc/services |grep 587
/etc/defaults/rc.conf | grep sendmail_submit
submission 587/tcp
submission 587/udp
%cat
sendmail_submit_enable="YES" # Start a localhost-only MTA for mail submission
sendmail_submit_flags="-L sm-mta -bd -q30m -ODaemonPortOptions=Addr=localhost"
This request is outrageous. There is any amount of material on the net already about security theory and practice. I've read most of it myself. How much of it am I practicing myself? Not very much. I'm not a full time sysadmin, I sysadmin during my recess breaks from my development activities. Why do I not bother to take security measures I hear preached on every street corner? Because the devil is in the details, and I can't afford to have my FreeBSD server go offline because ICMP was accomplishing something I didn't know about.
This guide is more useful to me than another dozen sermons. It gives me confidence that I can lock down aspects of the system I don't have time to understand in depth with a modicum of confidence that the essential functions of my box will continue to perform.
In my development life there are some aspects of security I work with daily: OpenSSH (tunnels, authpf), OpenSSL, IPsec. Despite my meager time budget to practice host-based security, I'm far from clueless about good security practices.
Do people forget what an incredible sinkhole of human productivity security has become? A simple overview of X.509 destroyed a week of my time. Yet another horror show more easily avoided in theory than practice.
One of the problems with Google is that you never see the thickness of the fully assembled tome. I recall an era where system documentation was measured in shelf-feet. Whenever I had the urge to make my life more complicated than necessary, I just had to look at that bookshelf and ask myself "do I really want to go there?"
I'm at the point in my life where I'm never again going to set aside whole days to master intricacies like all the special perm bits on the FreeBSD implementation of FFS.
I cherish the people out there who return from the trenches with a tattered cheat sheet with the barbed wire, machine gun nests, and landmine locations carefully documented. And then I read highly rated comments from the Rear Admiral types that "this is all well and good, but it isn't another volume of War and Peace". I would love to find to a complete set of VAX manuals on Ebay to donate to this idiot, but I don't think I could afford the shipping charge.
What this article needs is not more theory, but more warnings about "if you experience this kind of problem after making these changes, you took your security measures too far too fast". The art of security is not in knowing what you ought to be doing, it's knowing *what you get away with hardening* given other constraints, such as having any time left over to accomplish something productive.
I always remember the famous quote about building the Fermilab accelerator. When challenged about how Fermilab improved national security, someone shot back: Fermilab is the kind of project that makes America *worth* defending. People and nations who can't grasp that response end up eating their own tails.
The Year of Our Lord 2003 has been a particularly bad year for the "B"s,
- Bob Hope
- Buddy Ebsen
- Buddy Hackett
- Barry White
- BSD
This honored list of dead is but a small token of adieu from the many fans of the deceased.These dead were truly some American Icons. They will be missed.
it's BSD. it's DEAD. I'm sorry
Funny stuff. My favorite line:
"Or more likely they just haven't caught up to Linux and are still using iptables."
Funny.
Linux cannot achieve uptimes of more than about 500 minutes. So their disclaimer is meaningless.
I had to laugh when I saw that gif. Put a smile on my face...sad, but true
And while the post was somewhat tongue-in-cheek, at the same time it outlined an underlying truth.
NAT was cutting edge circa 1997; it's now 2003, very nearly 2004, and that means NAT is paleolithic technology. I am well aware that traditionally FreeBSD is thought to possess one of the nicest TCP/IP stacks in the business, and that much of that stack has made its way into commercial offerings, but still, at this point in time, the stack ought to be sufficiently modular that a computer with two network cards in it can be immediately turned into a NAT bridge/router with no more than a few lines of text in a configuration file, NOT A RECOMPILATION OF THE KERNEL!
And no, those of us in the real world don't have time to Google for weeks on end trying to find instructions on just what it is we're supposed to do as part of this kernel recompilation, only to find that no two sets of instructions are the same. At the very least, there should be an official FreeBSD document at the official FreeBSD website that gives the officially sanctioned set of steps one needs to perform to get NAT bridge/routing up and running on a FreeBSD platform.
does anyone else find it ironic that this guy is giving a tutorial on how to secure freebsd on a windows box?
2 9. asp
http://www.littlewhitedog.com/reviews_other_000
No, no, no, no. This was the funniest line.
"Then there was the OpenSSH holes. I would later learn that FreeBSD has
a history of remote exploits. Perhaps they should work with the team
at RedHat, as RH knows how to secure their distros."
This really has to be modded up as humorous.
How do you secure something thats dead?
What We Can Learn From BSD
By Chinese Karma Whore, Version 1.0
Everyone knows about BSD's failure and imminent demise. As we pore over the history of BSD, we'll uncover a story of fatal mistakes, poor priorities, and personal rivalry, and we'll learn what mistakes to avoid so as to save Linux from a similarly grisly fate.
Let's not be overly morbid and give BSD credit for its early successes. In the 1970s, Ken Thompson and Bill Joy both made significant contributions to the computing world on the BSD platform. In the 80s, DARPA saw BSD as the premiere open platform, and, after initial successes with the 4.1BSD product, gave the BSD company a 2 year contract.
These early triumphs would soon be forgotten in a series of internal conflicts that would mar BSD's progress. In 1992, AT&T filed suit against Berkeley Software, claiming that proprietary code agreements had been haphazardly violated. In the same year, BSD filed countersuit, reciprocating bad intentions and fueling internal rivalry. While AT&T and Berkeley Software lawyers battled in court, lead developers of various BSD distributions quarreled on Usenet. In 1995, Theo de Raadt, one of the founders of the NetBSD project, formed his own rival distribution, OpenBSD, as the result of a quarrel that he documents on his website. Mr. de Raadt's stubborn arrogance was later seen in his clash with Darren Reed, which resulted in the expulsion of IPF from the OpenBSD distribution.
As personal rivalries took precedence over a quality product, BSD's codebase became worse and worse. As we all know, incompatibilities between each BSD distribution make code sharing an arduous task. Research conducted at MIT found BSD's filesystem implementation to be "very poorly performing." Even BSD's acclaimed TCP/IP stack has lagged behind, according to this study.
Problems with BSD's codebase were compounded by fundamental flaws in the BSD design approach. As argued by Eric Raymond in his watershed essay, The Cathedral and the Bazaar, rapid, decentralized development models are inherently superior to slow, centralized ones in software development. BSD developers never heeded Mr. Raymond's lesson and insisted that centralized models lead to 'cleaner code.' Don't believe their hype - BSD's development model has significantly impaired its progress. Any achievements that BSD managed to make were nullified by the BSD license, which allows corporations and coders alike to reap profits without reciprocating the generous goodwill of open-source. Fortunately, Linux is not prone to this exploitation, as it is licensed under the GPL.
The failure of BSD culminated in the resignation of Jordan Hubbard and Michael Smith from the FreeBSD core team. They both believed that FreeBSD had long lost its earlier vitality. Like an empire in decline, BSD had become bureaucratic and stagnant. As Linux gains market share and as BSD sinks deeper into the mire of decay, their parting addresses will resound as fitting eulogies to BSD's demise.
Has anyone ever done a comparative study on the pros and cons of BSD vs Linux
Linux is like living in a teepee. No Windows, no Gates, Apache in house.
I installed the mini ISO for FreeBSD 4.8 so I could cvsup Dragonfly and see what Matt Dillon was up to. Unfortunately, I was doing a few other things at the same time and stupidly left my cable modem on and didn't set a root password before rebooting. In the the time in took to go to the bathroom, I had a few more files in /usr directory - one of them being a @LongLink file with a http address in it.
That is as bad as it gets. I'm running Redhat 8 because I have the disks and needed something with a GUI quickly. I'm scared of Windows after this latest virus onslaught - now I'm scared of my favorite OS. Will 4.9 be secure-by-default???
"You see, even though I have never ever contributed code to any BSD project, I thought it was my duty to be a big asshole to others which don't use the OS I do, because it just 0wnz.", said one FreeBSD user. "Now that I know it sux0rs, though, I have to go find something else to be an asshole about."
One notorious OpenBSD fanatic known as WideOpen, told reporters, "I have to kill myself. This isn't how it was supposed to happen. My BSD has always been the best, and shouting that opinion in other people's faces at every chance I got has been my only hobby. It was all I ever did. It was what got me out of bed in the morning. Now I have to die. I will jam my bedpost up my ass until I hit my brain. It is the only way to go: BSD style."
In the volatile world of operating systems anything can happen. "At least we don't sux0r as much as Windows users", BigAzz, a relatively well-known NetBSD user said. "Screaming things in people's faces is my calling. Now I need to scream that BSD sux0rs. What a sad world. At least I won't kill myself like those uber-asshole OpenBSD guys. They are just way over the top. Or were, at least."
Nobody knows for sure what the future holds for the state of operating systems, but with Netcraft confirming the sux0r status, *BSD users all over the world will have to stick something else up their asses from now on or risk looking even more gay than they used to.
Margialized operating systems require you to jump through more hoops to get things accomplished. Not only do you have to track changes in your operating system, but you have to track changes in unsupported software and emulation libraries. You always have to tweak and use "work-around" because your hardware is not supported by any vendor.
Things only get more hairy day by day as BSD becomes increasingly marginalized.
I run a small unix shell provider running on BSD, and while I was running though this how-to, I came accross a number of things not set-up for a secure system.
Congrats to the wonderful person who wrote this document, I found it increadably useful!
And your point? Lets see if we can waste bandwidth instead...
A default RH install has no services externally available, so it's really not very funny. It was 5 years ago.
I tried that and now my friends can't get my emails. You don't know SHIT about locking down a box.
Yes, I'm joking.
-Looking for a job as a materials chemist or multivariat