I was looking at my logwatch mail and saw:
Failed logins from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 139 times 220.128.67.41: 9 times
Illegal users from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 229 times 220.128.67.41: 2 times
Received disconnect: 11: Bye Bye : 379 Time(s)
so it appears that someone was trying to break in to my machine.
I googled rev.gaoland.net (http://whois.domaintools.com/gaoland.net) and it appears to be some kind of French ISP. Is there some place to report this?
Steve
On Wed, Apr 21, 2010 at 00:33:11 -0400, Steve Blackwell zephod@cfl.rr.com wrote:
I googled rev.gaoland.net (http://whois.domaintools.com/gaoland.net) and it appears to be some kind of French ISP. Is there some place to report this?
It's probably not worth your time.
If you really want to, you could try reporting the incident to the ISP's abuse address.
On 4/20/10, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Apr 21, 2010 at 00:33:11 -0400, Steve Blackwell zephod@cfl.rr.com wrote:
I googled rev.gaoland.net (http://whois.domaintools.com/gaoland.net) and it appears to be some kind of French ISP. Is there some place to report this?
It's probably not worth your time.
If you really want to, you could try reporting the incident to the ISP's abuse address. --
[mkosmal@Theranch ~]$ whois 62.39.117.140 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: This output has been filtered. % To receive output for a database update, use the "-B" flag.
% Information related to '62.39.117.136 - 62.39.117.143'
inetnum: 62.39.117.136 - 62.39.117.143 netname: OLYMPIQUE-DE-MARSEILLE descr: Internet Services descr: Gaoland country: FR admin-c: HT28-RIPE tech-c: HT28-RIPE status: ASSIGNED PA remarks: ********************************************** remarks: * For hacking, spamming or security problems * remarks: * send email to abus@omfr.com * remarks: ********************************************** mnt-by: LDCOM-MNT source: RIPE # Filtered
person: Herve Talbot address: OLYMPIQUE DE MARSEILLE address: 33 Traverse de la Martine address: 13012 Marseille address: France phone: +33 4 91 76 91 20 fax-no: +33 4 91 76 91 00 e-mail: herve.talbot@omfr.com nic-hdl: HT28-RIPE mnt-by: LDCOM-MNT source: RIPE # Filtered
% Information related to '62.39.0.0/16AS15557'
route: 62.39.0.0/16 descr: LDCOM-NETWORKS CIDR BLOCK descr: FRANCE origin: AS15557 mnt-by: LDCOM-MNT source: RIPE # Filtered
Good luck with that..
YMMV
Marvin
From: "Steve Blackwell" zephod@cfl.rr.com Sent: Tuesday, 2010/April/20 21:33
I was looking at my logwatch mail and saw:
Failed logins from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 139 times 220.128.67.41: 9 times
Illegal users from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 229 times 220.128.67.41: 2 times
Received disconnect: 11: Bye Bye : 379 Time(s)
so it appears that someone was trying to break in to my machine.
I googled rev.gaoland.net (http://whois.domaintools.com/gaoland.net) and it appears to be some kind of French ISP. Is there some place to report this?
Yes. You found it already. Look in the whois report.
It's useless though. All really good (and different) passwords for all users, a clever trick with iptables to limit connections to one every few minutes, or using an alternate port for "security through obscurity" (not safe if the alternate port is discovered in a port scan), or a private key login is what you need to make these attacks simple log filler rather than an effective attack. Of course, combining methods can work nicely. (I just have a perverse pleasure from both baiting the barstads and tracking the nastiness on the net.)
This is the iptables trick. IPTABLES is filled with the path to "iptables". Mind the wrap.
... # Setup the reject trap $IPTABLES -A INPUT -p tcp --syn --dport 22 -m recent --name sshattack --set $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 180 --hitcount 2 -j LOG --log-prefix 'SSH REJECT: ' \ --log-level info $IPTABLES -A INPUT -p tcp --dport 22 --syn -m recent --name sshattack \ --rcheck --seconds 180 --hitcount 2 -j REJECT --reject-with tcp-reset ...
As it happens this allows ONE attempt every three minutes. I duplicate it for any open ports like pop3s and imaps. (I could use -m multiport for it, too, I suppose. I put different log prefixes on each just to keep track of what is being attacked.) I figure at one attempt in every three plus minutes the universe could grow cold before the password is discovered, even with a distributed attempt that is not VERY well coordinated even for a password as crude as ABCDHEFG.
{^_^}
Steve Blackwell wrote: <snip>
so it appears that someone was trying to break in to my machine.
do you have 'ping reply' enabled on your cable modem?
if so, i would suggest that you disable it so you are not visible.
hth.
On Wed, 2010-04-21 at 06:07 +0000, g wrote:
Steve Blackwell wrote:
<snip> > so it appears that someone was trying to break in to my machine.
do you have 'ping reply' enabled on your cable modem?
if so, i would suggest that you disable it so you are not visible.
It might help against naive attempts, but there are other ways of checking visibility.
poc
On Wed, 21 Apr 2010 00:33:11 -0400 Steve Blackwell zephod@cfl.rr.com wrote:
I was looking at my logwatch mail and saw:
Failed logins from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 139 times 220.128.67.41: 9 times
Illegal users from: 62.39.117.140 (140.117.39-62.rev.gaoland.net): 229 times 220.128.67.41: 2 times
Received disconnect: 11: Bye Bye : 379 Time(s)
so it appears that someone was trying to break in to my machine.
I googled rev.gaoland.net (http://whois.domaintools.com/gaoland.net) and it appears to be some kind of French ISP. Is there some place to report this?
Steve
rkhunter is reporting this:
---------------------- Start Rootkit Hunter Scan ---------------------- Warning: Suspicious file types found in /dev:
/dev/shm/mono-shared-500-shared_fileshare-steve.blackwell-Linux-i686-36-12-0:data /dev/shm/mono-shared-500-shared_data-steve.blackwell-Linux-i686-312-12-0:data /dev/shm/mono.2812: data
process 2812 is tomboy so that should be OK. What are the other 2? Normal? OK to whitelist them?
Thanks, Steve
g geleem@bellsouth.net writes:
Steve Blackwell wrote:
<snip> > so it appears that someone was trying to break in to my machine.
do you have 'ping reply' enabled on your cable modem?
if so, i would suggest that you disable it so you are not visible.
hth.
One should really point out that some icmp messages are vital to the correct operation of the network? Many newbies seem to end up filtering out icmp-must-fragment in their zeal to stop all those evil icmp messages. That messes up mtu-discovery and ends up causing some destinations to effectively be unreachable for large packets.
The core problem is to prevent someone from guessing users' passwords. You aren't going to achieve real security by hiding this or that attribute. If you don't want to worry about your users chosing bad non-random passwords, don't let them. Force them to use a 1k-2k RSA key for ssh and turn off all login types in sshd_config other than RSA2. That way any attacker has to correctly guess a 1k-bit computer generated number. That will almost certainly be much more secure than any password users will chose. Then you can look at the ssh log files and laugh. The universe isn't going to last long enough for them to guess even a small fraction of the keys.
-wolfgang
On Wed, 2010-04-21 at 11:26 -0700, Wolfgang S. Rupprecht wrote:
g geleem@bellsouth.net writes:
Steve Blackwell wrote:
<snip> > so it appears that someone was trying to break in to my machine.
do you have 'ping reply' enabled on your cable modem?
if so, i would suggest that you disable it so you are not visible.
hth.
One should really point out that some icmp messages are vital to the correct operation of the network? Many newbies seem to end up filtering out icmp-must-fragment in their zeal to stop all those evil icmp messages. That messes up mtu-discovery and ends up causing some destinations to effectively be unreachable for large packets.
The core problem is to prevent someone from guessing users' passwords. You aren't going to achieve real security by hiding this or that attribute. If you don't want to worry about your users chosing bad non-random passwords, don't let them. Force them to use a 1k-2k RSA key for ssh and turn off all login types in sshd_config other than RSA2. That way any attacker has to correctly guess a 1k-bit computer generated number. That will almost certainly be much more secure than any password users will chose. Then you can look at the ssh log files and laugh. The universe isn't going to last long enough for them to guess even a small fraction of the keys.
Although this is true, it doesn't stop denial-of-service attacks, while not replying to Pings may go some way to do so by hiding the IP address from the less sophisticated attacker. I'm just saying ...
poc
On Wed, 2010-04-21 at 18:03 -0430, Patrick O'Callaghan wrote:
while not replying to Pings may go some way to do so by hiding the IP address from the less sophisticated attacker.
And only from them. There's a difference between pinging an address that doesn't reply back, and pinging an address that's not currently connected to something. The slightly clueful will know that.
I'll make an educated guess that someone trying to hack any and everyone they can, won't bother pinging *then* attacking the responders, but will simply try to connect to each IP in a range, dealing only with the responses to the connection attempts (be they telnet, SSH, FTP, HTTP, SMTP, POP, IMAP, or any other number of protocols).
Why bother pinging? The ping doesn't help you break into the other protocol.
Wolfgang S. Rupprecht wrote:
The core problem is to prevent someone from guessing users' passwords. You aren't going to achieve real security by hiding this or that attribute. If you don't want to worry about your users chosing bad non-random passwords, don't let them. Force them to use a 1k-2k RSA key for ssh and turn off all login types in sshd_config other than RSA2. That way any attacker has to correctly guess a 1k-bit computer generated number. That will almost certainly be much more secure than any password users will chose. Then you can look at the ssh log files and laugh. The universe isn't going to last long enough for them to guess even a small fraction of the keys.
Unless someone builds a quantum computer that can implement the Shor algorithm for nontrivial cases :-)
David Liguori liguorid@albany.edu writes:
Wolfgang S. Rupprecht wrote:
The core problem is to prevent someone from guessing users' passwords. You aren't going to achieve real security by hiding this or that attribute. If you don't want to worry about your users chosing bad non-random passwords, don't let them. Force them to use a 1k-2k RSA key for ssh and turn off all login types in sshd_config other than RSA2. That way any attacker has to correctly guess a 1k-bit computer generated number. That will almost certainly be much more secure than any password users will chose. Then you can look at the ssh log files and laugh. The universe isn't going to last long enough for them to guess even a small fraction of the keys.
Unless someone builds a quantum computer that can implement the Shor algorithm for nontrivial cases :-)
;-)
I had to look that up. Luckily there are going to be lots of papers about it if folks can start factoring RSA keys of that length.
-wolfgang
On Thu, 2010-04-22 at 23:21 -0700, Wolfgang S. Rupprecht wrote:
David Liguori liguorid@albany.edu writes:
Wolfgang S. Rupprecht wrote:
The core problem is to prevent someone from guessing users' passwords. You aren't going to achieve real security by hiding this or that attribute. If you don't want to worry about your users chosing bad non-random passwords, don't let them. Force them to use a 1k-2k RSA key for ssh and turn off all login types in sshd_config other than RSA2. That way any attacker has to correctly guess a 1k-bit computer generated number. That will almost certainly be much more secure than any password users will chose. Then you can look at the ssh log files and laugh. The universe isn't going to last long enough for them to guess even a small fraction of the keys.
Unless someone builds a quantum computer that can implement the Shor algorithm for nontrivial cases :-)
;-)
I had to look that up. Luckily there are going to be lots of papers about it if folks can start factoring RSA keys of that length.
More to the point, there would be widespread panic among banks and online shopping sites, webmail sites, and anywhere else that relies on a public-key based security model, which is essentially all of them.
Luckily the chances of this happening in the short to medium term seem very low. IIRC the current record for quantum computers is factoring the number 15. Getting up to the hundreds of bits is going to be very very difficult (you can't just string a bunch of smaller ones together like a conventional computer).
poc
On Fri, 23 Apr 2010 09:35:55 -0430 Patrick O'Callaghan wrote:
More to the point, there would be widespread panic among banks and online shopping sites, webmail sites, and anywhere else that relies on a public-key based security model, which is essentially all of them.
Nah, those aren't really problems. As we have already seen with all the recent spate of credit card number pilfering, it is far simpler to get a crook hired by the company to get inside info than to waste lots of time with cracking encryption codes :-).
On Fri, 2010-04-23 at 10:09 -0400, Tom Horsley wrote:
On Fri, 23 Apr 2010 09:35:55 -0430 Patrick O'Callaghan wrote:
More to the point, there would be widespread panic among banks and online shopping sites, webmail sites, and anywhere else that relies on a public-key based security model, which is essentially all of them.
Nah, those aren't really problems. As we have already seen with all the recent spate of credit card number pilfering, it is far simpler to get a crook hired by the company to get inside info than to waste lots of time with cracking encryption codes :-).
Indeed. One of the fallacies of the security-challenged is to think that by solving crypto, you've solved security. Needham and Schroeder put it very well:
"If you think your problem can be solved by cryptography, you don't understand cryptography and you don't understand your problem."
(It's an aphorism, not to be taken *too* literally).
poc
On 04/23/2010 11:00 PM, Patrick O'Callaghan wrote:
On Fri, 2010-04-23 at 10:09 -0400, Tom Horsley wrote:
On Fri, 23 Apr 2010 09:35:55 -0430 Patrick O'Callaghan wrote:
More to the point, there would be widespread panic among banks and online shopping sites, webmail sites, and anywhere else that relies on a public-key based security model, which is essentially all of them.
Nah, those aren't really problems. As we have already seen with all the recent spate of credit card number pilfering, it is far simpler to get a crook hired by the company to get inside info than to waste lots of time with cracking encryption codes :-).
Indeed. One of the fallacies of the security-challenged is to think that by solving crypto, you've solved security. Needham and Schroeder put it very well:
"If you think your problem can be solved by cryptography, you don't understand cryptography and you don't understand your problem."
Sounds like a pithy quotation that should be found by google. But, I was unable to unearth that quotation. Do you have a source?
(It's an aphorism, not to be taken *too* literally).
poc
On Fri, 2010-04-23 at 23:08 +0800, Ed Greshko wrote:
"If you think your problem can be solved by cryptography, you don't understand cryptography and you don't understand your problem."
Sounds like a pithy quotation that should be found by google. But, I was unable to unearth that quotation. Do you have a source?
I heard Roger Needham saying it at a conference years ago. He attributed it to Mike Schroeder. Interestingly, Schroeder, who was also at the conference, then attributed it to Needham :-) I think it's quoted in one of Bruce Schneier's books (probably Applied Cryptography) but I don't have them right here to check.
poc
On Fri, 2010-04-23 at 23:08 +0800, Ed Greshko wrote:
[...] Sounds like a pithy quotation that should be found by google. But, I was unable to unearth that quotation. Do you have a source?
Try http://www.google.co.ve/search?q=needham+schroeder+dont+understand
poc
On 04/23/2010 11:41 PM, Patrick O'Callaghan wrote:
On Fri, 2010-04-23 at 23:08 +0800, Ed Greshko wrote:
[...] Sounds like a pithy quotation that should be found by google. But, I was unable to unearth that quotation. Do you have a source?
Try http://www.google.co.ve/search?q=needham+schroeder+dont+understand
OK, better. I was searching for what you had written. The actual quotation makes more sense. Thanks....