On Dec 29, 2007 11:08 PM, John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> wrote: > Tod Merley wrote: > > On Dec 29, 2007 2:43 PM, John Summerfield <debian@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >> Tod Merley wrote: > >>> On Dec 27, 2007 11:10 AM, Daniel B. Thurman <dant@xxxxxxxxx> wrote: > >>>> I have finally got my F8 setup and running so now I am reviewing the > >>>> security issues that needs to be taken into account. > > > >>>> I would like to focus on securing Fedora ..against intrusions and attacks.. > >>>> > >>>> Thanks! > >>> Hi Daniel B. Thurman! > >>> > >>> It is late so topics only for tonight: > >>> > >>> 1. Turn off services you do not use. > >>> 2. Make your computer "silent" to all but those who use it - e.g. turn > >>> off ping - e.g. use a door knock protocol on a non-standard port for > >>> ssh to access ssh (give no reply to those who knock on the normal port > >>> and respond to only your special "knock" on your non-standard port), > >> imv turning off ping is highly overrated, and introduces management > >> problems. > >> > >> My technique that I've already posted all-but prevents password scans. > >> > > > > But why let them know where you are in the first place??? > > I run a mail server, finding me is no great difficulty. > > > > >>> 3. Have a constant background scan done for virus, root kit, e-mail, > >>> changes in critical files, port scan, log files (logwatch), and > >>> audits for suspicious activity. This can and should be "niced" to not > >>> interfere with normal operations. > >> One can't really trust a computer to diagnose itself. > >> > > I do agree! > > > > Yet why not use those "brains" on the machine that are uncompromised > > to see that we are compromised so we can start to do something about > > it? > > > > Thanks for the pointer though. I have considered containing all of > > the on box security in a virtual machine (well, most of it anyway). > > As well, why not have a separate box do the file scans, log checking, > > etc...? > >>> 4. Google "pen testing". C/o osstmm. > >>> 5. Honey pots! > >> Really! They may be useful for detecting the ungodly, but they do > >> nothing to add to one's security. Quite the reverse, you must assume > >> that the ungodly have a nest in your midst. > >> > > Do not soldiers train with live ammo? Do you find out if something is > > waterproof by exposing it to sunlight? > > They don't generally invite the opposition into the camp, and that's > what you propose. > I think you respond here to a comment that I meant to support penetration testing. I regret that I was misunderstanding your last post. Your guidance concerning honey pots is welcome. What I am becoming aware of is that indeed our networks are filled with them. Every computer on your network contains "honey" someone wants to get to. I suppose what I really want are better tools to prevent and detect and respond to infection. I did come up with one possibly useful idea while thinking about this. I think I would like to see our computers report suspicious activity (attempts to access ports for services we do not use - port scans - etc,,) to a central clearing house. Perhaps each state could have a site with a server farm dedicated to obtaining and processing data of this nature which would then forward the processed results to a national server. Perhaps the national server could coordinate a trace process designed to find the actual source which coordinates the suspicious activity. I would like to find "bot" controllers. Maybe this could become part of how. I suppose the response of the enemy to this would be to DOS it with false reports and other attacks. This could be mitigated and used to enhance the process by spreading the server IPs across several ranges, coordinating the times which messages are to be sent by specific computers to those IPs and detecting the bots by either that they send at a wrong time or do not use the secret protocol as they were instructed by the server at a previous time. > > > > I have noted with interest that Penetration Testing has become an > > expected part of any good security audit. I believe it is not only > > expected, it is practically required. > > The trouble one needs to take to implement security depends on what one > has to protect. > > the first step is to choose software that is and will be properly > supported into the future, and that means _not_ Fedora. There are > hardened Linux disros around, and there are NetBSD and OpenBSD: > --- > NetBSD is a free, secure, and highly portable Unix-like Open Source > operating system available for many platforms, from large-scale server > systems to powerful desktop systems to handheld and embedded devices. > --- > Only two remote holes in the default install, in more than 10 years! > > The OpenBSD project produces a FREE, multi-platform 4.4BSD-based > UNIX-like operating system. Our efforts emphasize portability, > standardization, correctness, proactive security and integrated > cryptography. OpenBSD supports binary emulation of most programs from > SVR4 (Solaris), FreeBSD, Linux, BSD/OS, SunOS and HP-UX. > --- > > In contrast: > Fedora is a Linux-based operating system that showcases the latest in > free and open source software. > > and I note that RH doesn't highlight security at all, that's I could > find in three clicks. > In fairness Windows gets hit most because it is most popular. Similarly RH gets hit most because it is most popular. Same with Ubuntu. > > > > > I would rather find out that my car leaks in my driveway with a water > > hose than tragically on the highway! Any day! That way I find the > > leak in a way I can clean it up. > > > > Honey pots are more of a risk I would agree. Containment is a real > > issue since the goal of many exploiters is to use your machine to > > spread their wares. I guess I am hoping that the containment issues > > can be resolved so we can have them as a tool to see what got in - > > what it was and how it grows - hopefully to be able to go and deal > > with it's progenitor. > > You will never find out who got into anything but the honeypot, by > looking at the honeypot. Nor is one likely to highlight the viruses and > trojans your users download in their web content and email. > > If there's a place for a honeypot in aiding security (and having > considered it for some years I doubt it), it's in an organisation with a > well-trained security team with the resources to set one up, isolate it > from the rest of the organisation, and monitor it. > > It's not for a relative beginner who's just installed his first Linux > box and us confused about all the attacks he sees. > I suppose what I would really like to see is an intelligent "action watcher" which would notice malicious activity and start yelling about it. I guess I should not call it a "honey pot" in the classic sense meaning a computer designed to be hacked (no security). I am thinking of one whose security is set up as the computers in it's area are set up. The fact that no one should be accessing it is the first and very telling clue. It would have e-mail accounts which are mentioned in the address lists on several other computers. If it ever gets any mail we know where it's address is mentioned and so know where to look next. > > >>> 6. Backup your "used" areas often and in a number of different ways. > >>> I use flash drives, CDs, and other portions of the local or remote > >>> hard drives. I also tend to put an occasional file in an obscure > >>> e-mail account. Be ready to "wipe and re-load" efficiently. I have > >>> played with the idea of using "ghosted" "snapshots" for this purpose > >>> but have only taken that to the idea level. Tar is becoming a friend. > >> flash drives are too easy to corrupt. I'm fairly careful with such > >> things, but one of mine lost its partition table. In my case recovery > >> was easy because I knew that copying the first sector from an identical > >> other drive would repair it. > >> > > What I like about them is that they are convenient, espically for a > > laptop. Since they are fairly cheap what I do is always have and use > > more than two. Loose one, not happy with that but little loss. > > bank account details? SS number for Americans. Information about you > that could lead to someone else knowing enough about you to present > himself as you? > I hate in a way to admit it, but I do not use online transactions. I gladly receive your point if I ever do. > > > >>> 7. Do planned "wipe and re-loads" several times a year. For that > >>> matter, if you simply save your used areas and then wipe and load the > >>> new version of your distro when it comes out that is probably enough. > >>> Be ready to restore to where you were if you need to. > >> That will cause more grief than it is ever likely to save. If you're > >> running a serious server, you're off the air for some time. A server > >> that's down isn't earning you money. > >> > > You yourself said: > > > > "What you need to do depends on what you're trying to protect. If you're > > not running any servers, then things are pretty cheesy - you only need > > to worry about invited data (websites you visit, email you receive and > > such)...." > > > > I certainly agree with the first part, but somewhere in the > > neighborhood of some six million compromised machines out there now > > doing the bidding of organized crime make me down right angry at the > > second part of the statement. > > and reinstalling them all the time would be of limited benefit. However, > keeping up to date with vendor fixes, using firefox and thunderbird > instead of Internet Exploder and Lookout Express (these are mostly > Windows boxes) _would_ help. > Several in this thread have testimonies to what they were forced to do when infected with no way to cure it. I believe we are often infected with no way to even find it!! Yes, we now have scanners that will detect some polymorphic viruses. So what else will they come up with that we do not yet know about? Certainly wipe and re-load is hard. However, I have noted myself that you get much better at it with practice. Since you may have to do it anyway, it would be good to be practiced! It is not just about frustrating system infection it is also about what you will eventually need to be ready to do. Perhaps we can agree that vendor fixes and other security upgrades should be soon placed into a test environment and when found to be good the configuration implemented on similar boxes in the system quickly and in a way that can be easily and quickly replicated when necessary. Also, that snapshots of the data areas be taken often. If a box is often exposed to an infectious environment, I believe it should be re-loaded with such approved configurations often. > -- > > Cheers > John > > Thanks for the discussion John, always a pleasure. I learned much here! Thanks again, Tod
