OpenSSH 3.4p1 Trouble on SCO 5.0.5? - SCO

This is a discussion on OpenSSH 3.4p1 Trouble on SCO 5.0.5? - SCO ; 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 ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

  1. OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    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

  2. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    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.

  3. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    In article <47E6160C.7080405@att.net>,
    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):


    .....

    >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

  4. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    Bill Vermillion wrote:
    > In article <47E6160C.7080405@att.net>,
    > 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):

    >
    > .....
    >
    >> 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.

  5. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    Bill Vermillion wrote:
    > In article <47E6160C.7080405@att.net>,
    > 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):

    >
    > ....
    >
    >> 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

  6. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?



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

    > Bill Vermillion wrote:
    >> In article <47E6160C.7080405@att.net>,
    >> 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):

    >>
    >> ....
    >>
    >> > 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.

  7. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    In article <47E680EC.7000005@gmail.com>,
    Nico Kadel-Garcia wrote:
    >Bill Vermillion wrote:
    >> In article <47E6160C.7080405@att.net>,
    >> 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):

    >>
    >> .....
    >>
    >>> 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

  8. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    Steve M. Fabac, Jr. wrote:
    > Bill Vermillion wrote:
    >> In article <47E6160C.7080405@att.net>,
    >> 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):

    >> ....
    >>
    >>> 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

  9. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5?

    On 25 Mar, 09:12, Rob 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.

  10. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5 -- use a VPN instead?



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

    > On 25 Mar, 09:12, Rob 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).

    >


  11. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5 -- use a VPN instead?

    On Wed, Mar 26, 2008, jd wrote:
    >
    >
    >On Wed, 26 Mar 2008, Nico Kadel-Garcia wrote:
    >
    >> On 25 Mar, 09:12, Rob 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.


    We use tcp_wrappers extensively, and absolutely require it when
    allowing username/password authentication via SSH. Normally we
    only permit authentication via authorized_keys, with good pass
    phrases, with tcp_wrappers not restricting sshd access (it's used
    for many other services).

    >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).


    OpenVPN is great -- unless one has high packet loss as it
    normally runs with UDP. I particularly like it for Windows users
    as it doesn't require that they think much to use it. We
    generate a zip file with the configuration files and keys that
    they can just drop in the correct place.

    Bill
    --
    INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    FAX: (206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676

    Those who cast the vote decide nothing.
    Those who count the vote decide everything. (Joseph Stalin)

  12. Re: OpenSSH 3.4p1 Trouble on SCO 5.0.5 -- use a VPN instead?



    On Wed, 26 Mar 2008, Bill Campbell wrote:

    > On Wed, Mar 26, 2008, jd wrote:
    >>
    >>
    >> On Wed, 26 Mar 2008, Nico Kadel-Garcia wrote:
    >>
    >>> On 25 Mar, 09:12, Rob 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.

    >
    > We use tcp_wrappers extensively, and absolutely require it when
    > allowing username/password authentication via SSH. Normally we
    > only permit authentication via authorized_keys, with good pass
    > phrases, with tcp_wrappers not restricting sshd access (it's used
    > for many other services).
    >
    >> 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).

    >
    > OpenVPN is great -- unless one has high packet loss as it
    > normally runs with UDP.


    It can run over TCP, but I am not sure why you would want to do this. If
    you get dropped packets when running TCP over TCP, which layer requests
    that the packets should be re-sent? What happens if both TCP layers
    request a re-send?

    Any VPN is not going to work well with a high packet loss, but then SSH
    probably won't work well either.

    I found a discussion on the web and the consensus seemed to be that the
    only case where using TCP for the transport layer would be sensible is
    when tunnelling a UDP protocol that requires a reliable connection (eg.
    tunnelling NFS using its default UDP protocol).
    http://www.google.com/search?q=%22Te...icial&filter=0


+ Reply to Thread