SCO Routing Behavior - SCO

This is a discussion on SCO Routing Behavior - SCO ; Hello all... having a strange issue where an older SCO installation (used by Avaya for voicemail) is adding dynamic routes that in some cases are overriding the default gateway and causing network issues until we clear them out manually. Neither ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: SCO Routing Behavior

  1. SCO Routing Behavior

    Hello all... having a strange issue where an older SCO installation
    (used by Avaya for voicemail) is adding dynamic routes that in some
    cases are overriding the default gateway and causing network issues
    until we clear them out manually.

    Neither gated nor routed are running on this system.

    I believe this is a 2.5.x release of SCO/UnixWare...

    Can anyone think of any default SCO network behavior that might result
    in the automatic addition of routes? The routes are showing up with
    the dynamically added flag (D), but as I said I can't find any
    (default) daemon running that would do this.

    Perhaps there is an Avaya specific app that is causing the issue.
    Avaya hasn't been too helpful -- I fear they don't have any SCO gurus
    around any longer. In any case, I wanted to eliminate the obvious OS-
    level configuration stuff. Would something in the SCO kernel
    networking subsystem be used to do some sort of dynamic route
    addition?

    Where should I check?

    Thanks in advance...


  2. Re: SCO Routing Behavior

    On 4 Jul, 01:02, rayvd wrote:
    > Hello all... having a strange issue where an older SCO installation
    > (used by Avaya for voicemail) is adding dynamic routes that in some
    > cases are overriding the default gateway and causing network issues
    > until we clear them out manually.
    >
    > Neither gated nor routed are running on this system.
    >
    > I believe this is a 2.5.x release of SCO/UnixWare...
    >
    > Can anyone think of any default SCO network behavior that might result
    > in the automatic addition of routes? The routes are showing up with
    > the dynamically added flag (D), but as I said I can't find any
    > (default) daemon running that would do this.
    >
    > Perhaps there is an Avaya specific app that is causing the issue.
    > Avaya hasn't been too helpful -- I fear they don't have any SCO gurus
    > around any longer. In any case, I wanted to eliminate the obvious OS-
    > level configuration stuff. Would something in the SCO kernel
    > networking subsystem be used to do some sort of dynamic route
    > addition?


    Ray,

    My guess is that what is underneath this Avaya solution is a
    UnixWare 2.1.x OS. How customised it is, I wouldnt know as this
    is an Avaya supported system.

    This is a very old (pre 1995) OS and we no longer publish the
    doc for the product. You can look at the UnixWare 7 doc at:

    http://www.sco.com/support/docs/unixware/

    but I am not sure how compatible they are in terms of their
    routing implementation.

    John





  3. Re: SCO Routing Behavior

    In article <1183507375.861980.16830@d30g2000prg.googlegroups.c om>,
    rayvd wrote:
    >Hello all... having a strange issue where an older SCO installation
    >(used by Avaya for voicemail) is adding dynamic routes that in some
    >cases are overriding the default gateway and causing network issues
    >until we clear them out manually.
    >
    >Neither gated nor routed are running on this system.
    >
    >I believe this is a 2.5.x release of SCO/UnixWare...
    >
    >Can anyone think of any default SCO network behavior that might result
    >in the automatic addition of routes? The routes are showing up with
    >the dynamically added flag (D), but as I said I can't find any
    >(default) daemon running that would do this.


    Even without a routing daemon running, the routing table can be updated
    by ICMP redirects. You might wish to monitor your network for such.

    John
    --
    John DuBois spcecdt@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/

  4. Re: SCO Routing Behavior

    On Jul 4, 8:42 am, spce...@armory.com (John DuBois) wrote:
    > Even without a routing daemon running, the routing table can be updated
    > by ICMP redirects. You might wish to monitor your network for such.


    This is likely the issue. Is there a way to disable this behavior
    in the SCO networking subsystem?

    If not, we'll have to look at other solutions. It seems that SCO is
    happy to add a route based on an ICMP redirect for 10.0.0.0/8 which
    pretty much wipes out connectivity for us. :-)

    Thanks!
    Ray


  5. Re: SCO Routing Behavior


    ----- Original Message -----
    From: "rayvd"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Thursday, July 05, 2007 11:41 AM
    Subject: Re: SCO Routing Behavior


    > On Jul 4, 8:42 am, spce...@armory.com (John DuBois) wrote:
    >> Even without a routing daemon running, the routing table can be updated
    >> by ICMP redirects. You might wish to monitor your network for such.

    >
    > This is likely the issue. Is there a way to disable this behavior
    > in the SCO networking subsystem?
    >
    > If not, we'll have to look at other solutions. It seems that SCO is
    > happy to add a route based on an ICMP redirect for 10.0.0.0/8 which
    > pretty much wipes out connectivity for us. :-)
    >
    > Thanks!
    > Ray



    You can probably block them with ipf.

    Put this in /etc/ipf.conf (create if necessary)

    block in quick on net0 proto icmp from any to any icmp-type redir

    replace net0 with whatever your nic's device name is, see the output of
    ifconfig -a

    start ipfnat manually to see if it works:
    /etc/init.d/ipfnat start

    if it's good then put it into rc2.d so it happens at boot:
    ln -s /etc/init.d/ipfnat /etc/rc2.d/S86ipfnat

    If you have osr 506 or later then you have ipf already.
    If you have osr 505, then you can install ipf via TLS709.
    If you have earlier than 505, you need to install OSS449F first, then
    TLS709.

    ftp://ftp.sco.com/pub/TLS/tls709.ltr
    ftp://ftp.sco.com/pub/TLS/tls709.tar.Z

    --
    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  6. Re: SCO Routing Behavior

    "Brian K. White" wrote:
    >
    > ----- Original Message -----
    > From: "rayvd"
    > Newsgroups: comp.unix.sco.misc
    > To:
    > Sent: Thursday, July 05, 2007 11:41 AM
    > Subject: Re: SCO Routing Behavior
    >
    > > On Jul 4, 8:42 am, spce...@armory.com (John DuBois) wrote:
    > >> Even without a routing daemon running, the routing table can be updated
    > >> by ICMP redirects. You might wish to monitor your network for such.

    > >
    > > This is likely the issue. Is there a way to disable this behavior
    > > in the SCO networking subsystem?
    > >
    > > If not, we'll have to look at other solutions. It seems that SCO is
    > > happy to add a route based on an ICMP redirect for 10.0.0.0/8 which
    > > pretty much wipes out connectivity for us. :-)
    > >
    > > Thanks!
    > > Ray

    >
    > You can probably block them with ipf.
    >
    > Put this in /etc/ipf.conf (create if necessary)
    >
    > block in quick on net0 proto icmp from any to any icmp-type redir
    >
    > replace net0 with whatever your nic's device name is, see the output of
    > ifconfig -a
    >
    > start ipfnat manually to see if it works:
    > /etc/init.d/ipfnat start


    Brian,

    Should you start ipfnat if you have not run mkfilters > /etc/ipf.conf
    to generate the basic rule set?

    I do use ipf but have never run ipfnat, just the command:
    /etc/ipf -Fa -f /etc/ipf.conf

    Actually, the command I use is from an awk script I wrote to
    analyze the /usr/adm/syslog entries for sshd and update
    iff.conf with the ip address of anyone trying ssh on
    my (or my client's) system with over 20 entries in the last
    200 lines of /usr/adm/syslog.

    tail -200 /usr/adm/syslog | grep sshd | egrep "Invalid|Failed password for root
    " | sed -e 's/.*from //' -e 's/ port.*//' \
    | awk ' BEGIN {

    ......

    printf"block in log quick from %s to any port = 22\n", i >> "/etc/ipf.conf"
    printf"Added ipf block on port 22 from %s for SSH abuse\n", i >> "/tmp/SSH_Abuse_logger"
    system( "/etc/ipf -Fa -f /etc/ipf.conf" )

    This appends /etc/ipf.conf as:
    block in log quick from 218.244.130.46 to any port = 22
    block in log quick from 163.18.62.53 to any port = 22
    block in log quick from 207.210.91.154 to any port = 22

    Jul 3 20:26:55 unix sshd[15520]: Failed password for invalid user administrator from 218.244.130.46 port 44709 ssh2
    Jul 3 20:26:57 unix sshd[15522]: Invalid user library from 218.244.130.46
    Jul 3 20:26:57 unix sshd[15522]: Failed password for invalid user library from 218.244.130.46 port 44990 ssh2
    Jul 3 20:26:59 unix sshd[15524]: Invalid user test from 218.244.130.46
    Jul 3 20:26:59 unix sshd[15524]: Failed password for invalid user test from 218.244.130.46 port 45175 ssh2
    Jul 3 20:27:01 unix SSHCHECK: Added ipf block on port 22 from 218.244.130.46 for SSH abuse
    Jul 3 20:29:00 unix sshd[15526]: fatal: Timeout before authentication for 218.244.130.46
    ......
    Jul 4 12:37:56 unix sshd[29493]: Failed password for root from 163.18.62.53 port 37770 ssh2
    Jul 4 12:37:57 unix sshd[29495]: Failed password for root from 163.18.62.53 port 39828 ssh2
    Jul 4 12:37:59 unix sshd[29497]: Failed password for root from 163.18.62.53 port 40315 ssh2
    Jul 4 12:38:01 unix SSHCHECK: Added ipf block on port 22 from 163.18.62.53 for SSH abuse
    Jul 4 12:40:00 unix sshd[29500]: fatal: Timeout before authentication for 163.18.62.53
    ....
    Jul 5 06:06:59 unix sshd[14482]: Failed password for root from 207.210.91.154 port 41428 ssh2
    Jul 5 06:07:00 unix sshd[14484]: Failed password for root from 207.210.91.154 port 41484 ssh2
    Jul 5 06:07:01 unix sshd[14486]: Failed password for root from 207.210.91.154 port 41544 ssh2
    Jul 5 06:07:01 unix SSHCHECK: Added ipf block on port 22 from 207.210.91.154 for SSH abuse
    Jul 5 06:09:01 unix sshd[14499]: fatal: Timeout before authentication for 207.210.91.154

    /usr/bin/lock_sshd runs every minute of the day from cron and has
    added 300 ip addresses to the basic "mkfilters > ipf.conf" file
    since I wrote and installed it Sep 18, 2006.

    I have to customize lock_sshd for some of my client's systems
    as "Invalid user" becomes "Illegal user" depending on the
    version of ssh installed on their system.


    >
    > if it's good then put it into rc2.d so it happens at boot:
    > ln -s /etc/init.d/ipfnat /etc/rc2.d/S86ipfnat
    >
    > If you have osr 506 or later then you have ipf already.
    > If you have osr 505, then you can install ipf via TLS709.
    > If you have earlier than 505, you need to install OSS449F first, then
    > TLS709.
    >
    > ftp://ftp.sco.com/pub/TLS/tls709.ltr
    > ftp://ftp.sco.com/pub/TLS/tls709.tar.Z
    >
    > --
    > Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    > +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    > filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!



    --

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

  7. Re: SCO Routing Behavior


    ----- Original Message -----
    From: "Steve M. Fabac, Jr."
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Thursday, July 05, 2007 6:43 PM
    Subject: Re: SCO Routing Behavior


    > "Brian K. White" wrote:
    >>
    >> ----- Original Message -----
    >> From: "rayvd"
    >> Newsgroups: comp.unix.sco.misc
    >> To:
    >> Sent: Thursday, July 05, 2007 11:41 AM
    >> Subject: Re: SCO Routing Behavior
    >>
    >> > On Jul 4, 8:42 am, spce...@armory.com (John DuBois) wrote:
    >> >> Even without a routing daemon running, the routing table can be
    >> >> updated
    >> >> by ICMP redirects. You might wish to monitor your network for such.
    >> >
    >> > This is likely the issue. Is there a way to disable this behavior
    >> > in the SCO networking subsystem?
    >> >
    >> > If not, we'll have to look at other solutions. It seems that SCO is
    >> > happy to add a route based on an ICMP redirect for 10.0.0.0/8 which
    >> > pretty much wipes out connectivity for us. :-)
    >> >
    >> > Thanks!
    >> > Ray

    >>
    >> You can probably block them with ipf.
    >>
    >> Put this in /etc/ipf.conf (create if necessary)
    >>
    >> block in quick on net0 proto icmp from any to any icmp-type redir
    >>
    >> replace net0 with whatever your nic's device name is, see the output of
    >> ifconfig -a
    >>
    >> start ipfnat manually to see if it works:
    >> /etc/init.d/ipfnat start

    >
    > Brian,
    >
    > Should you start ipfnat if you have not run mkfilters > /etc/ipf.conf
    > to generate the basic rule set?
    >
    > I do use ipf but have never run ipfnat, just the command:
    > /etc/ipf -Fa -f /etc/ipf.conf


    Unless a rule is bad, of course it doesn't hurt.

    The ipfnat start script just looks for the existence of /etc/ipf.conf and
    /etc/ipnat.conf
    If either/both exists, then it starts up the appropriate ipf or ipnat or
    both.

    Right now, he either has no rules at all, or he has some, either way adding
    a rule (assuming it's not bad) doesn't hurt anything. Granted an ipf.conf
    with nothing but that one rule doesn't do much, but, his was just to take
    his existing state of being and change it in no other way than to block this
    problem traffic. Securing a box with ipf is a whole different, large,
    non-trivial, complex, discussion of it's own, and is not what he asked for
    help with.

    In any event, since I failed to notice he said Unixware, the general idea
    may still apply if Unixware has ipf/ipnat, but the exact file names and
    start script behaviour probably do not.

    > Actually, the command I use is from an awk script I wrote to
    > analyze the /usr/adm/syslog entries for sshd and update
    > iff.conf with the ip address of anyone trying ssh on
    > my (or my client's) system with over 20 entries in the last
    > 200 lines of /usr/adm/syslog.
    >
    > tail -200 /usr/adm/syslog | grep sshd | egrep "Invalid|Failed password
    > for root
    > " | sed -e 's/.*from //' -e 's/ port.*//' \
    > | awk ' BEGIN {
    >
    > .....
    >
    > printf"block in log quick from %s to any port = 22\n", i >>
    > "/etc/ipf.conf"
    > printf"Added ipf block on port 22 from %s for SSH abuse\n", i >>
    > "/tmp/SSH_Abuse_logger"
    > system( "/etc/ipf -Fa -f /etc/ipf.conf" )
    >
    > This appends /etc/ipf.conf as:
    > block in log quick from 218.244.130.46 to any port = 22
    > block in log quick from 163.18.62.53 to any port = 22
    > block in log quick from 207.210.91.154 to any port = 22
    >
    > Jul 3 20:26:55 unix sshd[15520]: Failed password for invalid user
    > administrator from 218.244.130.46 port 44709 ssh2
    > Jul 3 20:26:57 unix sshd[15522]: Invalid user library from 218.244.130.46
    > Jul 3 20:26:57 unix sshd[15522]: Failed password for invalid user library
    > from 218.244.130.46 port 44990 ssh2
    > Jul 3 20:26:59 unix sshd[15524]: Invalid user test from 218.244.130.46
    > Jul 3 20:26:59 unix sshd[15524]: Failed password for invalid user test
    > from 218.244.130.46 port 45175 ssh2
    > Jul 3 20:27:01 unix SSHCHECK: Added ipf block on port 22 from
    > 218.244.130.46 for SSH abuse
    > Jul 3 20:29:00 unix sshd[15526]: fatal: Timeout before authentication for
    > 218.244.130.46
    > .....
    > Jul 4 12:37:56 unix sshd[29493]: Failed password for root from
    > 163.18.62.53 port 37770 ssh2
    > Jul 4 12:37:57 unix sshd[29495]: Failed password for root from
    > 163.18.62.53 port 39828 ssh2
    > Jul 4 12:37:59 unix sshd[29497]: Failed password for root from
    > 163.18.62.53 port 40315 ssh2
    > Jul 4 12:38:01 unix SSHCHECK: Added ipf block on port 22 from
    > 163.18.62.53 for SSH abuse
    > Jul 4 12:40:00 unix sshd[29500]: fatal: Timeout before authentication for
    > 163.18.62.53
    > ...
    > Jul 5 06:06:59 unix sshd[14482]: Failed password for root from
    > 207.210.91.154 port 41428 ssh2
    > Jul 5 06:07:00 unix sshd[14484]: Failed password for root from
    > 207.210.91.154 port 41484 ssh2
    > Jul 5 06:07:01 unix sshd[14486]: Failed password for root from
    > 207.210.91.154 port 41544 ssh2
    > Jul 5 06:07:01 unix SSHCHECK: Added ipf block on port 22 from
    > 207.210.91.154 for SSH abuse
    > Jul 5 06:09:01 unix sshd[14499]: fatal: Timeout before authentication for
    > 207.210.91.154
    >
    > /usr/bin/lock_sshd runs every minute of the day from cron and has
    > added 300 ip addresses to the basic "mkfilters > ipf.conf" file
    > since I wrote and installed it Sep 18, 2006.
    >
    > I have to customize lock_sshd for some of my client's systems
    > as "Invalid user" becomes "Illegal user" depending on the
    > version of ssh installed on their system.


    Thats pretty slick!

    I'm always wary of putting rules in ipf.conf since I've read that it's easy
    to cause terrible performance from having too many rules and even more from
    inexpertly designed rules. There are interactions between rules that aren't
    always easy to recognize. I guess a stack of simple blocks shouldn't hurt
    until the stack gets very large. Probably depends on the cpu and workload of
    the machine exactly how much stuff you can get away with putting in there
    before the network or cpu starts to show performance degradation.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  8. Re: SCO Routing Behavior

    Brian K. White wrote:

    > I'm always wary of putting rules in ipf.conf since I've read that it's easy
    > to cause terrible performance from having too many rules


    I have a box in the Internet, and the number of SSH attempts on it was
    just too big to put them all into the firewall. So I chose a poor man's
    solution, which has worked out surprisingly well: i made sshd listen on
    a non-standard port, like 34543 or some such. So far, zero illegitimate
    ssh attempts!

  9. Re: SCO Routing Behavior

    In article , Pepe wrote:
    >Brian K. White wrote:
    >
    >> I'm always wary of putting rules in ipf.conf since I've read that it's easy
    >> to cause terrible performance from having too many rules


    >I have a box in the Internet, and the number of SSH attempts on
    >it was just too big to put them all into the firewall. So I chose
    >a poor man's solution, which has worked out surprisingly well: i
    >made sshd listen on a non-standard port, like 34543 or some such.
    >So far, zero illegitimate ssh attempts!


    I was just reviewing the daily messages on a mail-server I
    maintain, and I see at least 12 attempts yesterday on non-standard
    ports with an ssh attempt. You will eventually see them.

    And my server is on a 100Mb/sec link into a 40Gb/sec network, so
    when I get hit, I can get hit hard. We had a client who wasn't
    running proper virus/spam software, and got into a spambot. I was
    getting mail in for them at the rate of 15/second, which virtually
    killed the machine with all the other legitimate mail coming in.
    They got removed in a hurry. I had over 100,000 messages in
    the mail queue when I caught it.

    Be sure to monitor everything when you are directly connected.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  10. Re: SCO Routing Behavior

    Bill Vermillion wrote:
    >
    > In article , Pepe wrote:
    > >Brian K. White wrote:
    > >
    > >> I'm always wary of putting rules in ipf.conf since I've read that it's easy
    > >> to cause terrible performance from having too many rules

    >
    > >I have a box in the Internet, and the number of SSH attempts on
    > >it was just too big to put them all into the firewall.


    319 IP addresses and counting in ipf.conf on the client's system reported below
    since Sep 20, 2006.

    > > So I chose
    > >a poor man's solution, which has worked out surprisingly well: i
    > >made sshd listen on a non-standard port, like 34543 or some such.
    > >So far, zero illegitimate ssh attempts!


    I have used that technique as well for a client where they refuse to assign
    passwords on their user's accounts. So far so good.

    The first time I saw a break-in on a client's system was March 23, 2005 when I was
    reviewing the BackupEdge logs looking for the reason the nightly backup was
    classified as a failure and stumbled upon a hidden sub directory
    under /tmp. The perpetrator had created the hidden directory and uploaded
    wownew.tgz on March 19. On my client's systems, I maintain 10 weeks of
    wtmp logs and went looking for the first time the perpetrator found the
    system. That turns out to be January 28, 2005 with numerous log in on
    Feb 1, Feb 20, Mar 4, Mar 12, Mar 15, Mar 17, Mar 19, Mar 22 and Mar 23.
    I disabled the temp account on Mar 23 and there were no further login's.

    I examined wownew.tgz and found the source code distribution of bouncer,
    targeted for Linux systems. The bad guy never got it installed as the
    system SCO UNIX 5.0.7 and does not have a C Compiler.

    The moral: Make sure all you accounts have proper passwords.


    >
    > I was just reviewing the daily messages on a mail-server I
    > maintain, and I see at least 12 attempts yesterday on non-standard
    > ports with an ssh attempt. You will eventually see them.


    Bill, can you post the ports that were tried? I'd like to avoid them
    if at all possible.

    >
    > And my server is on a 100Mb/sec link into a 40Gb/sec network, so
    > when I get hit, I can get hit hard. We had a client who wasn't
    > running proper virus/spam software, and got into a spambot. I was
    > getting mail in for them at the rate of 15/second, which virtually
    > killed the machine with all the other legitimate mail coming in.
    > They got removed in a hurry. I had over 100,000 messages in
    > the mail queue when I caught it.
    >
    > Be sure to monitor everything when you are directly connected.
    >
    > Bill
    > --
    > Bill Vermillion - bv @ wjv . com



    --

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

+ Reply to Thread