understanding netstat -ap

understanding netstat -ap

[Karthik Vishwanath]

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

Re: understanding netstat -ap

[Karthik Vishwanath]

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

Re: understanding netstat -ap

[Ray Olszewski]

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

Re: understanding netstat -ap

[joy merwin monteiro]

> 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

Re: understanding netstat -ap

[Eric Bambach]

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

Re: understanding netstat -ap

[Yawar Amin]

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

Re: understanding netstat -ap

[Eric Bambach]

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