Re: What can I do about breakin attempts?

On Mon, 27 Feb 2006, in the Usenet newsgroup comp.os.linux.security, in article
<20060227051855.61946515@xxxxxxxxxxxx>, Ertugrul Soeylemez wrote:

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.

First, let me state that I'm not talking about the setup at work. There is
a Non Disclosure Agreement - and all I will say is that there is a solution
and it is elegant.

At home (and indeed in any situation) your first task is to identify what
threat may exist. What is your expected usage? Do you really have a need
to allow connections from any IP address in the world? If not, how can
you "narrow" the range of allowed connections - perhaps to a list of trusted
IP addresses (my system accepts connections from about 40 specific IP
addresses).

The concept of moving the daemon to a non-standard port would normally be
(correctly) defined as "security through obscurity". But what threat are
you answering? Skript kiddiez and zombies do not go looking in
non-standard places. It's a waste of their time to do so, when there are
millions of other "easy" targets.

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.

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.

He will find the port, and he will also discover your knockd secret, if he
has some good reason to break into your system.

Restricting access by IP address reduces this risk. I don't know about you,
but I don't need to access my systems from unknown hosts from an unknown
location. That includes public kiosks. Sorry, that's to easy to abuse. A few
years ago, I did have such a requirement, and the solution was simple - a
one-time password. See "Practical Unix & Internet Security" from Garfinkel,
Spafford, and Schwartz, O'Reilly & Assoc., ISBN 0-596-00323-4, 984 pgs, US$55
http://www.ora.com/. See Chapter 19 in the third edition (chapter 8 in the
2nd edition - ISBN 1-56592-148-8 from 1996).

Also - do a google search for the keywords "port+knocking iptables" for
some _really_ simple solutions. Again, combining techniques like restricted
addresses, non-standard ports, port knocking, AS WELL AS eliminating password
accounts, using non-common usernames - and so on, will all work together to
raise the barrier.

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.

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

Old guy
.

Relevant Pages

  • Re: Where the &@^! was svu tonight???
    ... Communications and data serialization/deserialization module MD5: ... Threat assessment and response module MD5: ... attacker. ... Defenses available: thermal and kinetic modification of environment; ...
    (rec.arts.tv)
  • Re: Where the &@^! was svu tonight???
    ... Communications and data serialization/deserialization module MD5: ... Threat assessment and response module MD5: ... attacker. ... Defenses available: thermal and kinetic modification of environment; ...
    (rec.arts.tv)
  • Re: the "Turing Attack" (was: Sabotaged PaXtest)
    ... applied to the PaX threat model. ... that the attacker has arbitrary read/write access to the ... then you are building defenses against each category. ... You say that PaX ...
    (Linux-Kernel)
  • RE: Concepts: Security and Obscurity
    ... the relative level of determinacy, resources and skill that the attacker ... stratify the attackers and they have been classified as a single threat ... stereotypes about academia. ...
    (Security-Basics)
  • Re: Post Office
    ... She seems to see trampling other people down as a perfectly legitimate ... technique for achieving this. ... offer no threat to her. ...
    (uk.media.radio.archers)