Telnet: route to host
Nachman Yaakov Ziskind
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 aw...@ziskind.us
Attorney and Counselor-at-Law http://ziskind.us
Economic Group Pension Services http://egps.com
Actuaries and Employee Benefit Consultants
Brian K. White
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 -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Bela Lubkin
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<
Nachman Yaakov Ziskind
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
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? <Shrugs>:
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?
Bela Lubkin
> 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<
Brian K. White
----- Original Message -----
From: "Nachman Yaakov Ziskind" <aw...@ziskind.us>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
How it the world did you read Bela's last paragraph, and still write this?
Brian K. White
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.
Nachman Yaakov Ziskind
> 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
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
> > 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. :-)
Bill Vermillion
Nachman Yaakov Ziskind <aw...@ziskind.us> 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
Nachman Yaakov Ziskind
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
--
Simon Hobson
(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<something> that automatically adds IPs to IP Tables in such situations
- must take a look.
Simon
Bill Vermillion
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 Vermillion
Simon Hobson <simon...@thehobsons.codotuk> 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<something> 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.
Joe Dunning
> In article <0001HW.BF18246A...@usenet.plus.net>,
> Simon Hobson <simon...@thehobsons.codotuk> 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.
Joe Dunning
> Nachman Yaakov Ziskind <aw...@ziskind.us> 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?
>
>
Bill Vermillion
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.
Simon Hobson
(in message <IKpvn...@wjv.com>):
>> 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<something> 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 !