Re: Lockout a country.

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 01/08/05


Date: Fri, 07 Jan 2005 18:24:16 -0600

In article <MPG.1c47cc2aecc2cced989e1d@news-server.columbus.rr.com>,
Leythos wrote:

>When I to a VR I get the NOC info for every hop, that's the nice part
>for me - full owner info and block. It means that I can quickly get the
>info from one source while viewing everything. Sure, I know it can be
>done after a tracert by doing individual looks, but that would require
>more work

Understand the 'one place to look' concept. I just never bother with
anything but the last hop, as that's really the only one you can do
anything about. As for finding what block is in what country, I find
it easier to use the RIR databases. Want to know all of the networks in
Suriname (domain SR) or Syria (domain SY)?

[compton ~]$ zgrep 'S[RY]' IP.ADDR/stats/[ALR]*
IP.ADDR/stats/LANIC.gz:SR 200.1.156.0 255.255.252.0 assigned
IP.ADDR/stats/LANIC.gz:SR 200.2.160.0 255.255.240.0 allocated
IP.ADDR/stats/RIPE.gz:SY 82.137.192.0 255.255.192.0 allocated
IP.ADDR/stats/RIPE.gz:SY 213.178.224.0 255.255.224.0 allocated
[compton ~]$

Done! (By the way, there are just under 66,000 blocks assigned in IPv4.)

I rarely use a tool that depends on ICMP echo as does tracert or mtr,
because of the frequent dropped packets. Even the UDP version it getting
less useful because of firewalls. That's where the TCP version comes in
handy - as it's RARELY blocked.

>since I use and love VR it's just a simple click to see what path takes
>me to the probing IP - the info along the path is what I'm looking for.

Usually, only the last hop or three is relevant. I just did three traces
to the 211.54.40.0/25 you mention below, and was routed via Verio through
several hops in California thence to Seattle, to HINET in Taipei and then
to KORNET when tracing to TCP:80, and to broadwing.net in Hayward California,
and direct to KORNET when tracing to UDP or TCP:53. And it's repeatable
which I find strange. Somebody upstream has some strange routing policy
setups at the moment.

>The block list appears to block anything from the ranges I specify -
>since the probe comes from a foreign host and since I can see all the
>other hops and that they are foreign, it allow me to block their ranges
>too. While I may not have got a probe from hop 15, if I can see that hop
>15 is some place in Korea and it's network block assignment, I can block
>it before I get probed.

As you have little business overseas, it might just be simpler to set a
permitted range of networks you want to hear from, and ignore the rest. That
is the base philosophy of Wietse Venema's tcpwrappers (man 5 hosts_access).

>I added 220.72.0.0/12 tonight along with 211.54.40.0/25

See RFC1878. 220.72 isn't on a /12 boundary. You may want 220.64.0.0/12
which is 220.64.0.0 - 220.95.255.255 which is five different blocks assigned
to Korea.

[compton ~]$ zgrep ' 220.[5-9][0-9]' IP.ADDR/stats/APNIC.gz
KR 220.64.0.0 255.248.0.0 allocated
KR 220.72.0.0 255.248.0.0 allocated
KR 220.80.0.0 255.248.0.0 allocated
KR 220.88.0.0 255.252.0.0 allocated
KR 220.92.0.0 255.252.0.0 allocated
JP 220.96.0.0 255.252.0.0 allocated
[compton ~]$

As far as 211.54.40.0/25 goes, you could simplify that to 211.32/12 because
the 37 blocks from 211.32.0.0 to 211.63.255.255 are all in Korea.

>I don't even bother complaining to anyone outside the US, it almost
>never does any good. It's easier to block their network and just not
>have to deal with them. If there is no reason for anyone in country XYZ
>to hit our servers I don't see any reason I should expose the network to
>them.

For certain countries, that's saving you the frustration. There are several
that have a real 'pride' problem, who tend to send complaints to /dev/null.
My home setup is simple, because I don't offer any services, and therefore
don't accept inbounds from anywhere. At work, it's a good bit more complex
because we do business overseas, but it's not unbearable.

>Here's a link to their site http://www.visualiptrace.com/index.html

Hmmm, a Java app. Funny that the requirements for Linux are "Linux 2.2.5-15"
No I don't know if that refers to 2.2.5 to 2.2.15 (I don't know of any
current distro using a kernel that old - the "current" 2.2.x kernel is
2.2.27, and all current distros are 2.4.26 to 2.4.28, or 2.6.6 to 2.6.10)
or it refers to what they saw with uname -a in which case it refers to an
ancient kernel from Red Hat - 2.2.5-15 was the out-of-box kernel for RH6.0
back in 1999. Actually, the kernel is totally irrelevant to a Java app.
Wonder why it's x86 only. Java shouldn't care. The Sloaris 2.5 is also
ancient (2.10 should be out this year), and they ignore the *BSD family
except for the OSX derivative.

Lots of handwaving - but I don't see the price listed on the web site.

        Old guy



Relevant Pages