SEO

I have a client running SCO 5.0.5 with OpenSSH 3.4p1
installed.

Since SSH was installed, we have been getting hits from
people on the Internet scanning port 22.

Normally they give up and go away. However, I have noticed
an unusual number of scans from foreign IP addresses using
valid names on the system (the names below in the block for
a single source IP are the *only* names logged from that
IP):

2008 Jan Failed adm 218.210.175.092 4
2008 Jan Failed backup 218.210.175.092 14
2008 Jan Failed bin 218.210.175.092 2
2008 Jan Failed brian 218.210.175.092 2
2008 Jan Failed cron 218.210.175.092 2
2008 Jan Failed daemon 218.210.175.092 4
2008 Jan Failed donna 218.210.175.092 4
2008 Jan Failed eric 218.210.175.092 2
2008 Jan Failed kevin 218.210.175.092 4
2008 Jan Failed lp 218.210.175.092 2
2008 Jan Failed melanie 218.210.175.092 2
2008 Jan Failed mmdf 218.210.175.092 2
2008 Jan Failed root 218.210.175.092 662
2008 Jan Failed smf 218.210.175.092 2
2008 Jan Failed test1 218.210.175.092 16
2008 Jan Failed test2 218.210.175.092 4
2008 Jan Failed uucp 218.210.175.092 2
---------
218.210.175.092 730

In the above list users smf (me), brian, donna, eric, kevin,
melanie, test1, and test2 are all valid users. Root is
also a valid user but everyone knows that and that's why
I always set "PermitRootLogin no" in sshd_config.

The above is the only example with my login included. There
are many other IP's where the same list of users appear.

2007 Nov Failed adm 061.251.191.130 7
2007 Nov Failed auth 061.251.191.130 1
2007 Nov Failed backup 061.251.191.130 3
2007 Nov Failed bin 061.251.191.130 4
2007 Nov Failed brian 061.251.191.130 2
2007 Nov Failed craig 061.251.191.130 1
2007 Nov Failed daemon 061.251.191.130 3
2007 Nov Failed dana 061.251.191.130 3
2007 Nov Failed debbie 061.251.191.130 1
2007 Nov Failed donna 061.251.191.130 2
2007 Nov Failed edward 061.251.191.130 1
2007 Nov Failed eric 061.251.191.130 2
2007 Nov Failed judy 061.251.191.130 2
2007 Nov Failed kevin 061.251.191.130 2
2007 Nov Failed lp 061.251.191.130 5
2007 Nov Failed melanie 061.251.191.130 2
2007 Nov Failed root 061.251.191.130 131
2007 Nov Failed sys 061.251.191.130 3
2007 Nov Failed uucp 061.251.191.130 3
---------
061.251.191.130 178


2008 Feb Failed adm 219.076.099.049 9
2008 Feb Failed auth 219.076.099.049 1
2008 Feb Failed backup 219.076.099.049 6
2008 Feb Failed bin 219.076.099.049 4
2008 Feb Failed brent 219.076.099.049 1
2008 Feb Failed brian 219.076.099.049 3
2008 Feb Failed craig 219.076.099.049 2
2008 Feb Failed daemon 219.076.099.049 4
2008 Feb Failed dana 219.076.099.049 1
2008 Feb Failed debbie 219.076.099.049 2
2008 Feb Failed donna 219.076.099.049 1
2008 Feb Failed edward 219.076.099.049 4
2008 Feb Failed eric 219.076.099.049 2
2008 Feb Failed judy 219.076.099.049 2
2008 Feb Failed kevin 219.076.099.049 3
2008 Feb Failed lorraine 219.076.099.049 10
2008 Feb Failed lp 219.076.099.049 11
2008 Feb Failed melanie 219.076.099.049 1
2008 Feb Failed nuucp 219.076.099.049 1
2008 Feb Failed root 219.076.099.049 138
2008 Feb Failed scottm 219.076.099.049 1
2008 Feb Failed sys 219.076.099.049 3
2008 Feb Failed test1 219.076.099.049 7
2008 Feb Failed test2 219.076.099.049 9
2008 Feb Failed uucp 219.076.099.049 4
---------
219.076.099.049 230

