secure log

This is a discussion on secure log within the Linux Security forums, part of the System Security and Security Related category; When someone attempts to ssh into my machine, in /var/log/secure I can see the username the attacker is ...


Go Back   Usenet Forums > System Security and Security Related > Linux Security

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 02-15-2008
jarek.paduch@gmail.com
 
Posts: n/a
Default secure log

When someone attempts to ssh into my machine, in /var/log/secure I can
see the username the attacker is trying to use...I would like to be
able to see the invalid passwords as well. Can anyone help me out
with that. Thanks
Reply With Quote
  #2 (permalink)  
Old 02-15-2008
Keith Keller
 
Posts: n/a
Default Re: secure log

On 2008-02-15, jarek.paduch@gmail.com <jarek.paduch@gmail.com> wrote:
> When someone attempts to ssh into my machine, in /var/log/secure I can
> see the username the attacker is trying to use...I would like to be
> able to see the invalid passwords as well. Can anyone help me out
> with that. Thanks


This is actually a big security hole, as you will see all the
unintentional typos your legitimate users make.

What do you hope to accomplish seeing these passwords?

--keith


--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
see X- headers for PGP signature information

Reply With Quote
  #3 (permalink)  
Old 02-15-2008
jarek.paduch@gmail.com
 
Posts: n/a
Default Re: secure log

On Feb 14, 11:05 pm, Keith Keller <kkeller-use...@wombat.san-
francisco.ca.us> wrote:
> On 2008-02-15, jarek.pad...@gmail.com <jarek.pad...@gmail.com> wrote:
>
> > When someone attempts to ssh into my machine, in /var/log/secureI can
> > see the username the attacker is trying to use...I would like to be
> > able to see the invalid passwords as well. Can anyone help me out
> > with that. Thanks

>
> This is actually a big security hole, as you will see all the
> unintentional typos your legitimate users make.
>
> What do you hope to accomplish seeing these passwords?
>
> --keith
>
> --
> kkeller-use...@wombat.san-francisco.ca.us
> (try just my userid to email me)
> AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
> see X- headers for PGP signature information


I'm the only user on this machine....and to be able to view /var/log/
secure one needs root privileges so I'm not too concerned about other
users seeing mistyped passwords in that log or anything like that.
What I would like to know is if the passwords being used for invalid
ssh attempts to my machine (by "hackers") are my actual passwords I
use with for online purposes (email, banking, etc). I don't care if
invalid users try to ssh into my machine, but if those invalid users
use MY VALID PASSWORDS then its a different story
Reply With Quote
  #4 (permalink)  
Old 02-16-2008
Moe Trin
 
Posts: n/a
Default Re: secure log

On Thu, 14 Feb 2008, in the Usenet newsgroup comp.os.linux.security, in article
<a3462c07-52bc-4a01-b6cf-8b38b56d920f@h11g2000prf.googlegroups.com>,
jarek.paduch@gmail.com wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>Keith Keller <kkeller-use...@wombat.san-francisco.ca.us> wrote:


>> jarek.pad...@gmail.com <jarek.pad...@gmail.com> wrote:


>>> When someone attempts to ssh into my machine, in /var/log/secureI can
>>> see the username the attacker is trying to use...I would like to be
>>> able to see the invalid passwords as well.


>> What do you hope to accomplish seeing these passwords?


>What I would like to know is if the passwords being used for invalid
>ssh attempts to my machine (by "hackers") are my actual passwords I
>use with for online purposes (email, banking, etc).


The only way you'll see those is to decode the SSH login data stream (no
easy task) unless you're seeing their attempts as raw text (try using a
packet sniffer), OR by going in and altering the SSH login binary which
would be a major security hole even if you are the only one on the system.
DO NOT GO THERE.

Using "other passwords". Isn't it a sign of the times that every
freakin' electronic service (banking is wonderful that way) insist that
you have to use "our new secure service". From the people who brought you
four digit "PIN" numbers as a security feature. Yeah, right.

