This may not be strictly SuSE related, but what the heck: Lately, I've been getting tons of attempts to login via ssh for "guest", "test", "user", and "admin". Plenty others for root, and even one that seemed to have been a list of some script kiddie's /etc/passwd. The root ones are pretty obvious and always blocked, but I've found the others rather curious. Does anyone running a unix server really use "guest", "test", "user", or "admin" as real accounts? Judging by the volume of attempts I'm getting, there has to be something causing this. Was a borked version of ssh server released for windows, or something? Or is this trying to connect to zombie machines? From what I understand, ssh server isn't common on windows, and those accounts certainly aren't common to unix... Anyone know what's going on here? (I'm not worried about my machines, root is blocked by sshd and I don't have the other accounts, I'm just curious.)
yo, i've seen these login attempts on two of my machines, too! don't know where that comes from, but sometimes in the night i could see plenty pages of denied login attempts. a few weeks ago that stopped, but i didn't do anything to avoid these attempts...silly thing, since it were the same users as for you and some more different users, but none of them existed locally! but it sucked quite a bit to see these log entries over and over again! regards luk -----Ursprüngliche Nachricht----- Von: suse@rio.vg [mailto:suse@rio.vg] Gesendet: Montag, 20. September 2004 17:40 An: suse-security@suse.com Betreff: [suse-security] SSH password attacks This may not be strictly SuSE related, but what the heck: Lately, I've been getting tons of attempts to login via ssh for "guest", "test", "user", and "admin". Plenty others for root, and even one that seemed to have been a list of some script kiddie's /etc/passwd. The root ones are pretty obvious and always blocked, but I've found the others rather curious. Does anyone running a unix server really use "guest", "test", "user", or "admin" as real accounts? Judging by the volume of attempts I'm getting, there has to be something causing this. Was a borked version of ssh server released for windows, or something? Or is this trying to connect to zombie machines? From what I understand, ssh server isn't common on windows, and those accounts certainly aren't common to unix... Anyone know what's going on here? (I'm not worried about my machines, root is blocked by sshd and I don't have the other accounts, I'm just curious.) -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
Try to protect your ssh with tcp wrappers. ----- Original Message ----- From: "dadirtyluk" <news4dadirtyluk@gmx.de> To: <suse-security@suse.com> Sent: Monday, September 20, 2004 7:10 PM Subject: AW: [suse-security] SSH password attacks
yo,
i've seen these login attempts on two of my machines, too!
don't know where that comes from, but sometimes in the night i could see plenty pages of denied login attempts.
a few weeks ago that stopped, but i didn't do anything to avoid these attempts...silly thing, since it were the same users as for you and some more different users, but none of them existed locally!
but it sucked quite a bit to see these log entries over and over again!
regards luk
-----Ursprüngliche Nachricht----- Von: suse@rio.vg [mailto:suse@rio.vg] Gesendet: Montag, 20. September 2004 17:40 An: suse-security@suse.com Betreff: [suse-security] SSH password attacks
This may not be strictly SuSE related, but what the heck: Lately, I've been getting tons of attempts to login via ssh for "guest", "test", "user", and "admin". Plenty others for root, and even one that seemed to have been a list of some script kiddie's /etc/passwd. The root ones are pretty obvious and always blocked, but I've found the others rather curious.
Does anyone running a unix server really use "guest", "test", "user", or "admin" as real accounts? Judging by the volume of attempts I'm getting, there has to be something causing this. Was a borked version of ssh server released for windows, or something? Or is this trying to connect to zombie machines? From what I understand, ssh server isn't common on windows, and those accounts certainly aren't common to unix... Anyone know what's going on here?
(I'm not worried about my machines, root is blocked by sshd and I don't have the other accounts, I'm just curious.)
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
dadirtyluk <news4dadirtyluk@gmx.de> wrote:
i've seen these login attempts on two of my machines, too!
don't know where that comes from, but sometimes in the night i could see plenty pages of denied login attempts.
Those automated ssh login attempts where discussed several times over at FullDisclosure. A good entry point may be http://seclists.org/lists/fulldisclosure/2004/Aug/1126.html. Regards, Ulf -- /usr/lib/sendmail: No such file or directory
I have gone from perplexed to baffled to grimly determined. Having sustained a number of intrusions (all uninvited, including kitting of my Cisco 3640), I want to build a SuSE router with ip-tables. Am having the devil of a time at it. YaST will not support two network cards. Have tried manual configuration with << ip >>, which does recognize the cards ("ip link) as eth0 and eth1, but does not recognize the devices when I reference them from command line as either eth0, eth1, or those names that YaST gives them with the MAC address. Both NICs are internal. Prefer just to have an eth0 and eth1, and someway to force eth0 to load as "external." Does anyone know how to do this? a friend says it is easy in Gentoo. melissa
On Saturday 25 September 2004 11:40 am, melissad wrote:
YaST will not support two network cards.
Oh yes it will. I have several boxes with two nics, all configured with yast. What kind of nics are you having problems with? -- _____________________________________ John Andersen
On Sat, 25 Sep 2004, melissad wrote:
I have gone from perplexed to baffled to grimly determined. Having sustained a number of intrusions (all uninvited, including kitting of my Cisco 3640), I want to build a SuSE router with ip-tables. Am having the devil of a time at it.
YaST will not support two network cards. Have tried manual configuration with << ip >>, which does recognize the cards ("ip link) as eth0 and eth1, but does not recognize the devices when I reference them from command line as either eth0, eth1, or those names that YaST gives them with the MAC address.
Both NICs are internal. Prefer just to have an eth0 and eth1, and someway to force eth0 to load as "external."
Does anyone know how to do this? a friend says it is easy in Gentoo.
I find the claim that YaST does not support two network cards confusing. I've configured machines with up to four NICs using YaST and it simply works. The problem in SuSE 9.1 is that I haven't found a way to force a specific card to be a specific interface, but this could be because I'm not yet familiar enough with the 2.6 kernel. YaST should autodetect your cards in the first dialogue after you start 'yast2 network' and should then let you choose "configure" on them one by one. Bjørn -- Bjørn Tore Sund Phone: (+47) 555-84894 Stupidity is like a System administrator Fax: (+47) 555-89672 fractal; universal and Math. Department Mobile: (+47) 918 68075 infinitely repetitive. University of Bergen VIP: 81724 Support: system@mi.uib.no Contact: teknisk@mi.uib.no Direct: bjornts@mi.uib.no
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 26 September 2004 11:46, Bjorn Tore Sund wrote:
On Sat, 25 Sep 2004, melissad wrote:
I have gone from perplexed to baffled to grimly determined. Having sustained a number of intrusions (all uninvited, including kitting of my Cisco 3640), I want to build a SuSE router with ip-tables. Am having the devil of a time at it.
YaST will not support two network cards. Have tried manual configuration with << ip >>, which does recognize the cards ("ip link) as eth0 and eth1, but does not recognize the devices when I reference them from command line as either eth0, eth1, or those names that YaST gives them with the MAC address.
Both NICs are internal. Prefer just to have an eth0 and eth1, and someway to force eth0 to load as "external."
Does anyone know how to do this? a friend says it is easy in Gentoo.
I find the claim that YaST does not support two network cards confusing. I've configured machines with up to four NICs using YaST and it simply works. The problem in SuSE 9.1 is that I haven't found a way to force a specific card to be a specific interface, but this could be because I'm not yet familiar enough with the 2.6 kernel.
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
YaST should autodetect your cards in the first dialogue after you start 'yast2 network' and should then let you choose "configure" on them one by one.
Same here. Never had problems at this point... Jürgen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBVqYXtMrl3JEeRvwRAuGyAJ9nPgZ69thBLEbUfvbO9g29Otd5SACg7A/o vZUnzz3QljLrPR2La4VPOkg= =AnCN -----END PGP SIGNATURE-----
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
Bad way, IMHO. I'd never even consider monolithic kernels. Try adding the NIC modules to your INITRD_MODULES, in the order you want. Alternatively, insmod the modules from boot.local in the order you want. Untested, but cards get grabbed when their module is loaded. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Have never done either, but will try both. This is wonderful. Thanks everyone. I have been using SuSE since 6.3, but mostly as MS replacement for secure, robust, and reliable production machine. Now having to learn more, due to the deteriorating Internet civility environment and having inherited a family of MS users. Thank-you for being there and I will be contributing more as I get into this. melissa On Sun, 2004-09-26 at 20:37, Volker Kuhlmann wrote:
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
Bad way, IMHO. I'd never even consider monolithic kernels. Try adding the NIC modules to your INITRD_MODULES, in the order you want. Alternatively, insmod the modules from boot.local in the order you want. Untested, but cards get grabbed when their module is loaded.
Volker
-- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Volker Kuhlmann wrote:
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
Bad way, IMHO. I'd never even consider monolithic kernels. Try adding the NIC modules to your INITRD_MODULES, in the order you want. Alternatively, insmod the modules from boot.local in the order you want. Untested, but cards get grabbed when their module is loaded.
Just use unique names instead of the dynamically assigned interface names. You can for example also refer to an ethernet interface by MAC address or PCI bus address: $ ip link show eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:e0:4c:9f:61:9a brd ff:ff:ff:ff:ff:ff $ getcfg-interface eth-id-00:e0:4c:9f:61:9a eth0 $ lspci |grep net 0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) $ getcfg-interface eth-bus-pci-0000:00:12.0 eth0 So in my case I can use either eth0, eth-id-00:e0:4c:9f:61:9a or eth-bus-pci-0000:00:12.0 as interface name in SuSEfirewall2 depending on whether I want to refer to the first ethernet interface, an ethernet interface with a certain MAC address or the interface of a network card in a specific pci slot. cu Ludwig -- (o_ Ludwig Nussel //\ SUSE LINUX AG, Development V_/_ http://www.suse.de/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Volker, On Sunday 26 September 2004 22:37, Volker Kuhlmann wrote:
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
Bad way, IMHO. I'd never even consider monolithic kernels. Try adding the NIC modules to your INITRD_MODULES, in the order you want. Alternatively, insmod the modules from boot.local in the order you want. Untested, but cards get grabbed when their module is loaded.
This will work if you have different cards - but not if you have cards of the same type where the module loaded will handle all cards (at least it did not work for me). Monolithic kernels have some advantages from the security point of view. If the kernel does not support loading modules nobody can temper with the modules. Also, if I have a given hardware constellation which will not change (typical for server applications) why load modules? Jürgen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFBWE4RtMrl3JEeRvwRAoo+AKC9pkXQ7fK/isZ5z+1qssZDv0suMwCeLq6d jZ6pOo0hQYL2GQ+BxsYTfKs= =vGB+ -----END PGP SIGNATURE-----
This will work if you have different cards - but not if you have cards of the same type where the module loaded will handle all cards
Yes I was aware of that, but then the same driver will always grab cards in the same order. However, as Ludwig says, addressing interfaces by MAC or PCI address (which didn't used to be possible) is ever so much better.
Monolithic kernels have some advantages from the security point of view. If the kernel does not support loading modules nobody can temper with the modules. Also, if I have a given hardware constellation which will not change (typical for server applications) why load modules?
The security advantage is thin, ever since someone found out how to do the equivalent of loading modules in a monolithic kernel many years back. That the hardware doesn't change is an illusion in my experience. The network card dies, or refuses to work with some other device, mobo dies, whatever, it's a server so you're under stress to replace the part fast. Then you boot up and find you have a monolithic kernel - that's when you really start rotating... Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
Am Dienstag, 28. September 2004 01.33 schrieb Volker Kuhlmann:
That the hardware doesn't change is an illusion in my experience. The network card dies, or refuses to work with some other device, mobo dies, whatever, it's a server so you're under stress to replace the part fast. Then you boot up and find you have a monolithic kernel - that's when you really start rotating...
On most machines, special with own monolithic kernels, I've a standard kernel as reserve. Regards Jürg
On most machines, special with own monolithic kernels, I've a standard kernel as reserve.
All very well, until you find that the previous admin was less organised... :) Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
On Mon, 27 Sep 2004, [iso-8859-1] Jürgen Mell wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Volker,
On Sunday 26 September 2004 22:37, Volker Kuhlmann wrote:
One way I found to fix this: build your own kernel and do not compile the device drivers for the network cards as modules but include them into the kernel. Now the cards will always get the same 'eth...' ID.
maybe nameif (man nameif) could be used ?
Bad way, IMHO. I'd never even consider monolithic kernels. Try adding the NIC modules to your INITRD_MODULES, in the order you want. Alternatively, insmod the modules from boot.local in the order you want. Untested, but cards get grabbed when their module is loaded.
This will work if you have different cards - but not if you have cards of the same type where the module loaded will handle all cards (at least it did not work for me). Monolithic kernels have some advantages from the security point of view. If the kernel does not support loading modules nobody can temper with the modules. Also, if I have a given hardware constellation which will not change (typical for server applications) why load modules?
-- BINGO: completely leverage other's inexpensive benefits --- Engelbert Gruber -------+ SSG Fintl,Gruber,Lassnig / A6170 Zirl Innweg 5b / Tel. ++43-5238-93535 ---+
On Monday 20 September 2004 17:40, suse@rio.vg wrote:
Does anyone running a unix server really use "guest", "test", "user", or "admin" as real accounts? Judging by the volume of attempts I'm getting, there has to be something causing this. Was a borked version of ssh server released for windows, or something? Or is this trying to connect to zombie machines? From what I understand, ssh server isn't common on windows, and those accounts certainly aren't common to unix... Anyone know what's going on here?
AFAIK, when someone attempts to log in with an existing user name and incorrect password, the timing on the denied/rejected response is a great deal longer than the timing on a denied/rejected response for a non-existant user. Plugging your machine with first root, then a few accounts that in a typical unix environment will not exist, will give a potential hacker a bit of infor for their dictionary attack. Running the sequence of unknown user/unknown password is a huge resource requirement, so all they do now is just run a dictionary on user names, measure the response and make an educated guess from the responses what usernames probably do exist. Then they can start with passwords. B
Hi, by me the same: ... Sep 13 14:53:25 tempi sshd[7383]: Failed password for invalid user test from 220.73.215.151 port 52864 ssh2 Sep 13 14:53:28 tempi sshd[7385]: Failed password for invalid user guest from 220.73.215.151 port 52992 ssh2 Sep 13 14:53:30 tempi sshd[7387]: Failed password for admin from 220.73.215.151 port 53128 ssh2 Sep 13 14:53:33 tempi sshd[7393]: Failed password for admin from 220.73.215.151 port 53260 ssh2 Sep 13 14:53:36 tempi sshd[7396]: Failed password for invalid user user from 220.73.215.151 port 53392 ssh2 Sep 13 14:53:39 tempi sshd[7398]: Failed password for root from 220.73.215.151 port 53539 ssh2 Sep 13 14:53:41 tempi sshd[7400]: Failed password for root from 220.73.215.151 port 53678 ssh2 Sep 13 14:53:44 tempi sshd[7406]: Failed password for root from 220.73.215.151 port 53814 ssh2 Sep 13 14:53:47 tempi sshd[7408]: Failed password for invalid user test from 220.73.215.151 port 53948 ssh2 ... what I can do, is to block the addresses and read less logs :) On Mon, 20 Sep 2004 11:40:23 -0400, suse wrote
This may not be strictly SuSE related, but what the heck: Lately, I've been getting tons of attempts to login via ssh for "guest", "test", "user", and "admin". Plenty others for root, and even one that seemed to have been a list of some script kiddie's /etc/passwd. The root ones are pretty obvious and always blocked, but I've found the others rather curious.
Does anyone running a unix server really use "guest", "test", "user", or "admin" as real accounts? Judging by the volume of attempts I'm getting, there has to be something causing this. Was a borked version of ssh server released for windows, or something? Or is this trying to connect to zombie machines? From what I understand, ssh server isn't common on windows, and those accounts certainly aren't common to unix... Anyone know what's going on here?
(I'm not worried about my machines, root is blocked by sshd and I don't have the other accounts, I'm just curious.)
-- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help@suse.com Security-related bug reports go to security@suse.de, not here
-- Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER -- STTS
suse@rio.vg schrieb:
Anyone know what's going on here?
That's really not new. :) Try <http://www.securityfocus.com/archive/75/370099>, <http://www.securityfocus.com/archive/75/370164>, <http://www.securityfocus.com/archive/75/370354>, <http://www.securityfocus.com/archive/75/370592> and <http://www.securityfocus.com/archive/75/370752> on INCIDENTS. See also: <http://www.dslreports.com/forum/remark,10854834~mode=flat~days=9999> <http://www.incidents.org/diary.php?date=2004-07-23> <http://www.incidents.org/diary.php?date=2004-07-25> <http://www.dslreports.com/forum/remark,10854834~mode=flat~days=9999~start=60> <http://gathering.tweakers.net/forum/list_messages/937739 > <http://www.dshield.org/port_report.php?port=22&recax=1&tarax=2&srcax=2&percent=N&days=70&Redraw=>. -thh
Hello, a question about a (SuSE)Firewall-Login: Is there a possibility (most probably) to restrict the ssh-access (user and root) to the firewall to certain (local) networks like 10.10.10.*? Am I on the right way that I must change /etc/ssh/sshd_config Here I should change #ListenAddress 0.0.0.0 to ListenAddress 10.10.10.0 (with this only from the 10.10.10.0 net a user can login, root login is denied anyway) But _only_ this? For me there is no need to protect from 'inside' as it is only me. Thanks in advance, Carl
Carl A. Schreiber wrote:
Hello,
a question about a (SuSE)Firewall-Login:
Is there a possibility (most probably) to restrict the ssh-access (user and root) to the firewall to certain (local) networks like 10.10.10.*?
Am I on the right way that I must change /etc/ssh/sshd_config
Here I should change #ListenAddress 0.0.0.0 to ListenAddress 10.10.10.0 (with this only from the 10.10.10.0 net a user can login, root login is denied anyway)
But _only_ this? For me there is no need to protect from 'inside' as it is only me.
What exactly are you trying to accomplish? If you want to only allow SSH from the internal network, including root, use the rollowing in sshd_config: ListenAddress 10.10.10.5 (or whatever the IP of the server is) PermitRootLogin yes This will prevent anyone from connecting to ssh from the external network, and allow even root to login from internal. In general, this is not desirable, but if it's what you want, that's how you do it.
participants (16)
-
b＠rry.co.za -
Bjorn Tore Sund -
Carl A. Schreiber -
dadirtyluk -
engelbert.gruber＠ssg.co.at -
John -
John Andersen -
Juerg Schneider -
Juergen.Mell＠t-online.de -
Ludwig Nussel -
melissad -
Mátyás Tibor -
suse＠rio.vg -
Thomas Hochstein -
Ulf Stegemann -
Volker Kuhlmann