2007 Jul Failed adm 219.094.144.168 2
2007 Jul Failed backup 219.094.144.168 4
2007 Jul Failed bin 219.094.144.168 2
2007 Jul Failed brian 219.094.144.168 2
2007 Jul Failed daemon 219.094.144.168 2
2007 Jul Failed dana 219.094.144.168 4
2007 Jul Failed donna 219.094.144.168 2
2007 Jul Failed eric 219.094.144.168 2
2007 Jul Failed judy 219.094.144.168 2
2007 Jul Failed kevin 219.094.144.168 2
2007 Jul Failed lp 219.094.144.168 2
2007 Jul Failed melanie 219.094.144.168 2
2007 Jul Failed network 219.094.144.168 2
2007 Jul Failed root 219.094.144.168 1428
2007 Jul Failed sys 219.094.144.168 2
2008 Feb Failed backup 219.094.144.168 1
2008 Feb Failed brian 219.094.144.168 1
2008 Feb Failed daemon 219.094.144.168 1
2008 Feb Failed dana 219.094.144.168 2
2008 Feb Failed donna 219.094.144.168 1
2008 Feb Failed eric 219.094.144.168 1
2008 Feb Failed judy 219.094.144.168 1
2008 Feb Failed kevin 219.094.144.168 1
2008 Feb Failed melanie 219.094.144.168 1
2008 Feb Failed root 219.094.144.168 3226
2008 Feb Failed sys 219.094.144.168 1
---------
219.094.144.168 4697

On my 5.0.7 system I see people trying "dictionary" attacks with many
user names:

unix sshd[11062]: Failed password for invalid user *tomcat* from 62.141.56.145 por
unix sshd[11075]: Failed password for invalid user *cosinus* from 62.141.56.145 po
unix sshd[11077]: Failed password for invalid user *httpd* from 62.141.56.145 port
unix sshd[11079]: Failed password for invalid user *squirrelmail* from 62.141.56.1
unix sshd[11081]: Failed password for invalid user *trash* from 62.141.56.145 port
unix sshd[11083]: Failed password for invalid user *kent* from 62.141.56.145 port
unix sshd[11085]: Failed password for invalid user *ace* from 62.141.56.145 port 5
unix sshd[11087]: Failed password for backup from 62.141.56.145 port 54810 ssh2
unix sshd[11089]: Failed password for invalid user *fish* from 62.141.56.145 port
unix sshd[11091]: Failed password for invalid user *java* from 62.141.56.145 port
unix sshd[11093]: Failed password for invalid user *master* from 62.141.56.145 por
unix sshd[11095]: Failed password for invalid user *mysql* from 62.141.56.145 port
unix sshd[11097]: Failed password for invalid user *oracle* from 62.141.56.145 por


I don't see any of the above style attack on the client's 5.0.5 system.

The following shows repeated use of names on the system
from May 2007 to the present:

2007 May Failed brian 070.043.233.003 7
2007 May Failed craig 070.043.233.003 7
2007 May Failed kevin 070.043.233.003 6

2007 May Failed brian 192.100.197.003 7
2007 May Failed craig 192.100.197.003 7
2007 May Failed kevin 192.100.197.003 6

2007 May Failed brian 207.210.124.075 1
2007 May Failed craig 207.210.124.075 1
2007 May Failed debbie 207.210.124.075 1
2007 May Failed kevin 207.210.124.075 1

2007 May Failed brian 211.138.100.130 1
2007 May Failed craig 211.138.100.130 1
2007 May Failed debbie 211.138.100.130 1
2007 May Failed kevin 211.138.100.130 1

2007 May Failed brian 221.204.247.038 2
2007 May Failed craig 221.204.247.038 1
2007 May Failed debbie 221.204.247.038 1
2007 May Failed kevin 221.204.247.038 2

