Telnet: route to host - SCO

This is a discussion on Telnet: route to host - SCO ; .... a 505 box (probably with insufficient patches) can connect nicely to the linux box two feet away on some ports. It can't telnet, for some reason I'm puzzling over (ignore that for now). What gets me is when I ...

+ Reply to Thread
Results 1 to 20 of 20

Thread: Telnet: route to host

  1. Telnet: route to host

    .... a 505 box (probably with insufficient patches) can connect
    nicely to the linux box two feet away on some ports. It can't
    telnet, for some reason I'm puzzling over (ignore that for now).

    What gets me is when I connect to a non-functioning port, I get:

    $ telnet 10.1.1.4 5555
    Trying 10.1.1.4...
    telnet: Unable to connect to remote host: No route to host

    Two things wrong with that: first, it no problem finding a
    'route to host' for ports it likes:

    $ telnet 10.1.1.4 110
    Trying 10.1.1.4...
    Connected to 10.1.1.4.
    Escape character is '^]'.
    +OK Dovecot ready.

    Ping works as well, route to host notwithstanding.

    And, second, since the two machines are on the same subnet,
    connected by a switch, no need for a route at all. What's up with
    that?

    In case you were wondering, here's the routing table (.240 is
    SCO, .4 is linux, .1 is the DSL router):

    $ netstat -rn
    Routing tables
    Destination Gateway Flags Refs Use
    Interface
    default 10.1.1.1 UGS 0 42940 net0
    10.1.1 10.1.1.240 UC 1 0 net0
    10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    224 10.1.1.240 UCS 0 0 net0

    [and what is it *doing* on localhost anyway? Navel introspection?
    :-)]

    So, what did I screw up?

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  2. Re: Telnet: route to host


    ----- Original Message -----
    From: "Nachman Yaakov Ziskind"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Wednesday, August 03, 2005 1:18 PM
    Subject: Telnet: route to host


    > ... a 505 box (probably with insufficient patches) can connect
    > nicely to the linux box two feet away on some ports. It can't
    > telnet, for some reason I'm puzzling over (ignore that for now).
    >
    > What gets me is when I connect to a non-functioning port, I get:
    >
    > $ telnet 10.1.1.4 5555
    > Trying 10.1.1.4...
    > telnet: Unable to connect to remote host: No route to host
    >
    > Two things wrong with that: first, it no problem finding a
    > 'route to host' for ports it likes:
    >
    > $ telnet 10.1.1.4 110
    > Trying 10.1.1.4...
    > Connected to 10.1.1.4.
    > Escape character is '^]'.
    > +OK Dovecot ready.
    >
    > Ping works as well, route to host notwithstanding.
    >
    > And, second, since the two machines are on the same subnet,
    > connected by a switch, no need for a route at all. What's up with
    > that?
    >
    > In case you were wondering, here's the routing table (.240 is
    > SCO, .4 is linux, .1 is the DSL router):
    >
    > $ netstat -rn
    > Routing tables
    > Destination Gateway Flags Refs Use
    > Interface
    > default 10.1.1.1 UGS 0 42940 net0
    > 10.1.1 10.1.1.240 UC 1 0 net0
    > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    > 224 10.1.1.240 UCS 0 0 net0
    >
    > [and what is it *doing* on localhost anyway? Navel introspection?
    > :-)]
    >
    > So, what did I screw up?


    Maybe nothing.
    You do know that by default most recent linux distros
    * do not have telnetd enabled,
    * or even installed sometimes,
    * may have a default set of rules in the kernel software firewall that
    blocks telnet,
    * may have a securetty file that says root can't telnet directly in, only
    users, but you aren't getting even that far yet since you don't get as far
    as getting a login prompt.

    It might possibly be the old old long before linux problem of the telnet
    server trying to resolve the clients hostname, which it can't because no lan
    ip is in dns and only a few written by hand in /etc/hosts.
    You aren't getting the usual symptoms for this though, which is a very long
    pause before the login prompt appears followed by normal operation for the
    rest of that session, not "no route to host"

    What's netstat -rn on linux?
    What's /etc/resolv.conf on both boxes?
    Are all possible lan ip's listed in both boxes /etc/hosts? (it's ok if they
    are mostly shell-loop-generated dummy hostnames)
    Whats ipfstat on linux? Or whatever the command is to list the current
    running ip filter / ipnat table in the kernel. The terminology and the
    commands have changed several times in the last few years so rather than try
    to list every possible, I leave it to you to find out how to see the current
    firewall settings.
    What's "netstat -an |grep -i listen" on linux? Look for *.23, or add "|grep
    \.23" to the pipe.

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





  3. Re: Telnet: route to host

    Nachman Yaakov Ziskind wrote:

    > ... a 505 box (probably with insufficient patches) can connect
    > nicely to the linux box two feet away on some ports. It can't
    > telnet, for some reason I'm puzzling over (ignore that for now).
    >
    > What gets me is when I connect to a non-functioning port, I get:
    >
    > $ telnet 10.1.1.4 5555
    > Trying 10.1.1.4...
    > telnet: Unable to connect to remote host: No route to host
    >
    > Two things wrong with that: first, it no problem finding a
    > 'route to host' for ports it likes:
    >
    > $ telnet 10.1.1.4 110
    > Trying 10.1.1.4...
    > Connected to 10.1.1.4.
    > Escape character is '^]'.
    > +OK Dovecot ready.
    >
    > Ping works as well, route to host notwithstanding.
    >
    > And, second, since the two machines are on the same subnet,
    > connected by a switch, no need for a route at all. What's up with
    > that?
    >
    > In case you were wondering, here's the routing table (.240 is
    > SCO, .4 is linux, .1 is the DSL router):
    >
    > $ netstat -rn
    > Routing tables
    > Destination Gateway Flags Refs Use
    > Interface
    > default 10.1.1.1 UGS 0 42940 net0
    > 10.1.1 10.1.1.240 UC 1 0 net0
    > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    > 224 10.1.1.240 UCS 0 0 net0
    >
    > [and what is it *doing* on localhost anyway? Navel introspection?
    > :-)]
    >
    > So, what did I screw up?


    Lots of services route though localhost (e.g., I believe in the default
    configuration OSR507 reads man pages through localhost; less sure about
    505).

    The Linux box almost certainly isn't running a telnetd on port 23 (it's
    obsolete and a huge security hole).

    It's probably running an internal firewall which is set to generate ICMP
    host unreachable responses on attempts to access blocked ports. It's
    like the voice saying "nobody in here but us chickens", except computers
    are much more likely to take such a response literally...

    >Bela<


  4. Re: Telnet: route to host

    Bela Lubkin wrote (on Wed, Aug 03, 2005 at 03:46:25PM -0400):
    > Nachman Yaakov Ziskind wrote:
    >
    > > ... a 505 box (probably with insufficient patches) can connect
    > > nicely to the linux box two feet away on some ports. It can't
    > > telnet, for some reason I'm puzzling over (ignore that for now).
    > >
    > > What gets me is when I connect to a non-functioning port, I get:
    > >
    > > $ telnet 10.1.1.4 5555
    > > Trying 10.1.1.4...
    > > telnet: Unable to connect to remote host: No route to host
    > >
    > > Two things wrong with that: first, it no problem finding a
    > > 'route to host' for ports it likes:
    > >
    > > $ telnet 10.1.1.4 110
    > > Trying 10.1.1.4...
    > > Connected to 10.1.1.4.
    > > Escape character is '^]'.
    > > +OK Dovecot ready.
    > >
    > > Ping works as well, route to host notwithstanding.
    > >
    > > And, second, since the two machines are on the same subnet,
    > > connected by a switch, no need for a route at all. What's up with
    > > that?
    > >
    > > In case you were wondering, here's the routing table (.240 is
    > > SCO, .4 is linux, .1 is the DSL router):
    > >
    > > $ netstat -rn
    > > Routing tables
    > > Destination Gateway Flags Refs Use
    > > Interface
    > > default 10.1.1.1 UGS 0 42940 net0
    > > 10.1.1 10.1.1.240 UC 1 0 net0
    > > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    > > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    > > 224 10.1.1.240 UCS 0 0 net0
    > >
    > > [and what is it *doing* on localhost anyway? Navel introspection?
    > > :-)]
    > >
    > > So, what did I screw up?

    >
    > Lots of services route though localhost (e.g., I believe in the default
    > configuration OSR507 reads man pages through localhost; less sure about
    > 505).


    Thanks for this thought - but the SCO box really does very little, running
    just one VAR's application - wonder how it uses localhost?

    > The Linux box almost certainly isn't running a telnetd on port 23 (it's
    > obsolete and a huge security hole).


    It absolutely is - I turned it on.

    > It's probably running an internal firewall which is set to generate ICMP
    > host unreachable responses on attempts to access blocked ports. It's
    > like the voice saying "nobody in here but us chickens", except computers
    > are much more likely to take such a response literally...


    I found the telnet problem (I had to insert an IPTABLES rule). But that
    wasn't my question, so I'll restate it:

    Why does the OpenServer box generate a 'no route to host' error in a
    case like this? It should either wait and time out, or return
    'connection refused'.

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  5. Re: Telnet: route to host

    Brian K. White wrote (on Wed, Aug 03, 2005 at 03:14:15PM -0400):
    >
    > > ... a 505 box (probably with insufficient patches) can connect
    > > nicely to the linux box two feet away on some ports. It can't
    > > telnet, for some reason I'm puzzling over (ignore that for now).
    > >
    > > What gets me is when I connect to a non-functioning port, I get:
    > >
    > > $ telnet 10.1.1.4 5555
    > > Trying 10.1.1.4...
    > > telnet: Unable to connect to remote host: No route to host
    > >
    > > Two things wrong with that: first, it no problem finding a
    > > 'route to host' for ports it likes:
    > >
    > > $ telnet 10.1.1.4 110
    > > Trying 10.1.1.4...
    > > Connected to 10.1.1.4.
    > > Escape character is '^]'.
    > > +OK Dovecot ready.
    > >
    > > Ping works as well, route to host notwithstanding.
    > >
    > > And, second, since the two machines are on the same subnet,
    > > connected by a switch, no need for a route at all. What's up with
    > > that?
    > >
    > > In case you were wondering, here's the routing table (.240 is
    > > SCO, .4 is linux, .1 is the DSL router):
    > >
    > > $ netstat -rn
    > > Routing tables
    > > Destination Gateway Flags Refs Use
    > > Interface
    > > default 10.1.1.1 UGS 0 42940 net0
    > > 10.1.1 10.1.1.240 UC 1 0 net0
    > > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    > > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    > > 224 10.1.1.240 UCS 0 0 net0
    > >
    > > [and what is it *doing* on localhost anyway? Navel introspection?
    > > :-)]
    > >
    > > So, what did I screw up?

    >
    > Maybe nothing.
    > You do know that by default most recent linux distros
    > * do not have telnetd enabled,
    > * or even installed sometimes,
    > * may have a default set of rules in the kernel software firewall that
    > blocks telnet,
    > * may have a securetty file that says root can't telnet directly in, only
    > users, but you aren't getting even that far yet since you don't get as far
    > as getting a login prompt.


    Yes, yes - all that checked (and I found the problem - iptables). But that
    wasn't my question.

    > It might possibly be the old old long before linux problem of the telnet
    > server trying to resolve the clients hostname, which it can't because no lan
    > ip is in dns and only a few written by hand in /etc/hosts.


    Uh-uh.

    > You aren't getting the usual symptoms for this though, which is a very long
    > pause before the login prompt appears followed by normal operation for the
    > rest of that session, not "no route to host"
    >
    > What's netstat -rn on linux?


    Should it matter, in relation to a locally connected machine? :
    Kernel IP routing table
    Destination Gateway Genmask Flags MSS Window irtt Iface
    10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
    169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
    0.0.0.0 10.1.1.1 0.0.0.0 UG 0 0 0 eth0

    > What's /etc/resolv.conf on both boxes?


    This can't be relevant if some services work, but:
    nameserver 10.1.1.1 && Linux

    # l /etc/resolv.conf && SCO
    l: /etc/resolv.conf not found: No such file or directory (error 2)

    > Are all possible lan ip's listed in both boxes /etc/hosts? (it's ok if they
    > are mostly shell-loop-generated dummy hostnames)
    > Whats ipfstat on linux? Or whatever the command is to list the current
    > running ip filter / ipnat table in the kernel. The terminology and the
    > commands have changed several times in the last few years so rather than try
    > to list every possible, I leave it to you to find out how to see the current
    > firewall settings.
    > What's "netstat -an |grep -i listen" on linux? Look for *.23, or add "|grep
    > \.23" to the pipe.


    Again, you're attacking the telnet problem - thanks for the suggestions, but
    not my real question:

    Why does the SCO box come up with the bogus error message?


    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  6. Re: Telnet: route to host


    ----- Original Message -----
    From: "Nachman Yaakov Ziskind"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Wednesday, August 03, 2005 4:43 PM
    Subject: Re: Telnet: route to host


    > Bela Lubkin wrote (on Wed, Aug 03, 2005 at 03:46:25PM -0400):
    >> Nachman Yaakov Ziskind wrote:
    >>
    >> > ... a 505 box (probably with insufficient patches) can connect
    >> > nicely to the linux box two feet away on some ports. It can't
    >> > telnet, for some reason I'm puzzling over (ignore that for now).
    >> >
    >> > What gets me is when I connect to a non-functioning port, I get:
    >> >
    >> > $ telnet 10.1.1.4 5555
    >> > Trying 10.1.1.4...
    >> > telnet: Unable to connect to remote host: No route to host
    >> >
    >> > Two things wrong with that: first, it no problem finding a
    >> > 'route to host' for ports it likes:
    >> >
    >> > $ telnet 10.1.1.4 110
    >> > Trying 10.1.1.4...
    >> > Connected to 10.1.1.4.
    >> > Escape character is '^]'.
    >> > +OK Dovecot ready.
    >> >
    >> > Ping works as well, route to host notwithstanding.
    >> >
    >> > And, second, since the two machines are on the same subnet,
    >> > connected by a switch, no need for a route at all. What's up with
    >> > that?
    >> >
    >> > In case you were wondering, here's the routing table (.240 is
    >> > SCO, .4 is linux, .1 is the DSL router):
    >> >
    >> > $ netstat -rn
    >> > Routing tables
    >> > Destination Gateway Flags Refs Use
    >> > Interface
    >> > default 10.1.1.1 UGS 0 42940 net0
    >> > 10.1.1 10.1.1.240 UC 1 0 net0
    >> > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    >> > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    >> > 224 10.1.1.240 UCS 0 0 net0
    >> >
    >> > [and what is it *doing* on localhost anyway? Navel introspection?
    >> > :-)]
    >> >
    >> > So, what did I screw up?

    >>
    >> Lots of services route though localhost (e.g., I believe in the default
    >> configuration OSR507 reads man pages through localhost; less sure about
    >> 505).

    >
    > Thanks for this thought - but the SCO box really does very little, running
    > just one VAR's application - wonder how it uses localhost?
    >
    >> The Linux box almost certainly isn't running a telnetd on port 23 (it's
    >> obsolete and a huge security hole).

    >
    > It absolutely is - I turned it on.
    >
    >> It's probably running an internal firewall which is set to generate ICMP
    >> host unreachable responses on attempts to access blocked ports. It's
    >> like the voice saying "nobody in here but us chickens", except computers
    >> are much more likely to take such a response literally...

    >
    > I found the telnet problem (I had to insert an IPTABLES rule). But that
    > wasn't my question, so I'll restate it:
    >
    > Why does the OpenServer box generate a 'no route to host' error in a
    > case like this? It should either wait and time out, or return
    > 'connection refused'.


    How it the world did you read Bela's last paragraph, and still write this?

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


  7. Re: Telnet: route to host

    Nachman Yaakov Ziskind wrote:

    > Bela Lubkin wrote (on Wed, Aug 03, 2005 at 03:46:25PM -0400):
    > > Nachman Yaakov Ziskind wrote:
    > > >
    > > > What gets me is when I connect to a non-functioning port, I get:
    > > >
    > > > $ telnet 10.1.1.4 5555
    > > > Trying 10.1.1.4...
    > > > telnet: Unable to connect to remote host: No route to host

    >
    > > It's probably running an internal firewall which is set to generate ICMP
    > > host unreachable responses on attempts to access blocked ports. It's
    > > like the voice saying "nobody in here but us chickens", except computers
    > > are much more likely to take such a response literally...

    >
    > I found the telnet problem (I had to insert an IPTABLES rule). But that
    > wasn't my question, so I'll restate it:
    >
    > Why does the OpenServer box generate a 'no route to host' error in a
    > case like this? It should either wait and time out, or return
    > 'connection refused'.


    What was the generic IPTABLES rule you were overriding? I'm guessing
    something like:

    all ports not otherwise covered:
    reject with "ICMP destination unreachable: host unreachable"

    to which you added:

    TCP port 23 [telnet]:
    accept

    The message isn't bogus if the remote host actually sent a "host
    unreachable" message!

    >Bela<


  8. Re: Telnet: route to host

    > Why does the SCO box come up with the bogus error message?

    As Bela pointed out it turns out it's not bogus, or at least it's not the
    sco box being bogus.

    First consider a "normal" case.
    Suppose the destination box was several hops away on the internet.
    Suppose you have a correct routing table on your sco box that says the route
    to that ip lies via your gateway router.
    Suppose the gatway router also has a correct routing table that points to
    one of your isp's machines.
    Suppose that isp machine is misconfigured and has no route anywhere in it's
    routing table that matches the IP you tried to reach? (meaning, no default
    route either of course)

    The traffic left your box correctly and there is nothing you can fix on your
    box, but due to botched routing in one or more machines outside of your
    control, it hit a dead end.
    The last machine in that dead end, the machine that received the traffic but
    doesn't know what to do with it, _says so_ back to the machine it got the
    traffic from and the various machines relay that "no route to host" message
    back ultimately to you the originator.

    The point: The no route message doesn't come from the originating box, it
    comes from whichever machine was given a task it doesn't know how to do. If
    your own routing table is incorrect, that's the only time your own box
    generates the error.

    In your case, your routing table is correct enough to get you to the correct
    next hop along the way to the destination.
    That next hop happens to also BE the destination but that doesn't change
    much.
    The machine you reached claims it doesnt' know how to route traffic to the
    ip you asked for.
    That's basically a flat lie.
    If your destination was an IP (lets leave possible wrinkles with hostnames
    out for the moment), and if the linux box nic was that same IP, and if you
    physically reached that nic, then techincally the linux box is lying when it
    says no route to host.

    There are other types of errors besides no route so it is still generally
    correct that your box shows you errors it gets from the next hop, even in
    this case whre the next hop is the destination.

    Perhaps the sco box should be smart enough to know that a same-subnet route
    is a special case and that there can be no such thing as that particular
    error in that particular case, and throw away the error message it got from
    linux and instead report something like "Host is claiming no route to host.
    Host, whom I supposedly can't reach, told me this, over the route that
    supposedly doesn't exist. Maybe host has pms. I give up."

    Perhaps the linux box should be more honest and say "denied by firewall
    rules". That sounds like painting a big target on onesself saying "locked
    door here--->" which is counter to the goals of a firewall, but it's
    unavoidable anyways. No matter what the linux box wants to say, the
    physically next hop box always has the ability to know it's a lie, and it's
    possible for new machines that are hip to this trick and report the truth
    back to the originator to populate the internet over time. And any box
    anywhere already always has the ability to know it's a lie if they can reach
    the box by any other means. So it's a cute but ultimately pointless trick.

    This kind of thing bugs me because it inflicts wasted time damage on people
    like you & me who may think there really is a routing problem and chase our
    tails trying to fix what isn't broken.
    I think things like error messages shoudl be sacrosanct. You don't spoof
    them. Start doing that and error messages become a useless diagnostic tool,
    and THEN where are we?
    Shortsighted idiot linux developers are destroying the world.

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


  9. Re: Telnet: route to host

    Bela Lubkin wrote (on Wed, Aug 03, 2005 at 02:24:47PM -0700):
    > Nachman Yaakov Ziskind wrote:
    > > Bela Lubkin wrote (on Wed, Aug 03, 2005 at 03:46:25PM -0400):
    > > > Nachman Yaakov Ziskind wrote:
    > > > >
    > > > > What gets me is when I connect to a non-functioning port, I get:
    > > > >
    > > > > $ telnet 10.1.1.4 5555
    > > > > Trying 10.1.1.4...
    > > > > telnet: Unable to connect to remote host: No route to host

    > >
    > > > It's probably running an internal firewall which is set to generate ICMP
    > > > host unreachable responses on attempts to access blocked ports. It's
    > > > like the voice saying "nobody in here but us chickens", except computers
    > > > are much more likely to take such a response literally...

    > >
    > > I found the telnet problem (I had to insert an IPTABLES rule). But that
    > > wasn't my question, so I'll restate it:
    > >
    > > Why does the OpenServer box generate a 'no route to host' error in a
    > > case like this? It should either wait and time out, or return
    > > 'connection refused'.

    >
    > What was the generic IPTABLES rule you were overriding? I'm guessing
    > something like:
    >
    > all ports not otherwise covered:
    > reject with "ICMP destination unreachable: host unreachable"


    I'm not an IPTABLES expert (life is just too good with Shorewall), but the
    last rule is:

    -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

    which look like you're on the money. I had the same problem not just
    with port 23, but with random ports, which tends to confirm your
    hypothesis.

    > to which you added:
    >
    > TCP port 23 [telnet]:
    > accept
    >
    > The message isn't bogus if the remote host actually sent a "host
    > unreachable" message!



    So, I suppose I'm complaining about TCP/IP in general, rather than SCO's
    interpretation in particular. Sorry, it still seems bogus. I'm talking to a
    host. The host tell me that it's unreachable. The packet that tells me so has
    the source IP of the "unreachable" host. App tells the user that there's no
    route to host? Huh?

    That's like me knocking on your door:
    "Bela, are you home?"

    "No, I'm not."

    (turning to my wife: "He's not home.")

    I suppose I'm missing something really basic here ...

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  10. Re: Telnet: route to host

    Brian K. White wrote (on Wed, Aug 03, 2005 at 05:13:40PM -0400):
    >
    > >> > ... a 505 box (probably with insufficient patches) can connect
    > >> > nicely to the linux box two feet away on some ports. It can't
    > >> > telnet, for some reason I'm puzzling over (ignore that for now).
    > >> >
    > >> > What gets me is when I connect to a non-functioning port, I get:
    > >> >
    > >> > $ telnet 10.1.1.4 5555
    > >> > Trying 10.1.1.4...
    > >> > telnet: Unable to connect to remote host: No route to host
    > >> >
    > >> > Two things wrong with that: first, it no problem finding a
    > >> > 'route to host' for ports it likes:
    > >> >
    > >> > $ telnet 10.1.1.4 110
    > >> > Trying 10.1.1.4...
    > >> > Connected to 10.1.1.4.
    > >> > Escape character is '^]'.
    > >> > +OK Dovecot ready.
    > >> >
    > >> > Ping works as well, route to host notwithstanding.
    > >> >
    > >> > And, second, since the two machines are on the same subnet,
    > >> > connected by a switch, no need for a route at all. What's up with
    > >> > that?
    > >> >
    > >> > In case you were wondering, here's the routing table (.240 is
    > >> > SCO, .4 is linux, .1 is the DSL router):
    > >> >
    > >> > $ netstat -rn
    > >> > Routing tables
    > >> > Destination Gateway Flags Refs Use
    > >> > Interface
    > >> > default 10.1.1.1 UGS 0 42940 net0
    > >> > 10.1.1 10.1.1.240 UC 1 0 net0
    > >> > 10.1.1.240 127.0.0.1 UGHS 4 57 lo0
    > >> > 127.0.0.1 127.0.0.1 UH 3 8179178 lo0
    > >> > 224 10.1.1.240 UCS 0 0 net0
    > >> >
    > >> > [and what is it *doing* on localhost anyway? Navel introspection?
    > >> > :-)]
    > >> >
    > >> > So, what did I screw up?
    > >>
    > >> Lots of services route though localhost (e.g., I believe in the default
    > >> configuration OSR507 reads man pages through localhost; less sure about
    > >> 505).

    > >
    > > Thanks for this thought - but the SCO box really does very little, running
    > > just one VAR's application - wonder how it uses localhost?
    > >
    > >> The Linux box almost certainly isn't running a telnetd on port 23 (it's
    > >> obsolete and a huge security hole).

    > >
    > > It absolutely is - I turned it on.
    > >
    > >> It's probably running an internal firewall which is set to generate ICMP
    > >> host unreachable responses on attempts to access blocked ports. It's
    > >> like the voice saying "nobody in here but us chickens", except computers
    > >> are much more likely to take such a response literally...

    > >
    > > I found the telnet problem (I had to insert an IPTABLES rule). But that
    > > wasn't my question, so I'll restate it:
    > >
    > > Why does the OpenServer box generate a 'no route to host' error in a
    > > case like this? It should either wait and time out, or return
    > > 'connection refused'.

    >
    > How it the world did you read Bela's last paragraph, and still write this?


    You mean:
    "It's probably running an internal firewall which is set to generate
    ICMP host unreachable responses on attempts to access blocked ports.
    It's like the voice saying "nobody in here but us chickens", except
    computers are much more likely to take such a response literally..."

    ?

    Simple: I'm being obtuse. I just don't get "no route to host" out of this.
    See my separate reply to Bela. At least I now know it's not a SCO issue, but
    (either my ignorance or) a TCP/IP issue in general.

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  11. Re: Telnet: route to host

    Brian K. White wrote (on Wed, Aug 03, 2005 at 10:48:35PM -0400):
    > > Why does the SCO box come up with the bogus error message?

    >
    > As Bela pointed out it turns out it's not bogus, or at least it's not the
    > sco box being bogus.
    >
    > First consider a "normal" case.


    [Lots of good stuff snipped]

    > The point: The no route message doesn't come from the originating box, it
    > comes from whichever machine was given a task it doesn't know how to do. If
    > your own routing table is incorrect, that's the only time your own box
    > generates the error.


    I agree with everything you've written.

    > In your case, your routing table is correct enough to get you to the correct
    > next hop along the way to the destination.


    Is true, BTW? Does the routing table even come into play? Perhaps I just look
    at the IP/mask and decide 'local'.

    On second thought, no. Even local stuff gets routed through the table.

    > That next hop happens to also BE the destination but that doesn't change
    > much.
    > The machine you reached claims it doesnt' know how to route traffic to the
    > ip you asked for.
    > That's basically a flat lie.


    Fair enough - but shouldn't the receiving stack notice that the "unreachable
    host" is the one replying, and be guided accordingly?

    > If your destination was an IP (lets leave possible wrinkles with hostnames
    > out for the moment), and if the linux box nic was that same IP, and if you
    > physically reached that nic, then techincally the linux box is lying when it
    > says no route to host.
    >
    > There are other types of errors besides no route so it is still generally
    > correct that your box shows you errors it gets from the next hop, even in
    > this case whre the next hop is the destination.
    >
    > Perhaps the sco box should be smart enough to know that a same-subnet route
    > is a special case and that there can be no such thing as that particular
    > error in that particular case, and throw away the error message it got from
    > linux and instead report something like "Host is claiming no route to host.
    > Host, whom I supposedly can't reach, told me this, over the route that
    > supposedly doesn't exist. Maybe host has pms. I give up."


    How about just the obvious, "connection refused"? That's what is really
    happening.

    > This kind of thing bugs me because it inflicts wasted time damage on people
    > like you & me who may think there really is a routing problem and chase our
    > tails trying to fix what isn't broken.
    > I think things like error messages shoudl be sacrosanct. You don't spoof
    > them. Start doing that and error messages become a useless diagnostic tool,
    > and THEN where are we?
    > Shortsighted idiot linux developers are destroying the world.


    The best and worst thing about SCO is it's stability.
    The best and worst thing about Linux is it's instability.

    With the dog comes the fleas, I suppose.
    Like the old quip about D.C.: "If you don't like the weather, wait a
    minute. :-)

    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  12. Re: Telnet: route to host

    In article <20050804103023.F7172@egps.egps.com>,
    Nachman Yaakov Ziskind wrote:
    >Brian K. White wrote (on Wed, Aug 03, 2005 at 10:48:35PM -0400):
    >> > Why does the SCO box come up with the bogus error message?


    >> As Bela pointed out it turns out it's not bogus, or at least
    >> it's not the sco box being bogus.


    >> First consider a "normal" case.


    >[Lots of good stuff snipped]


    [Much more snipped as I'm only commenting on one line. wjv]

    .....

    >> Perhaps the sco box should be smart enough to know that a
    >> same-subnet route is a special case and that there can be no
    >> such thing as that particular error in that particular case,
    >> and throw away the error message it got from linux and instead
    >> report something like "Host is claiming no route to host. Host,
    >> whom I supposedly can't reach, told me this, over the route
    >> that supposedly doesn't exist. Maybe host has pms. I give up."
    >>


    >How about just the obvious, "connection refused"? That's what is
    >really happening.


    That may be what is actually happening but many systems are set
    not to respond at all feeling it is better for a cracker to think
    there is no machine there, as opposed to confirming there is a
    machine at that IP and attempt further attacks.

    >The best and worst thing about SCO is it's stability.


    What's wront with stability? Or are you confusing the 'worst' with
    being slow to have drivers for the latest hardware that gets
    released?

    >The best and worst thing about Linux is it's instability.


    Apply my previous comment to this also - but inverting it to mean
    supports almost anything that someone has at least put together in a
    prototype mode :-)

    Bill

    --
    Bill Vermillion - bv @ wjv . com

  13. Re: Telnet: route to host

    Bill Vermillion wrote (on Thu, Aug 04, 2005 at 06:15:01PM +0000):
    > In article <20050804103023.F7172@egps.egps.com>,
    > Nachman Yaakov Ziskind wrote:
    > >Brian K. White wrote (on Wed, Aug 03, 2005 at 10:48:35PM -0400):
    > >> > Why does the SCO box come up with the bogus error message?

    >
    > >> As Bela pointed out it turns out it's not bogus, or at least
    > >> it's not the sco box being bogus.

    >
    > >> First consider a "normal" case.

    >
    > >[Lots of good stuff snipped]

    >
    > [Much more snipped as I'm only commenting on one line. wjv]
    >
    > ....
    >
    > >> Perhaps the sco box should be smart enough to know that a
    > >> same-subnet route is a special case and that there can be no
    > >> such thing as that particular error in that particular case,
    > >> and throw away the error message it got from linux and instead
    > >> report something like "Host is claiming no route to host. Host,
    > >> whom I supposedly can't reach, told me this, over the route
    > >> that supposedly doesn't exist. Maybe host has pms. I give up."
    > >>

    >
    > >How about just the obvious, "connection refused"? That's what is
    > >really happening.

    >
    > That may be what is actually happening but many systems are set
    > not to respond at all feeling it is better for a cracker to think
    > there is no machine there, as opposed to confirming there is a
    > machine at that IP and attempt further attacks.


    No, I meant the SCO box, not the Linux box.

    > >The best and worst thing about SCO is it's stability.

    >
    > What's wront with stability? Or are you confusing the 'worst' with
    > being slow to have drivers for the latest hardware that gets
    > released?


    Yes, I am confusing exactly that. SCO users wait a long time for stuff
    that Linux users get quickly.

    > >The best and worst thing about Linux is it's instability.

    >
    > Apply my previous comment to this also - but inverting it to mean
    > supports almost anything that someone has at least put together in a
    > prototype mode :-)


    Yes. In their haste to support the Latest and Greatest, they tend to
    have a healthy disrespect for established standards. :-)

    All I'm pointing out that it's two sides of the same coin, and you
    have to make trade-offs. But source code means never having to say
    you're sorry. :-)

    > Bill
    >
    > --
    > Bill Vermillion - bv @ wjv . com


    --
    _________________________________________
    Nachman Yaakov Ziskind, FSPA, LLM awacs@ziskind.us
    Attorney and Counselor-at-Law http://ziskind.us
    Economic Group Pension Services http://egps.com
    Actuaries and Employee Benefit Consultants

  14. Re: Telnet: route to host

    On Thu, 4 Aug 2005 3:48:35 +0100, Brian K. White wrote
    (in message <020801c5989e$fa86a530$6b00000a@venti>):

    > This kind of thing bugs me because it inflicts wasted time damage on people
    > like you & me who may think there really is a routing problem and chase our
    > tails trying to fix what isn't broken.
    > I think things like error messages shoudl be sacrosanct. You don't spoof
    > them. Start doing that and error messages become a useless diagnostic tool,
    > and THEN where are we?
    > Shortsighted idiot linux developers are destroying the world.


    Hear hear !

    However, it's not just Linux guys ....

    When we put a firewall in at work we spent ages trying to figure out why we
    couldn't reach anything on the internet - pings failed altogether and
    traceroutes simply stopped somewhere in the ISPs network. A call to their
    support line enlightened us to the fact that they block pings so as to break
    one of the viruses, but only the sort used by Windoze.

    Switch to one of our Unix or Linux hosts and hey presto, traceroutes and
    pings work !


    At home, my router doesn't seem to allow them at all, so I can't traceroute
    anywhere :-(


    Anyway, back to the thread, in situations like this, I think the rule should
    simply be to drop the packets - that way it ties up resources on any machine
    being used to attck you. Ie, they attempt to open a connection, and instead
    of immediately getting back a "no way Jose" message, they must wait until the
    connection attempt times out. I see regular attacks on my machine, people out
    there are obviously trying brute-force attacks to try and connect via SSH -
    and it's clear they can do many attempts/second for some time, adding a few
    seconds to each will cause a 'cost' for the attacker. I see there's a package
    fail2 that automatically adds IPs to IP Tables in such situations
    - must take a look.

    Simon



  15. Re: Telnet: route to host

    In article <20050804145124.A21853@egps.egps.com>,
    Nachman Yaakov Ziskind wrote:
    >Bill Vermillion wrote (on Thu, Aug 04, 2005 at 06:15:01PM +0000):
    >> In article <20050804103023.F7172@egps.egps.com>,
    >> Nachman Yaakov Ziskind wrote:
    >> >Brian K. White wrote (on Wed, Aug 03, 2005 at 10:48:35PM -0400):
    >> >> > Why does the SCO box come up with the bogus error message?


    >> >> As Bela pointed out it turns out it's not bogus, or at least
    >> >> it's not the sco box being bogus.

    >>
    >> >> First consider a "normal" case.

    >>
    >> >[Lots of good stuff snipped]

    >>
    >> [Much more snipped as I'm only commenting on one line. wjv]
    >>
    >> ....
    >>
    >> >> Perhaps the sco box should be smart enough to know that a
    >> >> same-subnet route is a special case and that there can be no
    >> >> such thing as that particular error in that particular case,
    >> >> and throw away the error message it got from linux and instead
    >> >> report something like "Host is claiming no route to host. Host,
    >> >> whom I supposedly can't reach, told me this, over the route
    >> >> that supposedly doesn't exist. Maybe host has pms. I give up."
    >> >>


    >> >How about just the obvious, "connection refused"? That's what is
    >> >really happening.


    >> That may be what is actually happening but many systems are set
    >> not to respond at all feeling it is better for a cracker to think
    >> there is no machine there, as opposed to confirming there is a
    >> machine at that IP and attempt further attacks.


    >No, I meant the SCO box, not the Linux box.


    If the far side box sends NOTHING back - then how is the SCO box to
    know 1) if it really is there and refusing connection, or 2) it
    really does not exist.

    >> >The best and worst thing about SCO is it's stability.


    >> What's wront with stability? Or are you confusing the 'worst' with
    >> being slow to have drivers for the latest hardware that gets
    >> released?


    >Yes, I am confusing exactly that. SCO users wait a long time for stuff
    >that Linux users get quickly.


    Which usually goes with stability. That makes sense, but since
    Linux systems are also targetting the desk-top market - wanting to
    replace windows - and SCO systems are primarily server oriented
    [based on all I've seen and maintained where at times no one goes
    near the SCO machine for months] then stability must be the prime
    feature. The longest I had an SCO server up was about 1 3/4 years,
    but it was hard to tell because at that point the 'w' wouldn't show
    the uptime.

    Most of the few Linux systems I've worked with seem to hiccup or
    need a restart to get all things running properly. But these have
    been older RedHats. The FreeBSD machines I maintain can go past
    that.

    My main mail server shows 520 days, 32 seconds as of this moment.
    It was supposed to be taken off line last week, but its replacement
    decided not to play nice after hanging out in the rack for a month.
    I'm lazy so I want stable machines first and foremost :-)

    >> >The best and worst thing about Linux is it's instability.


    >> Apply my previous comment to this also - but inverting it to mean
    >> supports almost anything that someone has at least put together in a
    >> prototype mode :-)


    >Yes. In their haste to support the Latest and Greatest, they tend to
    >have a healthy disrespect for established standards. :-)


    Trying so hard to displace MS on the desktop they sometimes miss
    the standards like MS. Have you seen the non-standard conformance
    for the new IE-7 comming soon? It would seem they had years to get
    it right.

    And because of the strong success of Firefox the Mozilla group is
    going to make a commercial supported version, just as the sendmail
    group has done with supported/commercial sendmail for MS servers.

    At least we have plenty of choices :-)

    >All I'm pointing out that it's two sides of the same coin, and you
    >have to make trade-offs. But source code means never having to say
    >you're sorry. :-)


    I'll take some minor exceptions to that last point, after having
    some software builds go astray. But most of the time it's fine.
    That's why I like sources instead of the RPM approach.

    Bill



    --
    Bill Vermillion - bv @ wjv . com

  16. Re: Telnet: route to host

    In article <0001HW.BF18246A02484D54F0284600@usenet.plus.net>,
    Simon Hobson wrote:
    >On Thu, 4 Aug 2005 3:48:35 +0100, Brian K. White wrote
    >(in message <020801c5989e$fa86a530$6b00000a@venti>):


    >> This kind of thing bugs me because it inflicts wasted time
    >> damage on people like you & me who may think there really
    >> is a routing problem and chase our tails trying to fix what
    >> isn't broken. I think things like error messages shoudl be
    >> sacrosanct. You don't spoof them. Start doing that and error
    >> messages become a useless diagnostic tool, and THEN where are
    >> we? Shortsighted idiot linux developers are destroying the
    >> world.


    >Hear hear !


    >However, it's not just Linux guys ....


    >When we put a firewall in at work we spent ages trying to figure
    >out why we couldn't reach anything on the internet - pings failed
    >altogether and traceroutes simply stopped somewhere in the ISPs
    >network. A call to their support line enlightened us to the fact
    >that they block pings so as to break one of the viruses, but only
    >the sort used by Windoze.


    >Switch to one of our Unix or Linux hosts and hey presto,
    >traceroutes and pings work !


    Or switch to an ISP that knows and understands networking. I've
    seen some pretty stupid things done. And I've noticed more and
    more ISP turn off the ability of using ping -R [Record Route] which
    is awfully helpful when things don't go right, and you find packets
    go out one way but want to come back another because someone
    misconfigured something.

    >At home, my router doesn't seem to allow them at all, so I can't
    >traceroute anywhere :-(


    There are plenty of routers that do. Are you sure it's not
    something at your ISP?

    >Anyway, back to the thread, in situations like this, I think the
    >rule should simply be to drop the packets - that way it ties
    >up resources on any machine being used to attck you. Ie, they
    >attempt to open a connection, and instead of immediately getting
    >back a "no way Jose" message, they must wait until the connection
    >attempt times out. I see regular attacks on my machine, people
    >out there are obviously trying brute-force attacks to try and
    >connect via SSH - and it's clear they can do many attempts/second
    >for some time, adding a few seconds to each will cause a 'cost'
    >for the attacker. I see there's a package fail2 that
    >automatically adds IPs to IP Tables in such situations - must
    >take a look.


    Actually it depends upon how they are attacking you. Every now and
    thing I get notices that the kernel is limiting responses to
    200 packets/second when someone tries a stong attack, perhaps with
    a flood-ping. Limiting responses won't always help in that event.

    I see a lot of ssh attempts at times - and they seem to go in fits
    and spurts - with nothing for a week or so and then several days
    with nothing. Checking the places I log them I see about 22K
    attempts over the past 2 years.

    As to adding IPs to your filters you may find that your filters get
    so big they will start slowing down. I have not checked how many
    individual IPs are in the 22K mentioned above, but they typically
    come in bursts of a 100 or so, and virtually all of them are from
    outside the continental US. But I'd guess there could easily be
    1000 different addresses which is going to be a big table.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  17. Re: Telnet: route to host

    On 2005-08-04, Bill Vermillion wrote:
    > In article <0001HW.BF18246A02484D54F0284600@usenet.plus.net>,
    > Simon Hobson wrote:
    >>On Thu, 4 Aug 2005 3:48:35 +0100, Brian K. White wrote
    >>(in message <020801c5989e$fa86a530$6b00000a@venti>):

    >
    >>> This kind of thing bugs me because it inflicts wasted time
    >>> damage on people like you & me who may think there really
    >>> is a routing problem and chase our tails trying to fix what
    >>> isn't broken. I think things like error messages shoudl be
    >>> sacrosanct. You don't spoof them. Start doing that and error
    >>> messages become a useless diagnostic tool, and THEN where are
    >>> we? Shortsighted idiot linux developers are destroying the
    >>> world.

    >
    >>Hear hear !

    >
    >>However, it's not just Linux guys ....


    Actually, it's not the "Linux guys" at all: it's whoever wrote the
    firewall rules. Netfilter/IPTABLES has several options for packets that
    should be blocked. They can be silently dropped, or rejected with
    a choice of replies. Host-unreachable is only one of these.

    >
    >
    > Or switch to an ISP that knows and understands networking. I've
    > seen some pretty stupid things done. And I've noticed more and
    > more ISP turn off the ability of using ping -R [Record Route] which
    > is awfully helpful when things don't go right, and you find packets
    > go out one way but want to come back another because someone
    > misconfigured something.
    >
    >>At home, my router doesn't seem to allow them at all, so I can't
    >>traceroute anywhere :-(


    There is always tcptraceroute. Pick a suitable tcp port number and the
    packets should get through.


  18. Re: Telnet: route to host

    On 2005-08-04, Bill Vermillion wrote:
    > In article <20050804145124.A21853@egps.egps.com>,
    > Nachman Yaakov Ziskind wrote:
    >>Bill Vermillion wrote (on Thu, Aug 04, 2005 at 06:15:01PM +0000):

    >
    >
    > Which usually goes with stability. That makes sense, but since
    > Linux systems are also targetting the desk-top market - wanting to
    > replace windows - and SCO systems are primarily server oriented
    > [based on all I've seen and maintained where at times no one goes
    > near the SCO machine for months] then stability must be the prime
    > feature. The longest I had an SCO server up was about 1 3/4 years,
    > but it was hard to tell because at that point the 'w' wouldn't show
    > the uptime.


    I have run a Linux server for over 360 days without reboot. I know
    someone who ran one for over 1000 days. These were running 2.2.x and
    earlier.


    >
    >>> >The best and worst thing about Linux is it's instability.


    Instability? Yes, if you want to choose a bleeding edge distribution. If
    you value stability over having the latest features, chose a
    distribution that has the same goals. There are plenty of choices for
    stable distributions.

    Lets compare to SCO where it appears that Openserver 6 has some
    compatibility problems regarding applications for earlier versions.
    Also, within, what 1 month (or is it 2) since the release, there has
    already been a maintenance pack because of bugs and other is now
    required.

    >
    >
    >>All I'm pointing out that it's two sides of the same coin, and you
    >>have to make trade-offs. But source code means never having to say
    >>you're sorry. :-)

    >
    > I'll take some minor exceptions to that last point, after having
    > some software builds go astray. But most of the time it's fine.
    > That's why I like sources instead of the RPM approach.
    >


    Have you looked at Gentoo Linux?

    >
    >


  19. Re: Telnet: route to host

    In article ,
    Joe Dunning wrote:
    >On 2005-08-04, Bill Vermillion wrote:
    >> In article <20050804145124.A21853@egps.egps.com>,
    >> Nachman Yaakov Ziskind wrote:
    >>>Bill Vermillion wrote (on Thu, Aug 04, 2005 at 06:15:01PM +0000):

    >>
    >>
    >> Which usually goes with stability. That makes sense, but since
    >> Linux systems are also targetting the desk-top market - wanting to
    >> replace windows - and SCO systems are primarily server oriented
    >> [based on all I've seen and maintained where at times no one goes
    >> near the SCO machine for months] then stability must be the prime
    >> feature. The longest I had an SCO server up was about 1 3/4 years,
    >> but it was hard to tell because at that point the 'w' wouldn't show
    >> the uptime.

    >
    >I have run a Linux server for over 360 days without reboot. I know
    >someone who ran one for over 1000 days. These were running 2.2.x and
    >earlier.
    >
    >
    >>
    >>>> >The best and worst thing about Linux is it's instability.

    >
    >Instability? Yes, if you want to choose a bleeding edge distribution. If
    >you value stability over having the latest features, chose a
    >distribution that has the same goals. There are plenty of choices for
    >stable distributions.
    >
    >Lets compare to SCO where it appears that Openserver 6 has some
    >compatibility problems regarding applications for earlier versions.
    >Also, within, what 1 month (or is it 2) since the release, there has
    >already been a maintenance pack because of bugs and other is now
    >required.


    >>>All I'm pointing out that it's two sides of the same coin, and you
    >>>have to make trade-offs. But source code means never having to say
    >>>you're sorry. :-)


    >> I'll take some minor exceptions to that last point, after having
    >> some software builds go astray. But most of the time it's fine.
    >> That's why I like sources instead of the RPM approach.


    >Have you looked at Gentoo Linux?


    Having run FreeBSD for two different ISP's since about 1996/1997
    when they replaced 6 SGI servers, with twice performance and under
    1/4 the cost, I've never seen any reason to change.

    But all SW get's built on 1) my local machine first, and then
    2) a standby server, before it ever gets put on line.

    Under 4 hours of downtime total since 2000 [except for the two
    2-minute reboots each time the OS is upgraded] and the worst
    was a Cisco 7200 that decided to get cantankerous and reboot, which
    was replaced by a Foundry Networks router.

    It's the old "if it ain't broke don't fix it" approach. And
    FreeBSD for me is as comforatable as an old shoe, and is so much
    like the first Unix type system I learned on in 1983.

    Bill



    --
    Bill Vermillion - bv @ wjv . com

  20. Re: Telnet: route to host

    On Thu, 4 Aug 2005 22:35:11 +0100, Bill Vermillion wrote
    (in message ):

    >> However, it's not just Linux guys ....

    >
    >> When we put a firewall in at work we spent ages trying to figure
    >> out why we couldn't reach anything on the internet - pings failed
    >> altogether and traceroutes simply stopped somewhere in the ISPs
    >> network. A call to their support line enlightened us to the fact
    >> that they block pings so as to break one of the viruses, but only
    >> the sort used by Windoze.

    >
    >> Switch to one of our Unix or Linux hosts and hey presto,
    >> traceroutes and pings work !

    >
    > Or switch to an ISP that knows and understands networking. I've
    > seen some pretty stupid things done. And I've noticed more and
    > more ISP turn off the ability of using ping -R [Record Route] which
    > is awfully helpful when things don't go right, and you find packets
    > go out one way but want to come back another because someone
    > misconfigured something.


    In this case I can understand why they did it. We had a machine or two
    infected with the virus in question and I can tell you that the impact of the
    pings from just one or two machines was very noticable on our internet
    connection - literally flooding out pings to sequential addresses as fast as
    you can and waiting to see if any replies come back. Multiply by the number
    of customer the ISP (Demon Internet) has and I can see why it would be
    desirable for both the ISP and the Internet as a whole for them to block this
    one particular packet.

    It normally wouldn't affect me (I don't use windoze), but the guy setting up
    the firewall uses a windoze laptop.

    It definitely won't bother me any more as I leave the company this month :-))

    >> At home, my router doesn't seem to allow them at all, so I can't
    >> traceroute anywhere :-(

    >
    > There are plenty of routers that do. Are you sure it's not
    > something at your ISP?


    I'll be changing the router soon (for other reasons), so I'll find out.

    >> Anyway, back to the thread, in situations like this, I think the
    >> rule should simply be to drop the packets - that way it ties
    >> up resources on any machine being used to attck you. Ie, they
    >> attempt to open a connection, and instead of immediately getting
    >> back a "no way Jose" message, they must wait until the connection
    >> attempt times out. I see regular attacks on my machine, people
    >> out there are obviously trying brute-force attacks to try and
    >> connect via SSH - and it's clear they can do many attempts/second
    >> for some time, adding a few seconds to each will cause a 'cost'
    >> for the attacker. I see there's a package fail2 that
    >> automatically adds IPs to IP Tables in such situations - must
    >> take a look.

    >
    > Actually it depends upon how they are attacking you. Every now and
    > thing I get notices that the kernel is limiting responses to
    > 200 packets/second when someone tries a stong attack, perhaps with
    > a flood-ping. Limiting responses won't always help in that event.


    Whenever I've observed it, it's been a clear attempt to log in by brute force
    methods - one address makes repeated attempts to log in, I guess they hope
    that the root password is something in the dictionary or is short enough to
    find by trying a, b, ... aa, ab, ... and so on.

    > As to adding IPs to your filters you may find that your filters get
    > so big they will start slowing down.


    I've only ever observed 1 address at a time, and I would remove it from the
    filters later. All I want to do is 'my bit' towards making it 'cost' these
    people, by tying up their machine waiting for all the connection attempts to
    time out - actually I'd prefer a mechanism to exponentially back off and
    delay the failure response on each bad login.

    Anyway, that's probably enough off topic stuff !


+ Reply to Thread