There is a huge repository of guidance material related to creating safe
authentication schemes. I'm sure everyone has told you the "not a word in
a dictionary", "mixed case", include punctuation character", yada-yada
rules - perhaps thousands of times. Passwords should not have a connection
to the user name or individual. That means using your mother's telephone
number is out, as is the vehicle license plate number, the name of your
moose, or your favorite sports team. That's all great, but how do you
come up with unique passwords for each account/service that you have? In
the past, people used a single password (bad - compromised once is the same
as compromised everywhere), or a primary part with suffixes for each (as in
"passkeyBaNk" and "passkeyPr0n", and so on - marginally better, but still
pretty vulnerable).

A suggestion is to use pass-phrases created by taking the first or second
letter out of each word of a phrase - the classic example being "TtL*,h1WwUr"
(from the nursery rhyme "Twinkle, Twinkle, Little Star..."). Because these
_phrases_ have to be memorable TO YOU (but not the actual characters that
make up the passphrase you key in), you can "personalize" them into some
memorable part - such as "Bank Of Podunk Sucks Black Holes Through Cocktail
Straws" (and simply not include the identifying part - "sBhTcs" is the
idea). You can then make unique passwords for each service, and while the
actual "password" is totally meaningless, it's easy to "remember" and
there is thus no need to have passwords "saved" or "remembered" in a
vulnerable manner.

>I don't care if invalid users try to ssh into my machine, but if those
>invalid users use MY VALID PASSWORDS then its a different story