2007 Jun Failed brian 058.143.242.123 9
2007 Jun Failed craig 058.143.242.123 5
2007 Jun Failed debbie 058.143.242.123 4
2007 Jun Failed kevin 058.143.242.123 5

2007 Jun Failed brian 059.165.103.020 2
2007 Jun Failed craig 059.165.103.020 1
2007 Jun Failed debbie 059.165.103.020 1

2007 Jun Failed brian 065.116.160.056 9
2007 Jun Failed craig 065.116.160.056 5
2007 Jun Failed debbie 065.116.160.056 4
2007 Jun Failed kevin 065.116.160.056 5

2007 Jun Failed brian 065.214.140.025 7
2007 Jun Failed craig 065.214.140.025 7
2007 Jun Failed kevin 065.214.140.025 6

2007 Jun Failed brian 128.192.034.189 7
2007 Jun Failed craig 128.192.034.189 7
2007 Jun Failed kevin 128.192.034.189 6

2007 Jun Failed brian 129.025.032.067 3
2007 Jun Failed craig 129.025.032.067 3
2007 Jun Failed kevin 129.025.032.067 3

2007 Jun Failed brian 222.053.017.117 2
2007 Jun Failed craig 222.053.017.117 3
2007 Jun Failed debbie 222.053.017.117 2
2007 Jun Failed kevin 222.053.017.117 1

2007 Jul Failed brian 064.001.029.046 7
2007 Jul Failed craig 064.001.029.046 7
2007 Jul Failed kevin 064.001.029.046 9

2007 Jul Failed brian 091.121.016.113 3
2007 Jul Failed craig 091.121.016.113 3
2007 Jul Failed kevin 091.121.016.113 3

2007 Jul Failed brian 129.119.144.025 9
2007 Jul Failed craig 129.119.144.025 5
2007 Jul Failed kevin 129.119.144.025 5

2007 Jul Failed brian 207.210.096.036 1
2007 Jul Failed craig 207.210.096.036 1
2007 Jul Failed kevin 207.210.096.036 1

2007 Jul Failed brian 209.253.177.210 1
2007 Jul Failed craig 209.253.177.210 1
2007 Jul Failed kevin 209.253.177.210 1

2007 Jul Failed brian 219.094.144.168 2
2007 Jul Failed kevin 219.094.144.168 2

2007 Jul Failed debbie 129.119.144.025 4
2007 Jul Failed debbie 207.210.096.036 1

2007 Aug Failed brian 064.001.029.033 7
2007 Aug Failed craig 064.001.029.033 7
2007 Aug Failed kevin 064.001.029.033 9

2007 Aug Failed brian 195.144.225.034 7
2007 Aug Failed craig 195.144.225.034 7
2007 Aug Failed kevin 195.144.225.034 6

2007 Aug Failed brian 200.048.036.205 14
2007 Aug Failed craig 200.048.036.205 14
2007 Aug Failed kevin 200.048.036.205 14

2007 Sep Failed brian 058.150.109.244 1
2007 Sep Failed craig 058.150.109.244 1
2007 Sep Failed kevin 058.150.109.244 1
2007 Sep Failed kevin 065.214.140.025 6
2007 Sep Failed brian 065.214.140.025 7
2007 Sep Failed craig 065.214.140.025 7

2007 Sep Failed brian 066.219.102.039 1
2007 Sep Failed craig 066.219.102.039 1
2007 Sep Failed kevin 066.219.102.039 1

2007 Sep Failed brian 195.087.225.072 1
2007 Sep Failed craig 195.087.225.072 1
2007 Sep Failed kevin 195.087.225.072 1

2007 Sep Failed debbie 058.150.109.244 1
2007 Sep Failed debbie 066.219.102.039 1
2007 Sep Failed debbie 195.087.225.072 1

2007 Oct Failed brian 061.146.178.015 1
2007 Oct Failed craig 061.146.178.015 1
2007 Oct Failed kevin 061.146.178.015 1

2007 Oct Failed brian 061.152.157.166 1
2007 Oct Failed craig 061.152.157.166 1
2007 Oct Failed kevin 061.152.157.166 1

