Screensaver takes too much time to fade-out...

[Robert Moskowitz]

On 12/15/2011 11:34 AM, Jake Shipton wrote:
> On 15/12/11 15:23, Robert Moskowitz wrote:
>> I will provide a disclaimer up front that I work in the security field,
>> but I design security protocols (e.g. co-chaired IPsec, author of HIP,
>> contributor to 802.11i) and OS security I learn from osmosis from my
>> colleagues.
> I myself am not working within the security field. I am simply passing
> on advise from what I have learned over the years :-) (Well part of it)

And a lot of GOOD advice here!

>
>> On 12/15/2011 08:08 AM, Jake Shipton wrote:
>>> On 14/12/11 23:13, Linda McLeod wrote:
>>>> Re: Screensaver takes too much time to fade-out the previous pix, but...
>>>> Re: "RE: F14 login fails on backup copy; gdm error?"
>>>>
>>>> From:
>>>>       "Joe Zeff"<joe at zeff.us>
>>>> To:
>>>>        <users at lists.fedoraproject.org>
>>>>
>>>>
>>>>
>>>> "Extraordinary claims require extraordinary proof.  What evidence do you
>>>> have that strangers have targeted your machine and repeatedly trashed
>>>> it?"
>>>>
>>>>
>>>> The evidence is in this 5-inch stake of evidence, and in this box beside
>>>> the tower.. which proves that they destroyed a lot of my property, and
>>>> proves that psychotic-humans destroyed their greatest scientist yet...
>>>>
>>>>
>>>>
>>>> "What have you done to make your computer either an easier or harder
>>>> target?"
>>>>
>>>> Everything I could understand, in the many Linux forums...
>>> Okay.. Let's talk security :-).
>>>
>>> Right so before I get started I would like to say:
>>>
>>> If you are serious about making your machine secure, you will have to
>>> learn a thing or two about security. Reason being: a machine is only as
>>> secure as you make it. (Regardless of OS)
>>>
>>> In this mail I will try to give you some basic security tips which
>>> should get you a bit more secure than you appear to be now. From my own
>>> personal experience.
>>>
>>> You claim to have people "targeting" you.. and considering what you say
>>> and claim it wouldn't surprise me. But anyhow, that's not what I am here
>>> to discuss :-).
>>>
>>> So, first things first. If your machine has recently been targeted and
>>> "trashed", reinstall the OS. Chances are, if they got in once, they
>>> probably left them selves a nice easy backdoor (rootkit even).
>>>
>>> The safest and quickest way to remove one of these on a home computer is
>>> to just wipe the OS (They can be removed manually, but that takes a bit
>>> more skill..) - Install the very latest version of Fedora (16), (if
>>> using Fedora, I'm assuming you are as your on a Fedora list)
>> If you are truly paranoid, you will NOT have your computer connected to
>> the network during the install from a DVD.  Then further, from a trusted
>> computer (hey, how do you bootstrap this :) ), you build a local repo of
>> the fedora updates so you don't need to be exposed to internet access
>> during the 'yum update' process.  This second step might be hard.  Linux
>> install is NOT as bad as say XP install where you can get owned DURING
>> the install if you are connected (I have see lab tests where 2 min into
>> the XP install the system was owned).
> That's all well and good, but there is one problem with that. How do you
> explain to a "average" user who may not know exactly what they are doing
> to do all of that?

For an average paranoid user not behind a locked down gateway firewall, 
I would recommend install without network connectivity from the full 
DVD.  Then to shutdown services as you showed later, and THEN connect 
and get the updates.  Or even say just do "yum update kern*" first, 
reboot, then "yum update" in case there are real problems in the 
original kernel.

This would be simple enough for the average user, IMNSHO.

>
>>> Ensure when setting up your system you do not use the same password
>>> twice, or the same password you use anywhere else. Each password should
>>> be unique and should consist of Upper and Lower case letters, Numbers
>>> and Symbols (For example: MyPa55W0rd&2012&2011).
>> I am quite contrary on passwords and password strengths.  Also changing
>> GOOD passwords.  For a semi comical look at the password problem see:
>>
>> http://xkcd.com/936/
>>
>> For a good analysis of the problem with passwords see:
>>
>> http://www.cryptosmith.com/password-sanity
>>
>> Richard has a very good book on Authentication that I once taught a
>> class from...
>>
>> That said, a string of words can be easy to type in and easy to
>> remember.  However, there are programs out there like VNC that ONLY use
>> the first 8 characters in the password and ignore the rest!
> VNC? Probably not the most secure method of remotely controlling a
> machine I would say.

An example of a current service that is locked into the 8 character 
password mindset.  I do use VNC, but over SSH.

>
> As for password strengths, I've always done it the way of my example so
> I simply still advise that. If I'm wrong I'll fully admit to being
> wrong. :-).

Not wrong, as behind the attack path.  But if the service does limit 
password length, passphrases are a problem.  Smith on his site has a 
good 18 character password with ~42 bits of entropy.

