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 ...
|
|||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
|
|||
|
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 |
|
|||
|
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 |
|
|||
|
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 |
|
|||
|
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. |
|
|||
|
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 |
|
|||
|
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 |
|
|||
|
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 |
|
|||
|
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-... |
![]() |
| Thread Tools | |
| Display Modes | |
|
|