2007 Oct Failed craig 066.225.106.053 5
2007 Oct Failed kevin 066.225.106.053 5
2007 Oct Failed brian 066.225.106.053 9

2007 Oct Failed brian 074.094.178.108 1
2007 Oct Failed kevin 074.094.178.108 1

2007 Oct Failed brian 210.188.220.065 14
2007 Oct Failed craig 210.188.220.065 14
2007 Oct Failed kevin 210.188.220.065 17

2007 Oct Failed brian 216.154.223.095 7
2007 Oct Failed craig 216.154.223.095 7
2007 Oct Failed kevin 216.154.223.095 9

2007 Oct Failed debbie 061.146.178.015 1
2007 Oct Failed debbie 061.152.157.166 1
2007 Oct Failed debbie 066.225.106.053 4
2007 Oct Failed debbie 074.094.178.108 2

2007 Nov Failed brian 012.165.102.163 1
2007 Nov Failed craig 012.165.102.163 1
2007 Nov Failed kevin 012.165.102.163 1

2007 Nov Failed craig 061.251.191.130 1
2007 Nov Failed brian 061.251.191.130 2
2007 Nov Failed kevin 061.251.191.130 2

2007 Nov Failed brian 066.111.059.150 1
2007 Nov Failed craig 066.111.059.150 1
2007 Nov Failed kevin 066.111.059.150 3

2007 Nov Failed brian 201.234.032.130 1
2007 Nov Failed kevin 201.234.032.130 1

2007 Nov Failed debbie 012.165.102.163 1
2007 Nov Failed debbie 061.251.191.130 1
2007 Nov Failed debbie 201.234.032.130 1

2007 Dec Failed craig 080.093.089.163 2
2007 Dec Failed brian 080.093.089.163 4

2007 Dec Failed brian 085.234.133.053 7
2007 Dec Failed craig 085.234.133.053 7
2007 Dec Failed kevin 085.234.133.053 9

2007 Dec Failed brian 212.162.172.202 1
2007 Dec Failed craig 212.162.172.202 1
2007 Dec Failed kevin 212.162.172.202 1

2007 Dec Failed debbie 080.093.089.163 1
2007 Dec Failed debbie 085.234.133.053 1

2008 Jan Failed brian 080.087.072.003 1
2008 Jan Failed craig 080.087.072.003 1
2008 Jan Failed kevin 080.087.072.003 1

2008 Jan Failed brian 152.008.244.183 1
2008 Jan Failed craig 152.008.244.183 1
2008 Jan Failed kevin 152.008.244.183 1

2008 Jan Failed brian 202.108.034.239 23
2008 Jan Failed craig 202.108.034.239 12
2008 Jan Failed kevin 202.108.034.239 17

2008 Jan Failed debbie 080.087.072.003 1
2008 Jan Failed debbie 152.008.244.183 1
2008 Jan Failed debbie 202.108.034.239 4

2008 Feb Failed brian 065.116.031.073 1
2008 Feb Failed craig 065.116.031.073 1
2008 Feb Failed kevin 065.116.031.073 1

2008 Feb Failed kevin 071.006.202.101 12
2008 Feb Failed brian 071.006.202.101 14
2008 Feb Failed craig 071.006.202.101 14

2008 Feb Failed brian 121.015.012.009 1
2008 Feb Failed craig 121.015.012.009 1
2008 Feb Failed kevin 121.015.012.009 1

2008 Feb Failed brian 130.091.182.119 1
2008 Feb Failed kevin 130.091.182.119 1

2008 Feb Failed brian 202.196.033.230 1
2008 Feb Failed craig 202.196.033.230 1
2008 Feb Failed kevin 202.196.033.230 1

2008 Feb Failed brian 208.110.152.008 1
2008 Feb Failed craig 208.110.152.008 1
2008 Feb Failed kevin 208.110.152.008 1

2008 Feb Failed brian 211.090.075.035 9
2008 Feb Failed craig 211.090.075.035 5
2008 Feb Failed kevin 211.090.075.035 5