>
>>> Once you've got your new shiny OS installed, immediately run "yum
>>> update" as root. Make sure all packages are downloaded and installed.
>>>
>>> The Next step is to find out exactly what you will and won't be using.
>>> Obviously, you will need a GUI if this is a home computer so use yum to
>>> install a desktop environment such as GNOME or XFCE or KDE etc,
>>> depending on your preferences. Personally I prefer XFCE.
>>>
>>> Remove all software which you do not use at all. (You may want to
>>> research things before removing them)
>> Now before this firewall discussion, are you behind a firewall now?  If
>> you are like me, you have a local firewall that you can trust, but at
>> times you are out in the public, exposed to all sorts of attacks.  First
>> configure your local firewall so that all inbound ports are closed and
>> only open those that you have evidence that you need (what local servers
>> ARE you running?  Are you using VoIP?).  Security is all about belts and
>> suspendors (multiple layers of protection).
> That is what I was trying to explain with telling the user to close
> unnecessary ports :-).
>
> In my case, I have a router's firewall and a local firewall.
>
> I only have open what I need, and I usually forward local ports to ones
> needed. For example my SSH (not actual ports)
>
> I would have say, port 1000 locally forwarded via firewall to port 22,
> but still blocking 22. So an attempt to go straight to 22 will not work,
> however port 1000 would take them to port 22 (and good luck to them when
> they get there.....)
>
> PS: I don't actually use port 1000, I use another. I would change port
> 22 directly via sshd_config but every time I did SSH broke in some way
> or another, so I just forwarded it instead haha :-).

I finally got the command to 'fix' things:

semanage port -a -t ssh_port_t -p tcp 1000

This way I am protected when I am at a public WiFi.  Like at an IETF 
meeting with a few hundred scanners going  ;)

>>> Now you should set up your firewall (through a GUI if you prefer) ensure
>>> you have no open ports which you do not use. So in Fedora's case open up
>>> system-config-firewall. The first screen you will see probably has a
>>> load of checkboxes next to various service names. You will probably want
>>> to untick if unused the following:
>>>
>>> - SSH (I will explain later how to make one of these a bit more secure.)
>>> - FTP
>>> - HTTP
>>>
>>> and any others of which you do not recognise. Switch to "Other Ports"
>>> ensure this is blank and empty, or if needed open any ports not listed
>>> on previous page which you _NEED_.
>>>
>>> Go to trusted interfaces. Also mostly should pretty much be all unticked
>>> unless otherwise required.
>>>
>>> Switch to ICMP Filter, and tick the following:
>>>
>>> - Echo Reply
>>>
>>> Now click apply (You'll be amazed how many people forget to click apply
>>> and just close the firewall settings..)
>>>
>>> Okay cool, so that's your firewall sorted (For now)
>>>
>>> Let's move onto securing services, and disabling one's you do not use.
>>>
>>> For example, you said you have no idea what SSH is, if I remember
>>> correctly this is enabled by default.
>> Yes it is.  Sitting on port 22 and EVERY script kiddie out there knows
>> that and 'knocks' with common userids and passwords.  If you really need
>> the SSH server, at least move it to another port and/or implement
>> shorewall with port knocking defense on ssh (well documented in
>> shorewall docs).  Just the number of entries in logwatch if you have it
>> up and on port 22 is annoying and part of the reason I have moved it to
>> a different port.
> Oh most definitely, and if your serious about using SSH and you need it,
> make sure you disable root login,

It is disabled by default.  Once you log in, you 'su -' as needed.

>   that will be the account script
> kiddies will be after, and if it's disabled, it won't work, and they
> will need to guess your user-name aswell.
>
> I would never recommend leaving port 22 open in the wild either.
>
> As for blocking, I'd suggest fail2ban after a set amount of failed
> logins fail2ban will ban the IP address from that port.

The shorewall rules will set a set number of connections within a time 
period and force a backoff that breaks most scripts.  I guess use the 
two together...