Only that you are keeping your passphrases in an unsafe manner. Let's
think about that for a moment. First rule - have "good" passwords (yeah,
that's given). Second rule - DO NOT WRITE THEM DOWN in any way that they
can be seen (OK, no sticky notes taped to the back of the keyboard). Third
rule - independent passwords used only for one service (as above). Fourth
rule - change/expire/replace them on a suitable timescale, and that means
having available "replacement" passwords than can be used RIGHT NOW if
needed. Fifth rule - be careful WHERE you use your password protected
services. If you want to check your banking/mail/pr0n/bookie from an
insecure computer or network, be aware that your authentication may be
sniffed. Your call.

Old guy
Reply With Quote
  #5 (permalink)  
Old 02-16-2008
PooDBrown
 
Posts: n/a
Default Re: secure log

jarek.pad,

Instead of trying to figure out what passwords they are using, you
could change your authentication on ssh to pubkey/privatekey, plus
password. This would give you two factors of authentication, one the
"attacker" would have to have your public key and private key in order
to get into your box. If you can set it up to also use a password
after this they would then have to guess your password as well.

If you take the tips given from Moe Trin on strong passwords, you have
doubled your protection.

Another option to add is to use iptables to restrict IPs that can log
into your box. By restricting by IPs, "attackers" can not get to your
box without knowing your allowed IPs and spoofing them.

In my humble opinion I don't think you should try to look at the
passwords, just beef up your security and access to ssh.

Reply With Quote
  #6 (permalink)  
Old 02-16-2008
buck
 
Posts: n/a
Default Re: secure log

On Thu, 14 Feb 2008 19:47:49 -0800 (PST), jarek.paduch@gmail.com
wrote:

>When someone attempts to ssh into my machine, in /var/log/secure I can
>see the username the attacker is trying to use...I would like to be
>able to see the invalid passwords as well. Can anyone help me out
>with that.

No.

Doesn't it just torque you to ask a legitimate question and get
advice rather than an answer...

The answer is, you tweak the source code yourself. There is no other
way other than perhaps to run Wireshark / Tshark and constantly montor
your SSH port (probably 22) to a ring buffer. I suspect you'll see an
encrypted password that won't do you any good. And spend a lot of
computer resources to run 'shark while you're looking.

Everybody else has told you why this is a "tweak the source, Luke", so
I won't belabor that.

If you do alter the SSH daemon, be sure you keep a copy of the
unaltered executable in a place that you can instantly revert from and
that you know how to revert (stop the modified, start the original).
--
buck

Reply With Quote
  #7 (permalink)  
Old 02-16-2008
Moe Trin
 
Posts: n/a
Default Re: secure log

On Fri, 15 Feb 2008, in the Usenet newsgroup comp.os.linux.security, in article
<b4378804-21b5-4057-a587-395b5537c637@64g2000hsw.googlegroups.com>, PooDBrown
wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>Instead of trying to figure out what passwords they are using, you
>could change your authentication on ssh to pubkey/privatekey, plus
>password. This would give you two factors of authentication, one the
>"attacker" would have to have your public key and private key in order
>to get into your box.


Yes, I agree with this, but here in the US, the Federal Banking
authorities frown upon users dinking with the authentication mechanisms
used for on-line banking services. You're stuck with what ever the
idiots running the server have decided upon.

>Another option to add is to use iptables to restrict IPs that can log
>into your box. By restricting by IPs, "attackers" can not get to your
>box without knowing your allowed IPs and spoofing them.


Spoofing TCP is absolutely not easy, especially if you are trying to
carry on a conversation such as a "Login:" sequence. See the docs
from nmap, and look at "Sequence Numbers" - great fun. But yes, I
have never understood why everyone feels the need to allow connections
to their systems from every d4mn IP address in the world. As of late
Friday, there were 2,586,651,004 IPv4 addresses authorized or
allocated (69.79 percent of non-RFC3330 IP space). My home systems
accept connections from a /22 and two /24s "outside" (which is a
total of 1536 addresses world wide) because I can't see any reason to
allow connections from you or anyone else that I haven't approved in
advance, and I really don't expect authorized users to be connecting
from Korea, Kenya, Kuwait or Kazakhstan or a lot of other places either.

Another "trick" often used is to simply move your server to some
entirely different port number.

[compton ~]$ head -1 /dev/random | mimencode | tr -d ' -/:-z'
615503201
30737390107
6
[compton ~]$

Yes People, an SSH server will work just fine if you move it to a port
such as 6155, 61550, 15503, or similar. You'll have to tell your client
to connect to the different port number - wow, isn't that hard.

Old guy
Reply With Quote
  #8 (permalink)  
Old 02-20-2008
jayjwa
 
Posts: n/a
Default Re: secure log

ibuprofin@painkiller.example.tld (Moe Trin) writes:

> Another "trick" often used is to simply move your server to some
> entirely different port number.
>
> [compton ~]$ head -1 /dev/random | mimencode | tr -d ' -/:-z'
> 615503201
> 30737390107
> 6
> [compton ~]$
>
> Yes People, an SSH server will work just fine if you move it to a port
> such as 6155, 61550, 15503, or similar.


I did this years ago, and it hasn't been bothered since. The vast
majority of ssh attacks use automated scripts/malware, or are run by
script-kiddies. Trying to attack a service with "secure" in the name
seems almost self-defeating, when you think about it...


--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
http://www.theregister.co.uk/2008/01..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597
Reply With Quote
  #9 (permalink)  
Old 02-28-2008
robert@aptstream.com
 
Posts: n/a
Default Re: secure log

Hi,

well - if you want to hack around - you can always (if you have root
access which I assume you do) write a few lines of perl and parse the
output of the following strace which DO include the cleartext
password:
strace -fq -e trace=read,open -o /tmp/skit.out -p <PID OF SSHD>

Not nice, but a possibility. I'm not here to tell you if I'd do the
same or not, only that it's possible.




On Feb 20, 1:36 am, jayjwa <jay...@vdrl.ath.cx.invalid> wrote:
> ibupro...@painkiller.example.tld (Moe Trin) writes:
> > Another "trick" often used is to simply move your server to some
> > entirely different port number.

>
> > [compton ~]$ head -1 /dev/random | mimencode | tr -d ' -/:-z'
> > 615503201
> > 30737390107
> > 6
> > [compton ~]$

>
> > Yes People, an SSH server will work just fine if you move it to a port
> > such as 6155, 61550, 15503, or similar.

>
> I did this years ago, and it hasn't been bothered since. The vast
> majority of ssh attacks use automated scripts/malware, or are run by
> script-kiddies. Trying to attack a service with "secure" in the name
> seems almost self-defeating, when you think about it...
>
> --
> [** America, the police state **]
> Whoooose! What's that noise? Why, it's US citizen's
> rights, going down the toilet with Bush flushing.http://www.theregister.co.uk/2008/01...B347%5D=x-347-...


Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 08:58 AM.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0