I would have thought it would need at least a brief mention, it seems to be an aspect of system security that is often overlooked, clearly in a domestic environment there's not much you can do about it though.

cheers

Jamie...

Fancypiper: thanks. Both the "Cookbook" and "Doing things" should make for worthy Rute-class docs to refer to.

DavidPhillips: IMHO if we gonna handle GUI's we'll likely end up somewhere up an excrement-filled waterway. GUI's are one of the distro's added value thingies so none will function alike. I agree being able to read a script and use the cmdline would be an advantage. Besides that install/post-install GUI's will be modifying some files (like Nss/resolv/PAM for example), so it'll not be like we need them to create (much) stuff from scratch.
I would not object on explaining "generic" GUI's like Webmin but that ain't exactly newbie material, innit? I think we should be able to explain the security basics, which basic steps to take, be as distro-neutral as possible, don't force 'em to use the CLI and for in-depth nfo refer to LQ, references and the D-word.

DavidPhillips/markus1982: I didn't notice you ppl volunteering? Please join. I certainly could use your knowledge...

Jharris is IMHO right about physical security. If we look at the "common mistakes" that should not be a priority for now.


If I where to forecast next week:
If you could think about a list of fundamentals we should include, then monday (I won't be around much the next few days) we could begin that discussion more focussed and add some structure. Should we build our doc starting with the highest priority items? Or try to be complementary to their install process? Other ways?
If we all agree then we could be able to go into details after that, then draft up the framework, divide, conquer before next weekend...


In the meanwhile I'd like to thank you all for the contributions you made already.

Hmmm fundamentals..

Maybe the ways that your system can be taken over or messed with from someone outside?

I think that would be a great place to start...outline the dangers as it were...and then outline the solutions to each (or at least general practices to protect against these vectors)


ie:

- trojan executables (this would require some sort of intro to user IDs and file permissions)
- root exploits (or would that go under the same heading as trojans?)
- insecure daemons

Maybe what it means to firewall a system? I find a lot of newbies don't know about it...they can visualize a wall, but I've known some people who have avoided installing firewalls because "they don't want to be blocked off the net".

just spitballing here.

I will help as much as I can, my time is limited for the next couple of weeks.

In regard to physical security it could be very basic. The thing that comes to mind for me is that any box can be stolen. Gaining root access and changing a users password is trivial. This brings up the point of do you store sensative data, passwords, bookmarks to your bank, online broker, paypal with cached unencrypted passwords, email clients , etc.

Also the thought of recovery from loss in the event of theft, fire. Offsite backups, etc.

Is your laptop with your cached passwords left laying on your car seat while you go into Wal-Mart?

I just remembered another good guide.

K12 Linux Network Administration Course

This course will take you through several server management tasks. The skills you need to be a Linux server administrator will be learned in the context of these tasks. We've tried to select the most important and most useful tasks with a goal of learning basic unix skills in context. As you move from task to task your unix skills will grow and you will learn more about the Linux operating system.

Each task will have a "Unix Commands" section and a "Tips & Tricks" section. These may be referenced in the index at any time. You may add to "Tips & Tricks" and provide feedback throughout the course.

It has a good security section.

Just a note, what would be the focus of this document? The newbie home user? Or something for the office?

The only reason I ask is because a lot of security books focus a good chunk on tightening physical security (ie: bios passwords, locking doors to servers etc) and I figure for a home user that stuff is basically useless...but essential for an office admin..

I know I pretty much skipped those chapters til I was bored one day...I mean I don't admin an office network and never will (I'm a programmer analyst, promotted this week to systems analyst) but I do administer a nice network at home...which if I locked it up would mean getting beat over the head by my SO

I think whatever the focus, physical security should be touched upon. For example, one of my computers allows the user to bypass the BIOS password by changing a DIP switch on the motherboard. Which means any intruder with access to the motherboard could do the same, if he/she knew the switch to alter. Which means that the BIOS password is far from foolproof.

Well that's true...but lets face it, at home do you really have to worry about someone physically hacking the machine?

Well I guess if you have a pain in the butt little brother or something....

I mean how many people break into a house to hack? (As opposed to just ripping off the PC and selling it?)

Aha! You've put your finger on my chief concern. Somebody who steals the PC can access all its contents by flipping one little switch. And I'm sure if most burglars don't know or care, some of their customers most certainly do. I think it's a real danger for that one reason (and realistically it's the only reason I can think of, as you also suggest).

In all honesty, if there's a section titled "Lock down your home pc so if it get stolen out of your home and sold on the black market, nobody can access" would make me roll my eyes at the stereotypical ultra parania of computer geeks. I just don't think it's needed for an ultra newbie documentation.

Well Ive been looking through all of the links that you have posted at the top of the security forum and there is just too much information there for me to digest. I am looking forward to reading this security HOW TO for newbies when you finally get it written.

Oh so I guess my question would be: When do you anticipate getting something like that finished? Please dont feel like I am trying to put on the pressure or anything. I am just wondering. Oh, and if I could help out somehow by say editing or something, let me know. Keep in mind though, that I am a TOTAL newbie at this Linux stuff.

I would be interested in helping. Proofreading, trying different methods,
input from a newer linux user. Have the time to help right now so let me know what I can do.

To all of you who posted wrt physical security, and especially DavidPhillips who reminded me of my own "laptop days" at a large international (thnx for reminding me), if we look at single-user home boxen it doesn't make that much sense unless you're paranoid, but if we look a bit further at ppl sharing a box in a dorm or house, laptop users and more of those situations, I think we should include a piece about physical security. Raising awareness is a good thing. Security, a state of *awareness*, after all, being.

Fancypiper: thnx for the K12 link. Even tho it isn't awfully verbose it looks like a good checklist to use.

DavidPhillips, Kroenecker and twilli227: thanks for joining. All help will be usefull somehow. Kroenecker: don't worry. Pressure is a good thing as long as it stays at the "positive stress" levels...

As for fundamentals let's discuss* dividing it in three main area's:
I. filesystem, what: users/groups, kernel/modules, (extended) permissions, bootloader, partitioning, physical sec, integrity. How: find (suid/sgid), lsattr, modutils, psutils, lsof, (Aide, Samhain etc etc).
II. users, what: root user, (privileged) system users, human users, processes, authentication, (resource) limits, logging. How: w, last utils, sa, psutils, lsof, (logwatch, Tiger, lsat, env_audit?).
III. networking, what: services, sharing, serving, fw basics (ex (D|S)NAT?), sysctl, TCP Wrappers, authentication, IDS basics. How: Netfilter, netstat, lsof, chkrootkit, (nmap, nessus, tcpdump, Snort, Lsat?).
*I mean, this is possibly not how we should introduce it to newbies if we don't want to get entangled in a web of explanations, but more of an inventory. Each item in an area should be made subject to these three questions: what, how and why. IMHO especially the "why" part will be important because providing good reasons will give them the power to decide which parts to implement right away and what the user would benefit from that.

I think we should also end with an "Did you know?"/FAQ part. That would also allow us to place any items we can't categorize.

Just my 2 sheep goin astray.

If you're new to this thread plz first read the *whole* thread.

Hmm. No one in for a 'lil bit of discussion? Doesn't have to be a heated debate, but I sure could do with some feedback...


Please join in, please contribute and help your fellow LQ community members!