2008 Feb Failed brian 219.076.099.049 3
2008 Feb Failed craig 219.076.099.049 2
2008 Feb Failed kevin 219.076.099.049 3

2008 Feb Failed brian 219.094.144.168 1
2008 Feb Failed kevin 219.094.144.168 1

2008 Feb Failed brian 219.094.154.039 19
2008 Feb Failed craig 219.094.154.039 1
2008 Feb Failed kevin 219.094.154.039 19

2008 Feb Failed debbie 065.116.031.073 1
2008 Feb Failed debbie 130.091.182.119 1
2008 Feb Failed debbie 211.090.075.035 4
2008 Feb Failed debbie 219.076.099.049 2

2008 Mar Failed brian 069.064.069.134 2
2008 Mar Failed craig 069.064.069.134 2
2008 Mar Failed kevin 069.064.069.134 2


This is the count of individual IP addresses by
country that were logged since May 2007:

country: AL Count = 1 TELECOM ALBANIA
country: AR Count = 2 Argentina
country: AU Count = 9 Australia
country: BR Count = 6 Brasil
country: CA Count = 3 Canada
country: CH Count = 1
country: CI Count = 1
country: CL Count = 3 Chile
country: CN Count = 161 China
country: CO Count = 6 Colombia
country: CZ Count = 1
country: DE Count = 7 Germany
country: DK Count = 1
country: EC Count = 3
country: EG Count = 1
country: ES Count = 4
country: EU Count = 1
country: FR Count = 8 France
country: GB Count = 10 England
country: HK Count = 9 Hong Kong SAR, China
country: HU Count = 2
country: ID Count = 2
country: IE Count = 1
country: IL Count = 1
country: IN Count = 10 India
country: IT Count = 8 Italy
country: JP Count = 18 Japan
country: KR Count = 32 Korea
country: MA Count = 2
country: MN Count = 1
country: MO Count = 1
country: MX Count = 4
country: MY Count = 2
country: NL Count = 3
country: NO Count = 1
country: NZ Count = 1
country: PA Count = 1
country: PE Count = 4
country: PH Count = 2
country: PK Count = 2
country: PL Count = 6
country: PT Count = 1
country: RO Count = 5
country: RU Count = 3
country: SA Count = 1
country: SE Count = 4
country: SG Count = 1
country: TH Count = 9 Thailand
country: TR Count = 2
country: TW Count = 20 Taiwan
country: US Count = 68 United States
country: UY Count = 3
country: VE Count = 1
country: ZA Count = 1

Anybody have any ideas, thoughts or comments on this?
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670

Steve M. Fabac, Jr. wrote:
> I have a client running SCO 5.0.5 with OpenSSH 3.4p1
> installed.
>
> Since SSH was installed, we have been getting hits from
> people on the Internet scanning port 22.
>
> Normally they give up and go away. However, I have noticed
> an unusual number of scans from foreign IP addresses using
> valid names on the system (the names below in the block for
> a single source IP are the *only* names logged from that
> IP):

Are you running an SMTP server that can be probed for valid addresses? A lot
of those are common system names, as well. Someone could have gotten a valid
/etc/passwd list by any of a number of other means, published it, and be
probing them with their rootkit tools.

However, 5.0.5 is way out of date. It has no, and I mean *NO* business having
any direct exposure to the Internet. If you have to run services like SSH to
it, it should be through an external firewall with some sort of logging, and
preferably not run popular services like SSH on port 22.


>
> Anybody have any ideas, thoughts or comments on this?

It looks like normal port scanning by crackers. Any machine exposed to the
Internet will see this sort of scanning, with the caveat that the user names
may be obtained from some other source (such as public email addresses off of
the web) or may be from random guessing of likely first-name addresses.

In article <47E6160C.7080405@att.net>,
Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>installed.

>Since SSH was installed, we have been getting hits from
>people on the Internet scanning port 22.

>Normally they give up and go away. However, I have noticed
>an unusual number of scans from foreign IP addresses using
>valid names on the system (the names below in the block for
>a single source IP are the *only* names logged from that
>IP):

