* understanding netstat -ap @ 2005-09-18 6:02 Karthik Vishwanath 2005-09-18 6:07 ` Karthik Vishwanath 2005-09-18 14:59 ` Ray Olszewski 0 siblings, 2 replies; 7+ messages in thread From: Karthik Vishwanath @ 2005-09-18 6:02 UTC (permalink / raw) To: linux-newbie Hello, As reported previously (Friday 12 August 2005, thread: programs/daemons/PIDs using the network), I happened to notice a lot of activity on the ethernet applet on my desktop. Here are lines that I thought looked most strange from the output of netstat -ap. What do they mean? For instance, does the line (from output below) tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 ESTABLISHED mean that someone (?) had an ssh session into this machine? last -adi does not show any untoward activity, however /var/log/auth.log has a whole horde of entries like: Sep 16 21:16:56 mithrandir sshd[16946]: Illegal user a from 64.91.253.157 Sep 16 21:16:57 mithrandir sshd[16946]: error: Could not get shadow information for NOUSER Sep 16 21:16:57 mithrandir sshd[16946]: Failed password for illegal user a from 64.91.253.157 port 60348 ssh2 Sep 16 21:16:57 mithrandir sshd[16948]: Illegal user b from 64.91.253.157 Sep 16 21:16:57 mithrandir sshd[16948]: error: Could not get shadow information for NOUSER Sep 16 21:16:57 mithrandir sshd[16948]: Failed password for illegal user b from 64.91.253.157 port 60369 ssh2 Must I reinstall the , to feel "safe"? Thanks, regards and sorry for the long post. -K -------------------------------------- # netstat -ap tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50481 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49720 TIME_WAIT tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50266 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49175 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 ESTABLISHED tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49928 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50040 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50811 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49506 TIME_WAIT tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50706 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51029 TIME_WAIT tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:48933 TIME_WAIT tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50373 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51135 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49824 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50584 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49281 TIME_WAIT tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49394 TIME_WAIT tcp 0 0 192.168.0.3:35283 galaxian.gpcc.itd.u:ssh ESTABLISHED tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49053 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50150 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50921 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:48832 TIME_WAIT tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49615 TIME_WAIT udp 0 0 192.168.0.3:netbios-ns *:* udp 0 0 *:netbios-ns *:* udp 0 0 *:discard *:* udp 0 0 192.168.0.3:netbios-dgm *:* udp 0 0 *:netbios-dgm *:* udp 0 0 192.168.0.3:32841 ns.cmc.co.denver:domain ESTABLISHED udp 0 0 *:sunrpc *:* - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 6:02 understanding netstat -ap Karthik Vishwanath @ 2005-09-18 6:07 ` Karthik Vishwanath 2005-09-18 14:59 ` Ray Olszewski 1 sibling, 0 replies; 7+ messages in thread From: Karthik Vishwanath @ 2005-09-18 6:07 UTC (permalink / raw) To: linux-newbie actually, it was netstat -al, sorry. On Sun, 18 Sep 2005, at 02:02, Karthik Vishwanath wrote to linux-newbie@vge...: > Hello, > > As reported previously (Friday 12 August 2005, thread: > programs/daemons/PIDs using the network), I happened to notice a lot of > activity on the ethernet applet on my desktop. Here are lines that I > thought looked most strange from the output of netstat -ap. What do they > mean? For instance, does the line (from output below) > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > ESTABLISHED > > mean that someone (?) had an ssh session into this machine? > last -adi does not show any untoward activity, however /var/log/auth.log > has a whole horde of entries like: > > Sep 16 21:16:56 mithrandir sshd[16946]: Illegal user a from 64.91.253.157 > Sep 16 21:16:57 mithrandir sshd[16946]: error: Could not get shadow > information for NOUSER > Sep 16 21:16:57 mithrandir sshd[16946]: Failed password for illegal user a > from 64.91.253.157 > port 60348 ssh2 > Sep 16 21:16:57 mithrandir sshd[16948]: Illegal user b from 64.91.253.157 > Sep 16 21:16:57 mithrandir sshd[16948]: error: Could not get shadow > information for NOUSER > Sep 16 21:16:57 mithrandir sshd[16948]: Failed password for illegal user b > from 64.91.253.157 > port 60369 ssh2 > > > Must I reinstall the , to feel "safe"? > > Thanks, regards and sorry for the long post. > > -K > > -------------------------------------- > # netstat -ap > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50481 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49720 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50266 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49175 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > ESTABLISHED > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49928 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50040 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50811 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49506 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50706 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51029 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:48933 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50373 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51135 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49824 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50584 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49281 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49394 > TIME_WAIT > tcp 0 0 192.168.0.3:35283 galaxian.gpcc.itd.u:ssh > ESTABLISHED > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49053 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50150 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50921 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:48832 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49615 > TIME_WAIT > udp 0 0 192.168.0.3:netbios-ns *:* > udp 0 0 *:netbios-ns *:* > udp 0 0 *:discard *:* > udp 0 0 192.168.0.3:netbios-dgm *:* > udp 0 0 *:netbios-dgm *:* > udp 0 0 192.168.0.3:32841 ns.cmc.co.denver:domain > ESTABLISHED > udp 0 0 *:sunrpc *:* > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-newbie" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.linux-learn.org/faqs > -------------- Seven Social Sins (M. K. Gandhi, Young India, 22-10-1925): Politics without Principle; Wealth Without Work; Pleasure Without Conscience; Knowledge without Character; Commerce without Morality; Science without Humanity; Worship without Sacrifice - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 6:02 understanding netstat -ap Karthik Vishwanath 2005-09-18 6:07 ` Karthik Vishwanath @ 2005-09-18 14:59 ` Ray Olszewski 2005-09-18 18:34 ` joy merwin monteiro 2005-09-18 19:55 ` Eric Bambach 1 sibling, 2 replies; 7+ messages in thread From: Ray Olszewski @ 2005-09-18 14:59 UTC (permalink / raw) To: linux-newbie Karthik Vishwanath wrote: > Hello, > > As reported previously (Friday 12 August 2005, thread: > programs/daemons/PIDs using the network), I happened to notice a lot of > activity on the ethernet applet on my desktop. Here are lines that I > thought looked most strange from the output of netstat -ap. What do they > mean? For instance, does the line (from output below) > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > ESTABLISHED > > mean that someone (?) had an ssh session into this machine? Yes. Probably some one from IP address 61.218.77.13 ... but to be sure of that, use netatat with the -n switch. > last -adi does not show any untoward activity, however /var/log/auth.log > has a whole horde of entries like: > > Sep 16 21:16:56 mithrandir sshd[16946]: Illegal user a from 64.91.253.157 > Sep 16 21:16:57 mithrandir sshd[16946]: error: Could not get shadow > information for NOUSER > Sep 16 21:16:57 mithrandir sshd[16946]: Failed password for illegal user a > from 64.91.253.157 > port 60348 ssh2 > Sep 16 21:16:57 mithrandir sshd[16948]: Illegal user b from 64.91.253.157 > Sep 16 21:16:57 mithrandir sshd[16948]: error: Could not get shadow > information for NOUSER > Sep 16 21:16:57 mithrandir sshd[16948]: Failed password for illegal user b > from 64.91.253.157 > port 60369 ssh2 This records a failed login attempt. Actually, two different ones (or maybe the same one trying to authenticate twice; depends on how you have sshd set up) from the same IP address. > > Must I reinstall the , to feel "safe"? Huh? Reinstall "the" what? In general, anyone trying to tell you what to do to "feel" safe is saying more than is possible for relative strangers like us. But to *be* safe, I'd suggest you do the following: 1. Figure out how connections from external IP addresses are getting to a private-interface address at all. Decide if there is a good reason for having this access. If not, eliminate it (probably at your router, but I don't know enough about your setup to be sure). 2. If you do need this access, make sure it is secure by A. limiting it to reasonably safe services and their ports. ssh qualifies as reasonably safe, for example, while telnet does not. B. seeing to it that all accounts on the system have strong password. 3. Make sure you are applying security updates regularly and promptly. (I forget what distro you use, but most have decent support for security udating of their own packages these days.) 4. If this system does have direct access to the Internet somehow (despite its using a private address, I mean), use iptables (or its 2.6.x equivalent) to create a good firewall on the system. It seems that you are the victim of **attempted** breakins. I don't see any indication in what you posted (with one possible exception; see below) of a **successful** breakin. A successsful breakin would, of course, call for an OS-plus-applications reinstall. > Thanks, regards and sorry for the long post. > > -K > > -------------------------------------- > # netstat -ap > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50481 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49720 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50266 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49175 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > ESTABLISHED > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49928 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50040 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50811 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49506 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50706 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51029 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:48933 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50373 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51135 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49824 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50584 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49281 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49394 > TIME_WAIT > tcp 0 0 192.168.0.3:35283 galaxian.gpcc.itd.u:ssh > ESTABLISHED > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49053 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50150 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50921 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:48832 > TIME_WAIT > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49615 > TIME_WAIT > udp 0 0 192.168.0.3:netbios-ns *:* > udp 0 0 *:netbios-ns *:* > udp 0 0 *:discard *:* > udp 0 0 192.168.0.3:netbios-dgm *:* > udp 0 0 *:netbios-dgm *:* > udp 0 0 192.168.0.3:32841 ns.cmc.co.denver:domain > ESTABLISHED > udp 0 0 *:sunrpc *:* This looks to me like someone (or maybe 2 someones, since there are 2 source addresses) is making a bunch of ssh connections and trying to find a userid/password combo that will work. Note that all but 1 of the ssh entries is status TIME_WAIT, which in practice means they are terminated connections that have not timed out on your system yet. But compare these addresses/ports to your logs to be sure of what happened. The other ESTABLISHED connection is an *outgoing* ssh connection. If you don't know what that one it, then I suggest you do need to worry about a successful penetration having occurred. BTW, the 61-218-77-13 address is a dialup IP address in Taiwan. The other one is incomplete (try using the -n option) so I cannot check it for sure, but 220-228-117-0 also is from Taiwan (probably a DSL block, judging from the "adsl" in the name). - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 14:59 ` Ray Olszewski @ 2005-09-18 18:34 ` joy merwin monteiro 2005-09-18 19:55 ` Eric Bambach 1 sibling, 0 replies; 7+ messages in thread From: joy merwin monteiro @ 2005-09-18 18:34 UTC (permalink / raw) To: linux-newbie > BTW, the 61-218-77-13 address is a dialup IP address in Taiwan. The > other one is incomplete (try using the -n option) so I cannot check it > for sure, but 220-228-117-0 also is from Taiwan (probably a DSL block, > judging from the "adsl" in the name). > Most probably spoofed, doubt anything to be gotten down that line.... > - > To unsubscribe from this list: send the line "unsubscribe linux-newbie" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.linux-learn.org/faqs > -- <ed__> riel: if it were a vax, gcc would probably be an opcode - excerpt from #kernelnewbies - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 14:59 ` Ray Olszewski 2005-09-18 18:34 ` joy merwin monteiro @ 2005-09-18 19:55 ` Eric Bambach 2005-09-18 20:10 ` Yawar Amin 1 sibling, 1 reply; 7+ messages in thread From: Eric Bambach @ 2005-09-18 19:55 UTC (permalink / raw) To: Ray Olszewski, Karthik Vishwanath; +Cc: linux-newbie On Sunday 18 September 2005 09:59 am, Ray Olszewski wrote: Hello, These are SSH brute force attempts to guess username password combonations. There are alot of such attacks going on as my boxes at work are getting hammered by thousands of authentication attempts. The best solution I found that doesnt involve a lot of firewall tricks was the pam_abl module. Turn on PAM authentication in the SSHD config file usually /etc/ssh/sshd_config and add "required auth pam_abl.so" (or something like that read the docs) to /etc/pam.d/ssh. Although it wont stop the connections, what pam_abl does is auto-blacklist the host after so many failed attempts. They can still try to log in and it looks like they're authenticating but even if they have a correct username/password pair they will be denied! Its quite a nifty module. Combine that with "RootLogin no" in the sshd config file and you can feel safe that they will never break in by brute force. I use this at work on production boxes and I feel safe against this kind of attack. > Karthik Vishwanath wrote: > > Hello, > > > > As reported previously (Friday 12 August 2005, thread: > > programs/daemons/PIDs using the network), I happened to notice a lot of > > activity on the ethernet applet on my desktop. Here are lines that I > > thought looked most strange from the output of netstat -ap. What do they > > mean? For instance, does the line (from output below) > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > > ESTABLISHED > > > > mean that someone (?) had an ssh session into this machine? > > Yes. Probably some one from IP address 61.218.77.13 ... but to be sure > of that, use netatat with the -n switch. > > > last -adi does not show any untoward activity, however /var/log/auth.log > > has a whole horde of entries like: > > > > Sep 16 21:16:56 mithrandir sshd[16946]: Illegal user a from 64.91.253.157 > > Sep 16 21:16:57 mithrandir sshd[16946]: error: Could not get shadow > > information for NOUSER > > Sep 16 21:16:57 mithrandir sshd[16946]: Failed password for illegal user > > a from 64.91.253.157 > > port 60348 ssh2 > > Sep 16 21:16:57 mithrandir sshd[16948]: Illegal user b from 64.91.253.157 > > Sep 16 21:16:57 mithrandir sshd[16948]: error: Could not get shadow > > information for NOUSER > > Sep 16 21:16:57 mithrandir sshd[16948]: Failed password for illegal user > > b from 64.91.253.157 > > port 60369 ssh2 > > This records a failed login attempt. Actually, two different ones (or > maybe the same one trying to authenticate twice; depends on how you have > sshd set up) from the same IP address. > > > Must I reinstall the , to feel "safe"? > > Huh? Reinstall "the" what? > > In general, anyone trying to tell you what to do to "feel" safe is > saying more than is possible for relative strangers like us. > > But to *be* safe, I'd suggest you do the following: > > 1. Figure out how connections from external IP addresses are getting to > a private-interface address at all. Decide if there is a good reason for > having this access. If not, eliminate it (probably at your router, but I > don't know enough about your setup to be sure). > > 2. If you do need this access, make sure it is secure by > A. limiting it to reasonably safe services and their ports. ssh > qualifies as reasonably safe, for example, while telnet does not. > B. seeing to it that all accounts on the system have strong password. > > 3. Make sure you are applying security updates regularly and promptly. > (I forget what distro you use, but most have decent support for security > udating of their own packages these days.) > > 4. If this system does have direct access to the Internet somehow > (despite its using a private address, I mean), use iptables (or its > 2.6.x equivalent) to create a good firewall on the system. > > It seems that you are the victim of **attempted** breakins. I don't see > any indication in what you posted (with one possible exception; see > below) of a **successful** breakin. A successsful breakin would, of > course, call for an OS-plus-applications reinstall. > > > Thanks, regards and sorry for the long post. > > > > -K > > > > -------------------------------------- > > # netstat -ap > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50481 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49720 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50266 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49175 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51222 > > ESTABLISHED > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49928 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50040 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50811 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49506 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50706 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51029 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:48933 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:50373 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:51135 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49824 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50584 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49281 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49394 > > TIME_WAIT > > tcp 0 0 192.168.0.3:35283 galaxian.gpcc.itd.u:ssh > > ESTABLISHED > > tcp 0 0 192.168.0.3:ssh adsl-220-228-117-:49053 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50150 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:50921 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:48832 > > TIME_WAIT > > tcp 0 0 192.168.0.3:ssh 61-218-77-13.HINE:49615 > > TIME_WAIT > > udp 0 0 192.168.0.3:netbios-ns *:* > > udp 0 0 *:netbios-ns *:* > > udp 0 0 *:discard *:* > > udp 0 0 192.168.0.3:netbios-dgm *:* > > udp 0 0 *:netbios-dgm *:* > > udp 0 0 192.168.0.3:32841 ns.cmc.co.denver:domain > > ESTABLISHED > > udp 0 0 *:sunrpc *:* > > This looks to me like someone (or maybe 2 someones, since there are 2 > source addresses) is making a bunch of ssh connections and trying to > find a userid/password combo that will work. Note that all but 1 of the > ssh entries is status TIME_WAIT, which in practice means they are > terminated connections that have not timed out on your system yet. But > compare these addresses/ports to your logs to be sure of what happened. > > The other ESTABLISHED connection is an *outgoing* ssh connection. If you > don't know what that one it, then I suggest you do need to worry about a > successful penetration having occurred. > > BTW, the 61-218-77-13 address is a dialup IP address in Taiwan. The > other one is incomplete (try using the -n option) so I cannot check it > for sure, but 220-228-117-0 also is from Taiwan (probably a DSL block, > judging from the "adsl" in the name). > > - > To unsubscribe from this list: send the line "unsubscribe linux-newbie" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.linux-learn.org/faqs -- ---------------------------------------- --EB > All is fine except that I can reliably "oops" it simply by trying to read > from /proc/apm (e.g. cat /proc/apm). > oops output and ksymoops-2.3.4 output is attached. > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. --Alan Cox LKML-December 08,2000 ---------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 19:55 ` Eric Bambach @ 2005-09-18 20:10 ` Yawar Amin 2005-09-19 20:59 ` Eric Bambach 0 siblings, 1 reply; 7+ messages in thread From: Yawar Amin @ 2005-09-18 20:10 UTC (permalink / raw) To: linux-newbie On 9/19/05, Eric Bambach <eric@cisu.net> wrote: [...] > Although it wont stop the connections, what pam_abl does is auto-blacklist > the host after so many failed attempts. They can still try to log in and it > looks like they're authenticating but even if they have a correct > username/password pair they will be denied! Its quite a nifty module. [...] We're facing this problem also. We've considered auto-blacklisting hosts like you say, but what if these hosts are actually simply zombies taken over for launching brute force attacks, or external IP addresses for a whole range of NAT'd hosts, any one of which might be the attacker, and the rest innocent bystanders? You could remove them from the blacklist after a while, perhaps. Or maybe not. The problem remains: how to blacklist them very swiftly when it's decided they're trying a brute force, and then whitelist them again after a while so that nobody else suffers because of the bad guys. -- Yawar - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: understanding netstat -ap 2005-09-18 20:10 ` Yawar Amin @ 2005-09-19 20:59 ` Eric Bambach 0 siblings, 0 replies; 7+ messages in thread From: Eric Bambach @ 2005-09-19 20:59 UTC (permalink / raw) To: yawar.amin; +Cc: linux-newbie Yawar, Your concern is very valid. However in our case our range of people we want to use SSH is very small so the probability of them getting caught in the crossfire is pretty small. In regards to auto-blacklisting, I suggest you look at the module. It will auto-blacklist after a predefined limit of tries, default is 10 failed attempts per hour which I think is very generous. The default is then to blacklist them for 2 days. If you want to be more swift you could configure it to be 5 failures in 10 minutes and blacklist for 2 hours which I dont think would be too intrusive but would still thwart most attempts. Furthermore, who cares if they are zombies. An attack is an attack. If the attacker can only complete 5 guesses per 2 days he would need hundreds of thousands (if not millions) of zombies testing you at the same time to sucessfully brute force a password. Also you may not realize but this particular method REALLY messes with an attackers attempts in that he does not realize he is blacklisted. What he will end up with is huge tracts of untested space in his dictionary whereas he believes he has tested all that space. There is also a tool to unblock a user/host easily. Combine this with a php or perl frontend a user can easily unblock himself if he/she has be wrongfully blocked. The pontential benifit far outweighs an occasional accidental blocking. I think the benifits far outweigh the costs. I could see if you were a shell server with hundreds to thousands of users where the accidental blocking might cause a problem. But for any other type of server there really is no reason NOT to use pam_abl. Most servers are limited to being ssh'ed by a small set of users/administrators anyways from limited IP spaces. On Sunday 18 September 2005 03:10 pm, Yawar Amin wrote: > On 9/19/05, Eric Bambach <eric@cisu.net> wrote: > [...] > > > Although it wont stop the connections, what pam_abl does is > > auto-blacklist the host after so many failed attempts. They can still try > > to log in and it looks like they're authenticating but even if they have > > a correct username/password pair they will be denied! Its quite a nifty > > module. > > [...] > > We're facing this problem also. We've considered auto-blacklisting > hosts like you say, but what if these hosts are actually simply > zombies taken over for launching brute force attacks, or external IP > addresses for a whole range of NAT'd hosts, any one of which might be > the attacker, and the rest innocent bystanders? > > You could remove them from the blacklist after a while, perhaps. Or > maybe not. The problem remains: how to blacklist them very swiftly > when it's decided they're trying a brute force, and then whitelist > them again after a while so that nobody else suffers because of the > bad guys. -- ---------------------------------------- --EB > All is fine except that I can reliably "oops" it simply by trying to read > from /proc/apm (e.g. cat /proc/apm). > oops output and ksymoops-2.3.4 output is attached. > Is there anything else I can contribute? The latitude and longtitude of the bios writers current position, and a ballistic missile. --Alan Cox LKML-December 08,2000 ---------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-newbie" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.linux-learn.org/faqs ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-09-19 20:59 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-09-18 6:02 understanding netstat -ap Karthik Vishwanath 2005-09-18 6:07 ` Karthik Vishwanath 2005-09-18 14:59 ` Ray Olszewski 2005-09-18 18:34 ` joy merwin monteiro 2005-09-18 19:55 ` Eric Bambach 2005-09-18 20:10 ` Yawar Amin 2005-09-19 20:59 ` Eric Bambach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox