Re: What can I do about breakin attempts?

ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin) (06-02-27 14:16:16):

Still, isn't it much better to make brute-forcing (practically)
impossible? If you're a network guy, then you should know that keys
are not just more secure, but also much easier to manage/handle; one
single key for every machine you want to connect to -- without
security risks.

Worrying about a port scanner finding it? One solution is suggested
in the Security-Quickstart-HOWTO - using "PortSentry" to block someone
who scans. I dislike this technique, as it is possible to use IP
spoofing to cause a denial of service. A tradeoff is to block the
scanning address for a limited time (such as a few minutes). Another
technique is to "white-list" certain addresses such that someone
spoofing those addresses will not trigger a DOS.

This all makes it _not so easy_ to find the port -- but not impossible,
not even difficult. What I was trying to say is that as long as you
have the ability to get to the port without authentication, the attacker
has also. If you restrict the allowed IP addresses to a set of
"trusted" or at least "known" addresses, then the attacker has still a
chance to compromise one of those boxes first. Maybe he has even
legitimate access to those systems. (This is the theory that everyone
is a potential attacker).


However, your non-standard port approach will keep arbitrary
script-kiddies away, but not a 'real' attacker.

Again, what is your threat model? The skript kiddiez and zombies are
most of the problem people face. A "real" attacker? What do you
define as a "real" attacker? The police, or a government agency? They
don't have to break in - they have much more sure ways of accessing
your system. Are you concerned of a professional cracker not with the
governments? What have you got on the systems that a person would
want to get bad enough to pay a professional the large amount required
to compensate for his time? If there really is something worth those
big bux, one has to ask why, and why it is not locked away securely.

I always assume the worst-case-scenario. A 'real' attacker is any
attacker with appropriate skills to break into systems. And as said, he
might have a good reason to break into _your_ system. In my case even
the government wouldn't get to my data, as it lays encrypted on my
hard-disk, as long as there are no serious security flaws known about
the encryption method I use.

Yes, you can argue that this is "exaggerated" in my case (it's simply a
workstation). But I have the possibility to encrypt my filesystem. So
why shouldn't I do so? The effort is low anyway (entering a passphrase
at boot time).


But remember two things. NOTHING YOU CAN DO will make it totally
secure, because there is no such thing as total security - even
locking the computer in a safe, and tossing that safe into the sea.
That's called a fact of life. Second - don't get to cute or
fancy. More than one person has done so, and wound up locking
themselves out.

That's true. There is no "perfect security", but there is "ideal
security", which you can try to approach.


Figure out what your threat scenario is, and guard against that. Don't
try to prevent the impossible - or the impossible to defend.

I guard against everything I can guard against (and which comes into my
mind, of course). There is no reason not to do so, as long as the
effort required doesn't exceed a certain limit (depending on the
scenario). Passwords are simply not as secure as encrypted keys. So
why should I use passwords, just because nobody would possibly be
interested in my data? Maybe some day somebody is, and maybe this guy
is a professional.


Regards.
.

Relevant Pages

  • Re: Pin generation algorithm question
    ... > You have to secure a number of keys in this instance, ... > tokens in the database with a secret key cipher, or better a keyed hash, and ... Assume that an attacker can monitor requests and observe the ...
    (sci.crypt)
  • An Interview with Gary McGraw, Co-author of Exploiting Software: How to Break Code
    ... about software security. ... having co-authored the classic Building Secure ... which covered the design and implementation of secure code ... an attacker can get an attack payload to execute, ...
    (comp.os.linux.security)
  • An Interview with Gary McGraw, Co-author of Exploiting Software: How to Break Code
    ... about software security. ... having co-authored the classic Building Secure ... which covered the design and implementation of secure code ... an attacker can get an attack payload to execute, ...
    (comp.os.linux)
  • Re: Apache AuthBasic
    ... the SSL site, and using public/private key auth via SSL instead of basic ... distribute and sign keys to each user that is going to access the sight, ... 2)Minimize and secure your server configurations. ... > The main security concern is confidentiality of the data. ...
    (Security-Basics)
  • Re: Traffic study
    ... > What do you have not understood about 'security is binary'? ... > A car with defunct brakes must not be used. ... A car with the doors locked and the keys in your pocket is more secure ...
    (comp.security.firewalls)