Can anyone else get to ripe.net ?
I cannot seem to access the whois or any other service (my ripe traffic goes through Sprint).
When I ping peach.ripe.net, I get 90%+ missing packets + "destination host unreachable"
from inside Sprint.
Regards
Marshall Eubanks
Can anyone else get to ripe.net ?
I cannot seem to access the whois or any other service (my ripe traffic
goes through Sprint).
When I ping peach.ripe.net, I get 90%+ missing packets + "destination
host unreachable"
from inside Sprint.
The same goes for me via qwest/Level3.
----peach.ripe.net PING Statistics----
24 packets transmitted, 3 packets received, 87% packet loss
round-trip (ms) min/avg/max = 127/127/127
-Jack
Same here on packet loss.. I see issues @level3 in Amsterdam, and this is
going out a tranist link from Qwest.
# ping peach.ripe.net
PING peach.ripe.net (193.0.0.203): 56 octets data
64 octets from 193.0.0.203: icmp_seq=2 ttl=241 time=86.2 ms
64 octets from 193.0.0.203: icmp_seq=4 ttl=241 time=86.1 ms
64 octets from 193.0.0.203: icmp_seq=5 ttl=241 time=86.2 ms
64 octets from 193.0.0.203: icmp_seq=6 ttl=241 time=86.4 ms
--- peach.ripe.net ping statistics ---
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 86.1/86.2/86.4 ms
I'm a bit closer than yuo,
we see multiple flaps on their routes.
25396 15703 12859 3333
193.109.219.130 from 193.109.219.130 (213.160.111.1)
Origin IGP, localpref 150, valid, external
Community: 6320:1004 6320:2002 6320:21238 15703:22001 25396:15703
Dampinfo: penalty 441, flapped 1 times in 00:02:46
7176 3333, (suppressed due to dampening)
195.66.224.74 from 195.66.224.74 (195.16.160.29)
Origin IGP, metric 1090, localpref 100, valid, external
Community: 6320:1004 6320:2003 6320:7176
Dampinfo: penalty 3298, flapped 14 times in 00:54:45, reuse in 00:32:00
1136 3333
195.66.224.163 from 195.66.224.163 (194.151.224.192)
Origin IGP, metric 70, localpref 150, valid, external, best
Community: 6320:1004 6320:2002 6320:5459
Dampinfo: penalty 1899, flapped 7 times in 01:02:51
6461 12859 3333
208.185.188.165 from 208.185.188.165 (207.126.96.50)
Origin IGP, metric 721, localpref 150, valid, external
Community: 6320:1004 6320:2002 6320:3000
6461 12859 3333
195.66.224.76 from 195.66.224.76 (209.249.254.202)
Origin IGP, metric 741, localpref 150, valid, external
Community: 6320:1004 6320:2002 6320:5459
13237 12859 3333
195.66.224.99 from 195.66.224.99 (80.245.35.6)
Origin IGP, metric 20, localpref 150, valid, external
Community: 6320:1004 6320:2002 6320:5459 12859:1000 12859:4000
Dampinfo: penalty 875, flapped 1 times in 00:02:54
3291 3333 (history entry)
195.66.224.14 from 195.66.224.14 (154.14.65.2)
Origin IGP, metric 20, localpref 150, external
Community: 6320:1004 6320:2002 6320:5459
Dampinfo: penalty 1001, flapped 5 times in 01:03:26
same here.
both for 193.0.0.203 and 193.0.0.193
the buck stops at the KPN Internet Operator at 195.190.227.37
Thursday, February 27, 2003, 3:04:55 PM, Marshall wrote:
Got told by an insider they are under a very nasty icmp attack, I guess
they're little busy to get the chance to reply.
-Subhi
back to normal here
AMS-IX 193.194.136.2
RIPE 193.0.0.193
And on a related topic (whois.ripe.net almost unreachable, along with
the rest of RIPE): rwhois.level3.net:4321 as been MIA or AWOL for
about 4 days: Level3 was informed, but seems to have some good reasons
of their own not to fix this....
$ telnet rwhois.level3.net 4321
Trying 209.244.1.179...
telnet: Unable to connect to remote host: Connection refused
There is no public access to rwhois.level3.net (it worked at one point,
but, accurding to Level3, not intentionally). They say that they don't
have to make this information available to anyone except ARIN. I was
always under the impression that delegations had to be publicly visible,
but looking at ARIN's policy more closely, it seems that the information
only has to be available to ARIN.
If the ARIN server recurses properly, you should be able to pull it
out that way. So hiding it from everybody but ARIN doesn't make the
information unavailable. They're probably sheltering themselves from
security concerns in the server.
-Dave
Secrecy over a public resource = no oversight = facilitator of abuse.
It has worked as long as I can remember, and them intentionally
shutting it off is completely against letter and spirit of
ARIN's allocation policy: rwhois, or SWIP delegations, but not
"none of the above". 7018 Realized this for 12.0.0.0/8 at some
point.
Why do I get the distinct feeling that this "move" by Level3 is
aimed not at creating greater customer privacy (it never served
POC email addresses), or protecting themselves from getting their
customer base poached by other providers, but at preventing
people from identifying spamming Level3 customers (of which they
seem to have 100's) by organization name and being able to
correlate activity from different netblocks of theirs.
So instead of select prefixes, most longer than /24 appearing in
the various DNSBLs that do manual listing "by organization"
(Spamhaus SBL, SPEWS, Wirehub), Level3 customers can now look
forward to /24 to /17 knock-outs that should absolutely positive
cover the hiding criminal scum they so willingly receive money
from. And then some. If you are a Level3 customer using Level3
IP space, you might want to expediously insist that your IP space
delegation appears at whois.arin.net properly, or else consider
a new network provider or buying yourself your own /16 on the
grey market^W^W^W^Wacquire a defunct company with a mostly
unused /16.
What did Randy once say?
"I welcome my competitors running their networks this way"....
(paraphrased)
Though I agree, Level3 seems to host a good number of spammers, they're by
no means the only guilty party. Pulled at random from recent spams I've
submitted to NJABL are 69.6.4.104, 69.6.4.114, and 69.6.4.156. whois
@arin.net yields the following:
...
NetRange: 69.6.0.0 - 69.6.63.255
CIDR: 69.6.0.0/18
NetName: WHOLE-2
NetHandle: NET-69-6-0-0-1
Parent: NET-69-0-0-0-0
NetType: Direct Allocation
NameServer: NS1.WHOLESALEBANDWIDTH.COM
NameServer: NS2.WHOLESALEBANDWIDTH.COM
...
Where are the swips? The rest of that record makes no mention of an
rwhois server. Doing a bunch of whois requests for IPs in that block, I
found only one swip (for a /21). I realize the ARIN regs don't seem to
require that reassignment info be made available to the public (just to
ARIN), but using your innocent customers (if there are any) as a shield to
hide your spammer customers is just wrong. Should I block 69.6.4.0/24
from sending email into my systems? 69.6.0.0/18?
http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.104
http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.114
http://www.njabl.org/cgi-bin/lookup.cgi?query=69.6.4.156
We (Atlantic.Net) have gotten a flurry of abuse complaints from people
who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL
hosted on our network). I'm hoping the new PTR record will head off many
complaints now.
For the past 15 months, NJABL has reactively tested systems that have
connected to participating SMTP servers to see if those systems are open
relays. Just over a week ago, NJABL added open proxy testing to its relay
testing software. The proxy testing checks for a variety of common proxy
software/protocols on about 20 different ports simultaneously. This is
apparently setting off some IDS/firewall alarms.
We do not consider what NJABL does abuse, and we reply to all the
complaints explaining that the complainant should go have a look at
http://njabl.org/ and hopefully they'll understand why their system was
scanned.
This sort of activity is becoming more common / mainstream, so people
ought to just get used to it. Road Runner is doing the same thing
(according to http://sec.rr.com/probing.htm) which is pretty ironic given
how their security department has gotten along with (or not) various
DNSBLs in the past.
BTW...in the week that NJABL has been testing for open proxies, more than
18000 have been detected, pretty much all of which are actively being
abused by spammers, else mail would not have come through them.
We (Atlantic.Net) have gotten a flurry of abuse complaints from people
who's systems have been scanned by 209.208.0.15 (rt.njabl.org...a DNSBL
hosted on our network). I'm hoping the new PTR record will head off many
complaints now.For the past 15 months, NJABL has reactively tested systems that have
connected to participating SMTP servers to see if those systems are open
relays. Just over a week ago, NJABL added open proxy testing to its relay
testing software. The proxy testing checks for a variety of common proxy
software/protocols on about 20 different ports simultaneously. This is
apparently setting off some IDS/firewall alarms.We do not consider what NJABL does abuse, and we reply to all the
Ahh, yes. The age old debate. So long as you, their provider, doesn't
consider it abuse, they should be relatively safe. Obviously, there are some
net blocks up to stop the probes. There always are and always will be.
Networks don't like scans. One thing I'll say about NJABL, it's probably the
most accurate list for what it does. With the added proxy testing, they'll
get more people using the list, along with more complaints. I'll be adding
my log IP's to that list soon enough.
-Jack
It has always been my opinion that if somebody connects to you, they
are implicitly granting you the right to connect back to them on
well-known ports. I have discussed this opinion with several dozen
people and have yet to find one who disagrees. (Though I'm sure
they're probably out there.)
I've dealt with any number of abuse complaints, many from
governmental and quasi-governmental group. They've all accepted my
cut/pasted explanation and we've been whitelisted by several such
organizations.
I often use the following as the 'meat' paragraph of my reply:
"In accord with our terms of service, when someone makes a connection
to one of our machines, we make connections back to them to ensure
they're not connecting through an open proxy. These connections are
to each of the ports on which such proxies commonly run and some
ports may require more than one connection to test multiple
protocols. We never do such a probe except as a response to a
connection made to us."
I haven not checked NJABL but some of the other other open relay testers use
scenarios that are illegal (actually criminal) in California.
Roy
jlewis@lewis.org wrote:
> For the past 15 months, NJABL has reactively tested systems that have
> connected to participating SMTP servers to see if those systems are open
> relays. ...
>
> We do not consider what NJABL does abuse, ...
Jon,
If "they" are indeed only testing systems who connect to them, it's not
abuse, and I would not have complained. However, they scanned every
address in every netblock I own, looking for SMTP servers. That was
abuse, that was illegal in California, and I was shocked that you "allowed"
"them" to behave that way. Hopefully my inference is correct and "they"
are now scanning only the hosts which connect to participating SMTP servers.
Paul
Paul raises good questions about the level of response to incoming SMTP traffic. If contacted for transmission of SMTP, do you have the right to go probe the sending system for all possible vulnerabilities, or only ones that relate directly to email? Clearly there are concerns about email coming from open relays, and from open proxies. The degree of scanning could easily cross the line from warranted to abusive, and potentially illegal.
Scanning machines "in the neighborhood" sure seems far over the line. This is further complicated by the difficulty in determining the size of the "neighborhood" (read: netblock assigned to a customer).
While we would all like to find some solution to the spam problem before email is rendered useless, measures which themselves threaten the network with denial of service attacks and other measures can be considered just as damaging.
Yo Paul!
More importantly, could somebody provide some sort of moral basis for this
law? (I'm not sure if Paul feels the way he wrote, or if there was a bit
of tongue-in-cheeck...I suspect and hope the latter.)
Why is probing networks wrong?
I would agree exploiting vulnerabilities discovered from probing networks
is wrong. But I don't agree that probing is inherently wrong.
People probe networks for great reasons. Likewise, people have the ability
to prevent other people from probing their networks.
Should we outlaw a potentially beneficial practice due to its abuse by
criminals?
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Andy Dills 301-682-9972
Xecunet, LLC www.xecu.net
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Dialup * Webhosting * E-Commerce * High-Speed Access