.....

>Anybody have any ideas, thoughts or comments on this?

I've seen as high as 10,000 such attemts per day - but these are
on mail and web servers directly connected to a tier 1 backbone
[level 3] in their Orlando colo. They actually switch [not route]
connections across the US so I can see 1 hop from Orlando to
Seattle - that's one reason they carry about 60% of the 'net
traffic.

But as Nico said in his reply to you, you really shouldn't put SCO
on a directly connected internet.

IMO the ONLY machines that should be do so would be machines
that MUST be connected - eg mail servers and web servers. All
other machines should be behind a firewall.

Ideally 3 NIC cards connected to SWITCHES not hubs, would
have a public access IP, and those sould connect to the second set
[A DMZ area] with such things as your web servers, and the 3rd
NIC would go to your business machines on a totally private network
so nothing from the outside world would ever get through.

It's easy and cheap to set up a separate mail/web server
and keep you important machines hidden. I run on FreeBSD since
swithcing an ISP from SGIs back in 1995 and it can run on a slim
machine and is awfully solid.

If you think you are seeing a lot of attacks, just wait - they get
more numerous as time goes by.

Bill

--
Bill Vermillion - bv @ wjv . com

Bill Vermillion wrote:
> In article <47E6160C.7080405@att.net>,
> Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>> I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>> installed.
>
>> Since SSH was installed, we have been getting hits from
>> people on the Internet scanning port 22.
>
>> Normally they give up and go away. However, I have noticed
>> an unusual number of scans from foreign IP addresses using
>> valid names on the system (the names below in the block for
>> a single source IP are the *only* names logged from that
>> IP):
>
> .....
>
>> Anybody have any ideas, thoughts or comments on this?
>
> I've seen as high as 10,000 such attemts per day - but these are
> on mail and web servers directly connected to a tier 1 backbone
> [level 3] in their Orlando colo. They actually switch [not route]
> connections across the US so I can see 1 hop from Orlando to
> Seattle - that's one reason they carry about 60% of the 'net
> traffic.
>
> But as Nico said in his reply to you, you really shouldn't put SCO
> on a directly connected internet.
>
> IMO the ONLY machines that should be do so would be machines
> that MUST be connected - eg mail servers and web servers. All
> other machines should be behind a firewall.
>
> Ideally 3 NIC cards connected to SWITCHES not hubs, would
> have a public access IP, and those sould connect to the second set
> [A DMZ area] with such things as your web servers, and the 3rd
> NIC would go to your business machines on a totally private network
> so nothing from the outside world would ever get through.
>
> It's easy and cheap to set up a separate mail/web server
> and keep you important machines hidden. I run on FreeBSD since
> swithcing an ISP from SGIs back in 1995 and it can run on a slim
> machine and is awfully solid.
>
> If you think you are seeing a lot of attacks, just wait - they get
> more numerous as time goes by.

True. And in further thinking about this, I'd counsel doing something to
reduce the number of spurious logs to deal with. Switching the SSH port to,
say, 1022 and making sure there are no other services on it would help reduce
the logging of such attempts, and leave much less debris in your logs.

Bill Vermillion wrote:
> In article <47E6160C.7080405@att.net>,
> Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>> I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>> installed.
>
>> Since SSH was installed, we have been getting hits from
>> people on the Internet scanning port 22.
>
>> Normally they give up and go away. However, I have noticed
>> an unusual number of scans from foreign IP addresses using
>> valid names on the system (the names below in the block for
>> a single source IP are the *only* names logged from that
>> IP):
>
> ....
>
>> Anybody have any ideas, thoughts or comments on this?
>
> I've seen as high as 10,000 such attemts per day - but these are
> on mail and web servers directly connected to a tier 1 backbone
> [level 3] in their Orlando colo. They actually switch [not route]
> connections across the US so I can see 1 hop from Orlando to
> Seattle - that's one reason they carry about 60% of the 'net
> traffic.
>
> But as Nico said in his reply to you, you really shouldn't put SCO
> on a directly connected internet.