>
> Thus stopping the attack (Unless it's a botnet or otherwise attack, but
> if root is disabled as-well, it won't work anyhow if they are after root)

It me it is an annoyance issue.

>
>>>    If you do not use it disable it:
>>>
>>> systemctl disable sshd.service
>> This replaces chkconfig?  I've noted that chkconfig no longer lists all
>> of the services.
>>
> Yeah, see here:
>
> https://fedoraproject.org/wiki/Systemd#What_is_the_tool_to_manage_services_with_systemd.3F
>
>>> Do the same for other unused services (Be very careful with this
>>> though...)
>>>
>>> Just as a safecheck ensure you do have your firewall enabled:
>>>
>>> systemctl enable iptables.service
>>> and
>>> systemctl enable ip6tables.service
>>>
>>> Now lets talk system logs. System logs are a great way to detect odd
>>> behaviour on your machine. Most machines report these by default with
>>> "logwatch" so no setup necessary though a quick yum install logwatch
>>> wouldn't hurt to be sure it's actually installed.
>>>
>>> These logs are mailed to the root user (in my case..) at 3am. And
>>> generally speaking while this is a safe place for them to go, it's not
>>> the best of choices to be logging in as root in any case other than to
>>> do administrative tasks.
>>>
>>> So what do you do?
>>>
>>> Simple! you get them forwarded to your normal user account. To do this:
>>>
>>> nano /etc/aliases
>>>
>>> Go right to the bottom and find/add:
>>>
>>> # Person who should get root's mail
>>> root:        YourUsername
>>>
>>> Press Ctrl + X to exit and save.
>>>
>>> This change won't take affect until you run the following command:
>>>
>>> newaliases
>>>
>>> Cool! Now your user account will begin receiving all of roots mail..
>> Another way is to make the file /root/.forward by:
>>
>> su -
>> cat>  .forward
>> yourusername
>> <cntl-D>
>> exit
>>
>> This takes affect immediately.
>>
> I tried that on my system a while back, wouldn't work for some reason :/
>
>>>    But your probably wondering "Okay, so how do I read it?"
>>>
>>> There's two ways to do this.
>>>
>>> 1) Use "mail" command
>>> 2) Setup dovecot and use a local email client to fetch it.
>>>
>>> For quickness I advise mail command, for seriousness I advise dovecot. I
>>> will not go into explaining dovecot, otherwise this email may end up
>>> rather long :-).
>>>
>>> I personally use Dovecot with Postfix and Thunderbird.. but be warned:
>>> It can get pretty tricky. There are loads of tutorials out there on how
>>> to set these up. But just don't follow the parts of them asking you to
>>> open up ports, or setting up DNS for remote access etc.
>>>
>>> Ideally on a home system you only want root mail to be local to you and
>>> not remotely accessible.
>>>
>>> Just to be sure everything is running, as root run this command:
>>>
>>> logwatch --output mail --range today
>>>
>>> Check your setup method for the said email. Either with mail command as
>>> your normal user, or via email client.
>>>
>>> Now just double check and make sure SELinux is enabled.
>>>
>>> One last thing to setup would probably be "rkhunter". I'll quickly run
>>> through the setup of this.
>>>
>>> "yum install rkhunter" and optionally and recommended "yum install
>>> unhide"
>>>
>>> now as root run "rkhunter --update" then "rkhunter -c"
>>>
>>> It'll give a couple of warnings due to it's database is not setup. And
>>> probably a couple of false positives. Just look out for the part where
>>> it scans for rootkits.
>>>
>>> Now seeings as this is a new install chances of being attacked already
>>> are pretty low. So you could go ahead and run:
>>>
>>> "rkhunter --propupd"
>>> then again:
>>>
>>> "rkhunter -c" to verify everything is okay and clean.
>>>
>>> So now you have a basic semi-secure system. This would hold off most
>>> script kiddies and whatnot. And if they do try you'll probably see them
>>> in your logs.
>>>
>>> There is of course more you can do to secure your system such as setting
>>> up fail2ban and tripwire.
>>>
>>> My next advise would be to do the following:
>>>
>>> 1) Regularly change your password, say every 3/6 months.
>> A truly good password can be trusted if you never need to write it down
>> and no one is ever 'riding on your shoulder'.
>>
> Maybe so, but a good bruteforce attack could fetch a simple short
> password fairly quickly.
>
> But also think of it this way, if this person is being attacked
> repeatedly the chances are they now know that persons password (I don't
> know for sure of course, but it's entirely possible)
>
> And if you keep changing your password, they won't be able to "know it".
>
>>> 2) Watch your logs
>>> 3) Study up on security so you can perform tests against your own
>>> machine. (So you find the holes before they do..)
>>> 4) Stay up-to-date with system updates.
>>> 5) Don't give anyone your passwords.
>> Will your system become part of your estate?  If so you really are
>> obligated to maintain your passwords as part of your estate records.
>> This S**Ks in a security view, but if your loved ones will need access,
>> or if you are disabled and you need someone to access your system, you
>> need to plan for this.  Consider a firebox or a safety deposit box for
>> the root password.  My wife knows my passwords.  I don't know her's. but
>> I have root access on all of our systems...
>>
> But of course, with local access to a machine you could just go to
> recovery mode (init 1) and boom, your root straight away, and change
> user account passwords :-).
>
> (PS: That's blocked on my PC :p)
>>> 6) Don't write down passwords on paper....
>> See above on one exception to this advice.  The story goes that on 9/11
>> Morgan Stanley lost all of the IT people for the systems in the towers
>> and they NEEDED the data.  They had the backup offisite tapes but none
>> of the passwords.  During the wake for the people lost, the other IT
>> people figured out all the important passwords and were able to recover
>> the data.  I don't know the truth of this, but it points out the need
>> for recoverablity.
>>
>> Additionally, with all the passwords in your life, there are password
>> 'safes' (like MyPasswordSafe in the Fedora repo) to lock them all up
>> with one key.
> I was referring to home system security, not server or business security
> :-). But I do agree sometimes someone else knowing the password can be
> helpful. But other times it can be a serious security risk.
>
>>> With all of this, I don't think your system will suffer many more
>>> security problems if any. This is basic security (imo) and will keep you
>>> secure, at least more secure than you sound now.
>>>
>>> Hope this helps you stay safe :-).
>>>
>>> PS: Sorry for any grammar issues or misspellings, English is my only
>>> language.
>>>
>