secure log - Security

This is a discussion on secure log - Security ; 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. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: secure log

  1. 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

  2. Re: secure log

    On 2008-02-15, 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


  3. Re: secure log

    On Feb 14, 11:05 pm, Keith Keller francisco.ca.us> wrote:
    > On 2008-02-15, 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

  4. Re: secure log

    On Thu, 14 Feb 2008, in the Usenet newsgroup comp.os.linux.security, in article
    ,
    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 wrote:


    >> 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 ****tail
    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

  5. 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.


  6. 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


  7. Re: secure log

    On Fri, 15 Feb 2008, in the Usenet newsgroup comp.os.linux.security, in article
    , 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

  8. 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

  9. 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

    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 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 to Thread