Bill,

I neglected to indicate that the machine is behind a firewall and port
22 is forwarded from the public IP address to the LAN IP address of
the box.

>
> IMO the ONLY machines that should be do so would be machines
> that MUST be connected - eg mail servers and web servers. All
> other machines should be behind a firewall.
>
> Ideally 3 NIC cards connected to SWITCHES not hubs, would
> have a public access IP, and those sould connect to the second set
> [A DMZ area] with such things as your web servers, and the 3rd
> NIC would go to your business machines on a totally private network
> so nothing from the outside world would ever get through.
>
> It's easy and cheap to set up a separate mail/web server
> and keep you important machines hidden. I run on FreeBSD since
> swithcing an ISP from SGIs back in 1995 and it can run on a slim
> machine and is awfully solid.
>
> If you think you are seeing a lot of attacks, just wait - they get
> more numerous as time goes by.
>
> Bill
>

I have taken the steps to change from the default ssh port of 22 to
a high port number and that has stopped the repeated probes for now.
We have discussed this in the past and you have indicated that you have
seen ssh probes on high port numbers. We will cross that bridge if/when
it occurs.

Further tests show that my concerns were unwarranted as ssh 3.4p1
installed on 5.0.5 does not log attempts with unknown user names.
Thus the log only contains *hits* when the dictionary attack matches
an existing user's login name.

--
Steve Fabac
S.M. Fabac & Associates
816/765-1670

On Sun, 23 Mar 2008, Steve M. Fabac, Jr. wrote:

> Bill Vermillion wrote:
>> In article <47E6160C.7080405@att.net>,
>> Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>> > I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>> > installed.
>>
>> > Since SSH was installed, we have been getting hits from
>> > people on the Internet scanning port 22.
>>
>> > Normally they give up and go away. However, I have noticed
>> > an unusual number of scans from foreign IP addresses using
>> > valid names on the system (the names below in the block for
>> > a single source IP are the *only* names logged from that
>> > IP):
>>
>> ....
>>
>> > Anybody have any ideas, thoughts or comments on this?
>>
>> I've seen as high as 10,000 such attemts per day - but these are
>> on mail and web servers directly connected to a tier 1 backbone
>> [level 3] in their Orlando colo. They actually switch [not route]
>> connections across the US so I can see 1 hop from Orlando to
>> Seattle - that's one reason they carry about 60% of the 'net
>> traffic.
>>
>> But as Nico said in his reply to you, you really shouldn't put SCO
>> on a directly connected internet.
>
> Bill,
>
> I neglected to indicate that the machine is behind a firewall and port
> 22 is forwarded from the public IP address to the LAN IP address of
> the box.

Using Netfilter/Iptables under Linux, it is easy to limit the rate at
which new connections are made to the SSH server, while leaving existing
connections unaffected. This is very powerful against dictionary attacks,
which have been going on against SSH servers for 3-4 years now.

I believe that the *BSD OSes have similar capabilities.

You are using a recent version of OpenSSH, but are you using a version of
OpenSSL? There have been vulnerabilities in OpenSSL in recent the past.

In article <47E680EC.7000005@gmail.com>,
Nico Kadel-Garcia <nkadel@gmail.com> wrote:
>Bill Vermillion wrote:
>> In article <47E6160C.7080405@att.net>,
>> Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>>> I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>>> installed.
>>
>>> Since SSH was installed, we have been getting hits from
>>> people on the Internet scanning port 22.
>>
>>> Normally they give up and go away. However, I have noticed
>>> an unusual number of scans from foreign IP addresses using
>>> valid names on the system (the names below in the block for
>>> a single source IP are the *only* names logged from that
>>> IP):
>>
>> .....
>>
>>> Anybody have any ideas, thoughts or comments on this?
>>
>> I've seen as high as 10,000 such attemts per day - but these are
>> on mail and web servers directly connected to a tier 1 backbone
>> [level 3] in their Orlando colo. They actually switch [not route]
>> connections across the US so I can see 1 hop from Orlando to
>> Seattle - that's one reason they carry about 60% of the 'net
>> traffic.
>>
>> But as Nico said in his reply to you, you really shouldn't put SCO
>> on a directly connected internet.
>>
>> IMO the ONLY machines that should be do so would be machines
>> that MUST be connected - eg mail servers and web servers. All
>> other machines should be behind a firewall.
>>
>> Ideally 3 NIC cards connected to SWITCHES not hubs, would
>> have a public access IP, and those sould connect to the second set
>> [A DMZ area] with such things as your web servers, and the 3rd
>> NIC would go to your business machines on a totally private network
>> so nothing from the outside world would ever get through.
>>
>> It's easy and cheap to set up a separate mail/web server
>> and keep you important machines hidden. I run on FreeBSD since
>> swithcing an ISP from SGIs back in 1995 and it can run on a slim
>> machine and is awfully solid.
>>
>> If you think you are seeing a lot of attacks, just wait - they get
>> more numerous as time goes by.

>True. And in further thinking about this, I'd counsel doing
>something to reduce the number of spurious logs to deal with.
>Switching the SSH port to, say, 1022 and making sure there are
>no other services on it would help reduce the logging of such
>attempts, and leave much less debris in your logs.

That may help a little but I see scans across all the ports in
the daily security logs.

Bill


--
Bill Vermillion - bv @ wjv . com

Steve M. Fabac, Jr. wrote:
> Bill Vermillion wrote:
>> In article <47E6160C.7080405@att.net>,
>> Steve M. Fabac, Jr. <smfabac@att.net> wrote:
>>> I have a client running SCO 5.0.5 with OpenSSH 3.4p1
>>> installed.
>>> Since SSH was installed, we have been getting hits from
>>> people on the Internet scanning port 22.
>>> Normally they give up and go away. However, I have noticed
>>> an unusual number of scans from foreign IP addresses using
>>> valid names on the system (the names below in the block for
>>> a single source IP are the *only* names logged from that
>>> IP):
>> ....
>>
>>> Anybody have any ideas, thoughts or comments on this?

Steve,

what about using tcp_wrappers as to perform a "route delete" on the offending IP?

If memory serves, there was a porting of tcp_wrapper for SCO OS5 on a TLS076a
on the FTP site:

ftp://ftp.sco.com/pub/TLS/tls076a.tcp_wrappers.tar.Z

Hope this helps!

Ciao,
Rob

On 25 Mar, 09:12, Rob <r...@nothere.com> wrote:

> Steve,
>
> what about using tcp_wrappers as to perform a "route delete" on the offending IP?
>
> If memory serves, there was a porting of tcp_wrapper for SCO OS5 on a TLS076a
> on the FTP site:
>
> ftp://ftp.sco.com/pub/TLS/tls076a.tcp_wrappers.tar.Z
>
> Hope this helps!

If our faithful here only needs SSH access from a small set of well-
maintained sites, that might work well. However, if he has clients who
use NAT on their ISP networks (such as AOL, which uses 10.* internal
addresses), than the tcp_wrapper will block the NAT and everything
behind the NAT server.

On Wed, 26 Mar 2008, Nico Kadel-Garcia wrote:

> On 25 Mar, 09:12, Rob <r...@nothere.com> wrote:
>
>> Steve,
>>
>> what about using tcp_wrappers as to perform a "route delete" on the offending IP?
>>
>> If memory serves, there was a porting of tcp_wrapper for SCO OS5 on a TLS076a
>> on the FTP site:
>>
>> ftp://ftp.sco.com/pub/TLS/tls076a.tcp_wrappers.tar.Z
>>
>> Hope this helps!
>
> If our faithful here only needs SSH access from a small set of well-
> maintained sites, that might work well. However, if he has clients who
> use NAT on their ISP networks (such as AOL, which uses 10.* internal
> addresses), than the tcp_wrapper will block the NAT and everything
> behind the NAT server.

Then perhaps a VPN (such as OpenVPN) is a more appropriate solution for
remote access, instead of SSH (although SSH can be used over the VPN).

>