Is there a list of all IP ranges, perhaps with masking, used in
North America, Hawaii, and Alaska? Might it be better to just
allow those networks rather than hassle with blocking the rest
of the globe?

Thanks

"Alan Jones" <alan@alanjones.us> wrote in message
news:3gebq15bc9mjb8echf3u9vrqfudtlcrvh1@4ax.com

> Is there a list of all IP ranges, perhaps with masking, used in
> North America, Hawaii, and Alaska? Might it be better to just
> allow those networks rather than hassle with blocking the rest
> of the globe?

A very large percentage of spam originates from those addresses.

And 100 times more comes from China, Korea, Russia, Latvia, etc.
Cutting those areas out would be a tremendous help.

On Sun, 18 Dec 2005 12:49:15 -0800, "ynotssor"
<ynotssor@example.net> wrote:

>A very large percentage of spam originates from those addresses.

Alan Jones wrote:
> On Sun, 18 Dec 2005 12:49:15 -0800, "ynotssor"
> <ynotssor@example.net> wrote:
>
>
>>A very large percentage of spam originates from those addresses.

(-- top-posting corrected, TV --)

> And 100 times more comes from China, Korea, Russia, Latvia, etc.
> Cutting those areas out would be a tremendous help.

Even that *really* originates in the US, but the
hosts in said places are easier to crack for acting
as zombies for the spammers.

--

Tauno Voipio
tauno voipio (at) iki fi

On Sun, 18 Dec 2005 14:37:41 -0500, Alan Jones wrote:

>
> Is there a list of all IP ranges, perhaps with masking, used in
> North America, Hawaii, and Alaska? Might it be better to just
> allow those networks rather than hassle with blocking the rest
> of the globe?
>
> Thanks

24/8 will work. Also 80/6.


--

Felix Tilley
MAJ, LARTvocate
Fanatic Legions
1-800-555-LART

I doubt the majority of it does but so what anyway? I still
don't want it getting into my server from overseas IP's.
Again, removing that avenue will help greatly.

On Sun, 18 Dec 2005 22:27:02 GMT, Tauno Voipio
<tauno.voipio@INVALIDiki.fi> wrote:

>Even that *really* originates in the US,

Thanks but I found the 'list' of IP ranges I needed. :)

On Sun, 18 Dec 2005 15:31:32 -0700, Felix Tilley
<ftilley@cyberbromo.int> wrote:

>24/8 will work. Also 80/6.

Alan Jones wrote:
> Thanks but I found the 'list' of IP ranges I needed. :)
>

You do also realise that the list may not be 100% accurate. Those IP
assigned may have been through a 3rd party acting as a broker for a
non-US party.

Here's the list. Please tell me what you think...
http://www.iana.org/assignments/ipv4-address-space

On Mon, 19 Dec 2005 14:39:11 +1000, Wayne <4bu53@h0tm417.c0m> wrote:

>Alan Jones wrote:
>> Thanks but I found the 'list' of IP ranges I needed. :)
>>
>
>You do also realise that the list may not be 100% accurate. Those IP
>assigned may have been through a 3rd party acting as a broker for a
>non-US party.

"Alan Jones" <alan@alanjones.us> wrote in message
news:77pdq1l8qn1pu49edckpom6m7ra51dtus2@4ax.com

> Here's the list. Please tell me what you think...
> http://www.iana.org/assignments/ipv4-address-space

0.0.0.0/32 will keep you "safe."

Alan Jones wrote:

>
> Here's the list. Please tell me what you think...
> http://www.iana.org/assignments/ipv4-address-space

That a very large number of the IP addresses on that list which appear to
be inside the US are probably pointing to machines that reside outside
North America. The fact that an IP address block is allocated to an
American registrar or company doesn't mean that said entity can't make it
point to any machine anywhere in the world.

Likewise, it's trivial to make an APNIC address point to a machine in
Kansas. ;)

>
> On Mon, 19 Dec 2005 14:39:11 +1000, Wayne <4bu53@h0tm417.c0m> wrote:
>
>>Alan Jones wrote:
>>> Thanks but I found the 'list' of IP ranges I needed. :)
>>>
>>>
>>You do also realise that the list may not be 100% accurate. Those IP
>>assigned may have been through a 3rd party acting as a broker for a
>>non-US party.

On Sun, 18 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<3gebq15bc9mjb8echf3u9vrqfudtlcrvh1@4ax.com>, Alan Jones wrote:

>Is there a list of all IP ranges, perhaps with masking, used in
>North America, Hawaii, and Alaska?

If by North America, you mean the US alone - try http://www.blackholes.us/
or http://countries.nerd.dk/ You should be aware you are going to run
into a few problems with that.

>Might it be better to just allow those networks rather than hassle with
>blocking the rest of the globe?

[compton ~]$ grep -c US IP.ADDR/stats/[ALR]* | grep -v ':0'
IP.ADDR/stats/APNIC:5
IP.ADDR/stats/ARIN:31386
[compton ~]$ cat IP.ADDR/stats/[ALR]* | grep -vc US
39191
[compton ~]$

The US has 31391 assignments - the rest of the world 39191. That's as of
the 15th. If you want to add Canada, that's 4936 more - (36327 vs 34255).

[compton ~]$ grep -h US IP.ADDR/stats/A* | cut -d' ' -f2 | cut -d'.' -f1 | sort
-nu | column
3 17 32 55 71 134 146 157 168 204
4 18 33 56 72 135 147 158 169 205
6 19 34 60 73 136 148 159 170 206
7 20 35 63 74 137 149 160 171 207
8 21 38 64 75 138 150 161 172 208
9 22 40 65 76 139 151 162 192 209
11 24 44 66 128 140 152 163 196 214
12 26 45 67 129 141 153 164 198 215
13 28 48 68 130 142 154 165 199 216
15 29 52 69 131 143 155 166 200
16 30 54 70 132 144 156 167 202
[compton ~]$ grep -hv US IP.ADDR/stats/[ALR]* | cut -d' ' -f2 | cut -d'.' -f1 |
sort -nu | column
24 62 80 125 137 148 159 170 200 211
25 63 81 126 138 149 160 171 201 212
43 64 82 128 139 150 161 188 202 213
47 65 83 129 140 151 162 190 203 216
51 66 84 130 141 152 163 192 204 217
53 67 85 131 142 153 164 193 205 218
57 68 86 132 143 154 165 194 206 219
58 69 87 133 144 155 166 195 207 220
59 70 88 134 145 156 167 196 208 221
60 71 89 135 146 157 168 198 209 222
61 72 124 136 147 158 169 199 210
[compton ~]$

That's the first octet of the address. You might note considerable overlap.
Addresses were not assigned by the RIRs on a country blocking basis. See
http://www.iana.org/assignments/ipv4-address-space and note all those
"Various" blocks.

Old guy

Alan Jones wrote:
> Here's the list. Please tell me what you think...
> http://www.iana.org/assignments/ipv4-address-space
>
> On Mon, 19 Dec 2005 14:39:11 +1000, Wayne <4bu53@h0tm417.c0m> wrote:
>
> >Alan Jones wrote:
> >> Thanks but I found the 'list' of IP ranges I needed. :)
> >>
> >
> >You do also realise that the list may not be 100% accurate. Those IP
> >assigned may have been through a 3rd party acting as a broker for a
> >non-US party.

If you are trying to cut down on spam, try SpamAssassin.
http://spamassassin.apache.org/

If you're trying to add security to your network, harden your firewall
and tighten down your firewall rules. Review your logs. Deny _all_
connections except the ones you invite.

The list you have might be somewhat useful (for something) if
_everyone_ conformed to its intent. The ones you are trying to keep
out are the ones who don't.

Packets are routed by _destination_ and _not_by_source_ addresses.
Spam will 99.9999999999% of the time have a bogus IP return address
_except_ for an embedded link of some kind, ie., a connection you
_invite_ into your site.

Your "solution" has been proposed and tried by countless numbers of
those unknowledgeable in the ways of routing across the net. It's a
waist of time and firewall resources. It promotes an unfounded sense
of "increased security" -- perhaps the most detrimental and dangerous
thing for _any_ network.

Check here for some rather disturbing insight into how even
"unroutable" IPs are loose on the net:

http://www.completewhois.com/bogons/
[q]
Bogons is the name used to describe ip blocks not allocated by IANA and
RIRs to ISPs and organizations plus all other ip blocks that are
reserved for private or special use by RFCs (the actual term "bogons"
comes from word "bogus", as in bogus ip announcements). As these ip
blocks are not allocated or specially reserved, such ip blocks should
not be routable and used on the internet, however some of these ip
blocks do appear on the net primarily used by those individuals and
organizations that are often specifically trying to avoid being
identified and are often involved in such activities as DoS attacks,
email abuse, hacking and other security problems. These activities
obviously pose great danger to everyone and ***ISPs***[emphasis added]
should try to filter all these bad ip routes and we are trying to help
in that by working to create complete detailed list of unassigned bogon
ips based on whois data.
[eq]
http://www.completewhois.com/bogons/data/bogons-cidr-all.txt
http://www.completewhois.com/bogons/bogons_usage.htm
http://www.completewhois.com/hijacked/index.htm
http://www.completewhois.com/bogons/ipwhois_data_analysis.htm
http://www.completewhois.com/bogons/data/ <-- the current data
http://www.completewhois.com/statistics/index.htm <-- stats re: your
IANA list
http://www.completewhois.com/statistics/country_statistics.htm
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/
http://www.completewhois.com/rbl_lookup.htm

ISPs have (or should have) the resources to filter these problems
_without_ crippling the flow of legitimate traffic. You do not. Note
that even this effort has been something less than a stellar success.

And the idea of blocking out the _world_ at large (non-US) makes the
net rather pointless, don't you think?

The most successful(?)/used approach is to use RBLs and DNSBLs
(black/block lists) of "known" or suspected spammers or even netblocks
without DNS ptr records. Try these:

http://www.completewhois.com/rbl_lookup.htm
http://openrbl.org/
http://wiki.openrbl.org/wiki/Main_Page
http://www.nl.sorbs.net/ <-- a _very_ aggressive black list
http://spamblock.outblaze.com/spamchk.html
http://www.dnsstuff.com/tools/ip4r.ch?ip=you.rIP.add.res
EGs.,
http://www.dnsstuff.com/tools/ip4r.ch?ip=24.204.27.78 <-- a bogon that
I chased last year
http://groups.google.com/groups?hl=en&lr=lang_en&ie=ISO-8859-1&q=cablelynx.com&btnG=Search&meta=group%3Dnews.admin.net-abuse.sightings
[Yes, even google helps in a chase]

Additional info:
http://www.abuse.net/
http://spam.abuse.net/userhelp/
http://www.arin.net/reference/index.html

This barely scratches the surface ;-(

good luck,
prg

On Mon, 19 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<40ob1jF1aunprU1@individual.net>, ynotssor wrote:

>"Alan Jones" <alan@alanjones.us> wrote in message
>news:77pdq1l8qn1pu49edckpom6m7ra51dtus2@4ax.com
>
>> Here's the list. Please tell me what you think...
>> http://www.iana.org/assignments/ipv4-address-space

What continent is covered by "Various Registries"

>0.0.0.0/32 will keep you "safe."

0.0.0.0/0 is better ;-)

Old guy

On Mon, 19 Dec 2005 14:11:15 -0600, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>What continent is covered by "Various Registries"

Good question. :)

>>0.0.0.0/32 will keep you "safe."
>
>0.0.0.0/0 is better ;-)

I would have said '0.0.0.0/8' but didn't want to go there
for the sake of argument. :D

On 19 Dec 2005 12:09:44 -0800, "prg" <rdgentry1@cablelynx.com>
wrote:

>
>Alan Jones wrote:
>> Here's the list. Please tell me what you think...
>> http://www.iana.org/assignments/ipv4-address-space
>>
>> On Mon, 19 Dec 2005 14:39:11 +1000, Wayne <4bu53@h0tm417.c0m> wrote:
>>
>> >Alan Jones wrote:
>> >> Thanks but I found the 'list' of IP ranges I needed. :)
>> >>
>> >
>> >You do also realise that the list may not be 100% accurate. Those IP
>> >assigned may have been through a 3rd party acting as a broker for a
>> >non-US party.
>
>If you are trying to cut down on spam, try SpamAssassin.
>http://spamassassin.apache.org/

Not reliable and a hassle.

>If you're trying to add security to your network, harden your firewall
>and tighten down your firewall rules. Review your logs. Deny _all_
>connections except the ones you invite.

Really? What do you think I'm doing.

>The list you have might be somewhat useful (for something) if
>_everyone_ conformed to its intent.

Nope. What I'm doing applies to my server alone.

>The ones you are trying to keep out are the ones who don't.

Brilliant.

>Packets are routed by _destination_ and _not_by_source_ addresses.
>Spam will 99.9999999999% of the time have a bogus IP return address
>_except_ for an embedded link of some kind, ie., a connection you
>_invite_ into your site.

With my setup, only bogus 'domestic' or North American IP's
can connect. That's a very big help.

>Your "solution" has been proposed and tried by countless numbers of
>those unknowledgeable in the ways of routing across the net. It's a
>waist of time and firewall resources. It promotes an unfounded sense
>of "increased security" -- perhaps the most detrimental and dangerous
>thing for _any_ network.

Again, it only affects my server and it's working great.

>Check here for some rather disturbing insight into how even
>"unroutable" IPs are loose on the net:
>
>http://www.completewhois.com/bogons/
>[q]
>Bogons is the name used to describe ip blocks not allocated by IANA and
>RIRs to ISPs and organizations plus all other ip blocks that are
>reserved for private or special use by RFCs (the actual term "bogons"
>comes from word "bogus", as in bogus ip announcements). As these ip
>blocks are not allocated or specially reserved, such ip blocks should
>not be routable and used on the internet, however some of these ip
>blocks do appear on the net primarily used by those individuals and
>organizations that are often specifically trying to avoid being
>identified and are often involved in such activities as DoS attacks,
>email abuse, hacking and other security problems. These activities
>obviously pose great danger to everyone and ***ISPs***[emphasis added]
>should try to filter all these bad ip routes and we are trying to help
>in that by working to create complete detailed list of unassigned bogon
>ips based on whois data.
>[eq]
>http://www.completewhois.com/bogons/data/bogons-cidr-all.txt
>http://www.completewhois.com/bogons/bogons_usage.htm
>http://www.completewhois.com/hijacked/index.htm
>http://www.completewhois.com/bogons/ipwhois_data_analysis.htm
>http://www.completewhois.com/bogons/data/ <-- the current data
>http://www.completewhois.com/statistics/index.htm <-- stats re: your
>IANA list
>http://www.completewhois.com/statistics/country_statistics.htm
>http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/
>http://www.completewhois.com/rbl_lookup.htm

I had already looked at that, and it was a contributing factor
for the solution I've chosen.

>ISPs have (or should have) the resources to filter these problems
>_without_ crippling the flow of legitimate traffic. You do not.

I have available to me all the resources in existence for the
complete and total control of my server.

>Note
>that even this effort has been something less than a stellar success.

>And the idea of blocking out the _world_ at large (non-US) makes the
>net rather pointless, don't you think?

No it doesn't. My server doesn't need to have access to every
part of the globe.

>The most successful(?)/used approach is to use RBLs and DNSBLs
>(black/block lists) of "known" or suspected spammers or even netblocks
>without DNS ptr records. Try these:
>
>http://www.completewhois.com/rbl_lookup.htm
>http://openrbl.org/
>http://wiki.openrbl.org/wiki/Main_Page
>http://www.nl.sorbs.net/ <-- a _very_ aggressive black list
>http://spamblock.outblaze.com/spamchk.html
>http://www.dnsstuff.com/tools/ip4r.ch?ip=you.rIP.add.res
>EGs.,
>http://www.dnsstuff.com/tools/ip4r.ch?ip=24.204.27.78 <-- a bogon that
>I chased last year
>http://groups.google.com/groups?hl=en&lr=lang_en&ie=ISO-8859-1&q=cablelynx.com&btnG=Search&meta=group%3Dnews.admin.net-abuse.sightings
>[Yes, even google helps in a chase]
>
>Additional info:
>http://www.abuse.net/
>http://spam.abuse.net/userhelp/
>http://www.arin.net/reference/index.html
>
>This barely scratches the surface ;-(
>
>good luck,

I solved the problem late yesterday evening. All is well.

>prg

I'm allowing, inbound to port 25, only 'ARIN' controlled IP ranges.
As you know, ARIN serves North America. Any problems arising
from that policy will be handled individually. Any additional
needed avenues will be opened up on a case-by-case basis. I
just feel that is a more productive approach than trying block
what seems to be an endless range of IP's from countries that
have no business viewing my web pages let alone connecting to
port 25.

On Mon, 19 Dec 2005 14:07:53 -0600, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>Addresses were not assigned by the RIRs on a country blocking basis. See
>http://www.iana.org/assignments/ipv4-address-space and note all those
>"Various" blocks.

On Mon, 19 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<069eq1d59ahj4h9qpm179led8126r7foti@4ax.com>, Alan Jones wrote:

>I'm allowing, inbound to port 25, only 'ARIN' controlled IP ranges.
>As you know, ARIN serves North America.

Not so.

[compton ~]$ cat IP.ADDR/stats/ARIN | cut -d' ' -f1 | sort -u | column
AG BB CH FI HU JP LC PR VG
AI BE CZ FR IE KN LU SE VI
AR BM DE GB IL KR NL SG
AT BS DO GD IT KY NO TR
AU CA ES HK JM LB PL US
[compton ~]$

Since when is Argentina (AR), Austria (AT), Australia (AU), Switzerland
(CH), The Czech Republic (CZ), Germany (DE) and so on in North America?

>Any problems arising from that policy will be handled individually. Any
>additional needed avenues will be opened up on a case-by-case basis.

Do you really expect to get mail from all of the blocks in North America?

>I just feel that is a more productive approach than trying block
>what seems to be an endless range of IP's from countries that
>have no business viewing my web pages let alone connecting to
>port 25.

You may find it easier to use the Tactical Nuclear method of filtering.
For example, if you don't expect US business like HP, GE, or IBM to
want to connect, you can poke holes at 4.0.0.0/8, 8.0.0.0/8, 12.0.0.0/8
24.0.0.0/8 (but some of that block is used elsewhere)

[compton ~]$ grep -h ' 24\.' IP.ADDR/stats/[ALR]* | cut -d' ' -f1 | sort
-u | column
AR BS CA CL NL PR US
[compton ~]$

38.0.0.0/8, 46.0.0.0/7, 63.0.0.0/8, 64.0.0.0/4, 192.0.0.0/8 (again, lots
of countries), 196.0.0.0/8, 198.0.0.0/7, (same problem), 204.0.0.0/6,
208.0.0.0/7 and 216.0.0.0/8 while blocking or ignoring everything else.

You may wind up missing a lot - but that's your decision. But even with
these Draconian rules, you're not going to block all "non North American"
IPs.

Old guy

In article <77pdq1l8qn1pu49edckpom6m7ra51dtus2@4ax.com>, Alan Jones wrote:
>
> Here's the list. Please tell me what you think...
> http://www.iana.org/assignments/ipv4-address-space

Interesting that "Digital Equipment Corporation" and
"Bolt Beranek and Newman" still own /8s. DEC was
carved up and eaten by Compaq and Intel, with the
best part (Alpha) going elsewhere. BBN ain't the same
BBN. Also interesting that Halliburton owns one.

The IANA list is fairly useless for blocking by nation
of origin. The original poster would perhaps be more
interested in www.blackholes.us.

Another poster advised blocking 24/8. It's a good idea,
but when we tried it we discovered dozens of outbound
MTAs belonging to cable TV operators Videotron.ca,
RR.com, Shaw.ca, Charter.com, Cox.net, and some little
ones in Virginia. If your business wants mail from
consumers, be careful there.

We've been refusing email from 60/8, 219/8, 221/8,
and 222/8 for years, with no complaints from anybody.
I'm tempted to do it at the firewall instead of the
email server. Likewise 200/7, but a few of my users
have correspondents down there.

Speaking of 221 and 222. Consider the Great Firewall
of China, grepping for keywords offensive to the
PRC government like "slave labor" and "free Tibet".
Our MTA rejects SMTP from there, with some of those
keywords in our 553 message.
What if everybody did that? (Fat chance.) What if
1% of us did? Spammers causing false firewall hits
could help change the PRC's current policy towards
hosting them. At the least, it sure would raise
the false positive rate.


Cameron

In article <1135022984.734741.90890@o13g2000cwo.googlegroups.c om>, prg wrote:
>
> If you are trying to cut down on spam, try SpamAssassin.
> http://spamassassin.apache.org/

Filtering is nice for cleaning up the stragglers that
get past the source-IP block list checking.
But there's no reason for most places to accept email
from IP ranges owned by spam houses. I don't care
if it's Python Video or Hanaro.net. If they sent it,
I'm absolutely sure my users don't want it, and there's
no reason to give it further CPU time.
*Filtering* all that crap would cost a lot more.

> The list you have might be somewhat useful (for something) if
> _everyone_ conformed to its intent. The ones you are trying to keep
> out are the ones who don't.

The sbl-xbl.spamhaus.org list (for example) is more than
"somewhat" useful. I don't care if "_everyone_ conformed"
(whatever that means), just that it meets my organizations'
needs.


> Packets are routed by _destination_ and _not_by_source_ addresses.
> Spam will 99.9999999999% of the time have a bogus IP return address

I'm not sure what you're talking about there. The source IP
is, as far as I know, the most difficult thing for the spammer
to forge. (Well, he can forge it, but he's got to be able to
collect your responses to the forged addreses, or he can't send
spam that way.) He's got to do some kind of asymmetric routing
trick. Rumor has it Alan Ralsky was doing that for a while.
His crap would seem to come from a throwaway dialup account,
but there was way too much of it for that to be true.
That trick became useless when lists of dynamically-assigned
IP ranges became available in DNSBL form. It's no use
pretending to be a dial-up if everybody's blocking those.


> Your "solution" has been proposed and tried by countless numbers of
> those unknowledgeable in the ways of routing across the net.

Blocking by source-IP is one of the most important techniques
for keeping spam out. I doubt there are many networks with more
than a few thousand mailboxes that *don't* do it, at least a
little, if only to reduce the load on their filtering machines.


Cameron

On Mon, 19 Dec 2005 19:40:59 -0600, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>On Mon, 19 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
><069eq1d59ahj4h9qpm179led8126r7foti@4ax.com>, Alan Jones wrote:
>
>>I'm allowing, inbound to port 25, only 'ARIN' controlled IP ranges.
>>As you know, ARIN serves North America.
>
>Not so.
>
>[compton ~]$ cat IP.ADDR/stats/ARIN | cut -d' ' -f1 | sort -u | column
>AG BB CH FI HU JP LC PR VG
>AI BE CZ FR IE KN LU SE VI
>AR BM DE GB IL KR NL SG
>AT BS DO GD IT KY NO TR
>AU CA ES HK JM LB PL US
>[compton ~]$
>
>Since when is Argentina (AR), Austria (AT), Australia (AU), Switzerland
>(CH), The Czech Republic (CZ), Germany (DE) and so on in North America?

I can only go by what ARIN says...
http://www.arin.net/community/ARINcountries.html

Even with some bleed-over, allowing only ARIN IP's has been a
'very' big help.

>>Any problems arising from that policy will be handled individually. Any
>>additional needed avenues will be opened up on a case-by-case basis.
>
>Do you really expect to get mail from all of the blocks in North America?

Probably not. Again, it will be handled on a case-by-case basis.

>>I just feel that is a more productive approach than trying block
>>what seems to be an endless range of IP's from countries that
>>have no business viewing my web pages let alone connecting to
>>port 25.
>
>You may find it easier to use the Tactical Nuclear method of filtering.
>For example, if you don't expect US business like HP, GE, or IBM to
>want to connect, you can poke holes at 4.0.0.0/8, 8.0.0.0/8, 12.0.0.0/8
>24.0.0.0/8 (but some of that block is used elsewhere)

I have those blocks allowed.

>[compton ~]$ grep -h ' 24\.' IP.ADDR/stats/[ALR]* | cut -d' ' -f1 | sort
>-u | column
>AR BS CA CL NL PR US
>[compton ~]$
>
>38.0.0.0/8, 46.0.0.0/7, 63.0.0.0/8, 64.0.0.0/4, 192.0.0.0/8 (again, lots
>of countries), 196.0.0.0/8, 198.0.0.0/7, (same problem), 204.0.0.0/6,
>208.0.0.0/7 and 216.0.0.0/8 while blocking or ignoring everything else.

Except for 192, I have those blocks allowed.

>You may wind up missing a lot - but that's your decision. But even with
>these Draconian rules, you're not going to block all "non North American"
>IPs.

Again, I believe fine-tuning on a case-by-case basis is more
productive than playing the never-ending deny hosts game.
'Tactical Nuclear' and 'Draconian' is how I describe spamming
and SSH attacks. Why should I play nice when they don't...

ARIN says it serves only pretty much North America. I realize
that's probably not completely accurate but, for me, it's a start;
a set of IP blocks to begin with and fine-tune. :)

http://www.arin.net/community/ARINcountries.html

On 20 Dec 2005 01:41:08 GMT, "Cameron L. Spitzer"
<spambait@merde.greens.org> wrote:

>The IANA list is fairly useless for blocking by nation
>of origin. The original poster would perhaps be more
>interested in www.blackholes.us.

On Mon, 19 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<f1peq1lg6evf4cq82o8v5rmvt9mh8somn9@4ax.com>, Alan Jones wrote:

>> Since when is Argentina (AR), Austria (AT), Australia (AU), Switzerland
>> (CH), The Czech Republic (CZ), Germany (DE) and so on in North America?
>
>I can only go by what ARIN says...
>http://www.arin.net/community/ARINcountries.html

That describes the geographical areas. It does not detail the actual
assignments. ARIN existed before all other registries, and handled the
initial registrations. See RFC2050. The registrations out of North America
that ARIN still maintains are those 'early registrations' that haven't been
transferred to other registries.

Not withstanding, the registrations TEND to reflect the location of the
company doing the registration, not the actual location of the hosts. I
work at a company which the registration data says in in New York state,
yet a traceroute will show a last hop before the black hole of our outer
perimeter as near San Francisco, California, and I'm over a thousand miles
from either. We also have subnets in facilities around the world - in fact,
the subnet below the one my workstation is on is in Asia, and the subnet
above it is in Europe.

>Except for 192, I have those blocks allowed.

[compton ~]$ grep -h ' 192\.' IP.ADDR/stats/[ALR]* | cut -d' ' -f1 | sort
-u | column
AT BR DE FI ID LK NI PH TW
AU CA DK FR IL MO NL PR US
BF CH DZ GA IN MX NZ SE UY
BM CL EC GH IT MY PE SG VE
BN CN EG GT JP MZ PF TH ZA
BO CR EU HK KR NE PG TN
[compton ~]$ grep -c ' 192\.' IP.ADDR/stats/[ALR]*
IP.ADDR/stats/AFRINIC:211
IP.ADDR/stats/APNIC:1374
IP.ADDR/stats/ARIN:9087
IP.ADDR/stats/LACNIC:100
IP.ADDR/stats/RIPE:2554
[compton ~]$ grep ' 192\.' IP.ADDR/stats/[ALR]* | grep -c US
8169
[compton ~]$

192.0.0.0/8 is allocated in tiny chunks all over the place. Some 12.6
million of the 16.8 million addresses there are used.

>'Tactical Nuclear' and 'Draconian' is how I describe spamming
>and SSH attacks. Why should I play nice when they don't...

Last I bothered to look, the major source of spam for me was cable and
DSL zombies in the US - that's controllable with blacklists. "Asia", from
the Russian Far East to the Golden Horn was second, and only because it
covers a huge amount of space. Europe was a distant third. As for SSH,
why are you permitting ANY connections to your SSH ports from addresses
other than your own?

Old guy

On Tue, 20 Dec 2005 13:57:25 -0600, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>That describes the geographical areas.

Here is the area served...
http://www.arin.net/community/ARINcountries.html

>It does not detail the actual assignments.

And here is the list of ARIN IP blocks...
http://www.arin.net/reference/ip_blocks.html#ipv4

And here is a list showing other domestic blocks...
http://www.iana.org/assignments/ipv4-address-space

It is pretty much that simple. Let's not have a cow over
someone allowing only domestic blocks. My server is not a
gateway, hub, or thoroughfare. And, even if everyone in my
position implements my solution, I very much doubt the
Internet will fall apart.

>As for SSH,
>why are you permitting ANY connections to your SSH ports
>from addresses other than your own?

I'm not allowing any connections to port 22 but my own. That's
the whole point of what I'm doing; talking about. Are you really
this thick?

I will fine-tune my solution to allow as many legitimate blocks
as possible while filtering out domestic spam, but I will not lose
sleep over it. Let's move away from trying to convince me I'm
wrong. The fact is, I don't give a rats-bottom about countries
like Mexico, Brazil, Peru, Netherlands, France, Germany, India,
Russia, Korea, Viet Nam, China, Taiwan, etc. Okay? Get the point?
I hope you can you deal with that because I'm done discussing
whether what I'm doing is right or wrong. Frankly, that is none
of your damn business.

Just so 'Moe Trin' will understand, I have ports 22 and 8443 limited
to accept connections from my personal WAN IP only. And, port 25
is limited to accept connections from ARIN and other domestic IP
blocks only. Except for the large number of Asia and South America
IP blocks in my deny file, everyone else can view web pages and
connect to receive mail. Good grief, Moe Trin makes me need to
take a Tylenol!

On Tue, 20 Dec 2005 15:28:26 -0500, Alan Jones <alan@alanjones.us>
wrote:

>>As for SSH,
>>why are you permitting ANY connections to your SSH ports
>>from addresses other than your own?
>
>I'm not allowing any connections to port 22 but my own. That's
>the whole point of what I'm doing; talking about. Are you really
>this thick?

Cameron L. Spitzer wrote:
> In article <1135022984.734741.90890@o13g2000cwo.googlegroups.c om>, prg wrote:
> >
> > If you are trying to cut down on spam, try SpamAssassin.
> > http://spamassassin.apache.org/
>
> Filtering is nice for cleaning up the stragglers that
> get past the source-IP block list checking.
> But there's no reason for most places to accept email
> from IP ranges owned by spam houses. I don't care
> if it's Python Video or Hanaro.net. If they sent it,
> I'm absolutely sure my users don't want it, and there's
> no reason to give it further CPU time.
> *Filtering* all that crap would cost a lot more.

You obviously did not note that I suggested the use of (dns)RBLs.

If only email (or a special use web server, eg.) is being firewalled
(ie., MTA sits on its own box and has its own IP), I have no problem
with the idea of blocking "overseas" IP blocks wholesale as part of a
larger, layered, deeper security system. In fact, with a drop policy
and a list/range of "good" (per your needs) IP blocks it can help to
filter on source IPs. Also, I don't mind dedicating boxes to single
purposes if possible.

Besides, SpamAssassin has a number of plugins that will handle dnsbls,
country codes (from each relay used in the delivery path -- not just
the IP source address), Razor, Spamcop. Ah, but Alan said it was "Not
reliable and a hassle". Now _his_ solution is ... hmmm.

> > The list you have might be somewhat useful (for something) if
> > _everyone_ conformed to its intent. The ones you are trying to keep
> > out are the ones who don't.
>
> The sbl-xbl.spamhaus.org list (for example) is more than
> "somewhat" useful. I don't care if "_everyone_ conformed"
> (whatever that means), just that it meets my organizations'
> needs.

See above.
Is it the "everyone" or "conformed" part you don't get. Perhaps the
dropped "intent"? Yep, it's pretty fuzzy and senseless taken out of
the context of the thread preceding it.

And what does the sbl-xbl.spamhaus.org list have to do with IANA's IP
block list of allocated IP space? I would _much_ rather make use of
the spamhause list.

> > Packets are routed by _destination_ and _not_by_source_ addresses.
> > Spam will 99.9999999999% of the time have a bogus IP return address
>
> I'm not sure what you're talking about there. The source IP
> is, as far as I know, the most difficult thing for the spammer
> to forge.

Patently false, since most ISPs do not perform effective egress
filtering nor do most private stub nets.

> (Well, he can forge it, but he's got to be able to
> collect your responses to the forged addreses, or he can't send
> spam that way.)

Now you know why spammers include a "return" link in the _body_ of the
email. There does not have to be _any_ connection between the IP
source address of the spam and the IP the link goes to.

> He's got to do some kind of asymmetric routing
> trick. Rumor has it Alan Ralsky was doing that for a while.
> His crap would seem to come from a throwaway dialup account,
> but there was way too much of it for that to be true.
> That trick became useless when lists of dynamically-assigned
> IP ranges became available in DNSBL form. It's no use
> pretending to be a dial-up if everybody's blocking those.

You might be surprised how often _source_routed_ packets (from any kind
of IP) are allowed into a network. Spammers work on _volume_, not
precise aiming. They use any and all tricks. Open relays, source
routed packets, zombies and drones, even _MS_Windows_:-0

> > Your "solution" has been proposed and tried by countless numbers of
> > those unknowledgeable in the ways of routing across the net.
>
> Blocking by source-IP is one of the most important techniques
> for keeping spam out.

Maybe yes, maybe no, depending on where you expect your email to
originate.

If you _can_ limit your expected origins and accept the side effects,
great. However, it's much easier to have a denial _policy_ at the
firewall and allow the _expected_ through. Then if/when you need to
allow someone in from, say overseas like UK, it's easier and less error
prone than explicitly denying certain blocks, then coding _exceptions_.

> I doubt there are many networks with more
> than a few thousand mailboxes that *don't* do it, at least a
> little, if only to reduce the load on their filtering machines.

The larger the network -- and presumably the more likely employees will
work/travel around the globe writing email back to the main office --
the _less_ likely (IMO) that IP _block_ filtering by _country_codes_ is
to be used. It's been my experience, anyway. BTW, it's a similar
reason the ISPs give for not more aggressively filtering on source IP
of incoming mail.

Smaller networks (with fewer email users) can likely be more easily
accommodated _and_ have IP _block_ addresses denied.

Anyway, without a clearer statement of what Alan J. wanted, I was being
purposefully dramatic to make sure he did not think that by this
(seemingly) simple technique he had cured his woes. With more info and
better understanding of _his_ needs (and willingness to accept the
effects) I have no particular reason to poo-poo his efforts (I'll
certainly not live with the consequences). Less knowledgeable folk who
find this in the archives will hopefully be better informed what issues
are envolved and what they can expect by adopting a similar approach
(or whether they should do so for _their_ needs).

But I will wager that neither Alan nor you will work your way through
(any?) of the links I provided, though you might find the exercise
informative if not necessarily immediately applicable. Not even this
eg.:
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/AE-cidr.txt
UAE
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/AF-cidr.txt
Afghanistan
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/IR-cidr.txt
Iran
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/CL-cidr.txt
Chile
[ Note the 24.152.0.0/17 block ;-( ]
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/CN-cidr.txt
China
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/CU-cidr.txt
Cuba
http://www.completewhois.com/statistics/data/ips-bycountry/rirstats/CX-cidr.txt
Christmas I.
[ Could not resist ]

cheers,
prg

Alan Jones wrote:
> On Tue, 20 Dec 2005 13:57:25 -0600, ibuprofin@painkiller.example.tld
[snip]
> Are you really this thick?
>
[snip]
> The fact is, I don't give a rats-bottom about countries
> like Mexico, Brazil, Peru, Netherlands, France, Germany, India,
> Russia, Korea, Viet Nam, China, Taiwan, etc. Okay? Get the point?
> I hope you can you deal with that because I'm done discussing
> whether what I'm doing is right or wrong. Frankly, that is none
> of your damn business.

[q]
You better watch out
You better not cry
You better not pout
I'm tellin' you why
Sants Claus is coming to town
[eq]

Happy Holidays, anyone?
prg

Sorry but the constant pessimism infuriates me. Merry Christmas
everyone.

On 20 Dec 2005 15:13:53 -0800, "prg" <rdgentry1@cablelynx.com>
wrote:

>You better watch out
>You better not cry
>You better not pout
>I'm tellin' you why
>Sants Claus is coming to town
>[eq]
>
>Happy Holidays, anyone?
>prg

Alan Jones wrote:
> Sorry but the constant pessimism infuriates me. Merry Christmas
> everyone.

Point taken and Merry Christmas to each and everyone.

really,
prg

> On 20 Dec 2005 15:13:53 -0800, "prg" <rdgentry1@cablelynx.com>
> wrote:
>
> >You better watch out
> >You better not cry
> >You better not pout
> >I'm tellin' you why
> >Sants Claus is coming to town
> >[eq]
> >
> >Happy Holidays, anyone?
> >prg

On Tue, 20 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
<25pgq15ff7p7sjd0fa1rfdgk38jvabg1im@4ax.com>, Alan Jones wrote:

>And here is the list of ARIN IP blocks...
>http://www.arin.net/reference/ip_blocks.html#ipv4

I prefer to use the actual data.

>> As for SSH, why are you permitting ANY connections to your SSH ports
>>from addresses other than your own?
>
>I'm not allowing any connections to port 22 but my own. That's
>the whole point of what I'm doing; talking about.

Quoting your earlier posting

>'Tactical Nuclear' and 'Draconian' is how I describe spamming
>and SSH attacks. Why should I play nice when they don't...

Your firewall is blocking them - they are not attacks. You are sounding
like some windoze wankers firewall that screams "ATTACK!!! ATTACK!!!"
every time a packet passes by.

>Are you really this thick?

And a merry Christmas to you too. But don't bother replying.

Old guy

On Tue, 20 Dec 2005 18:59:13 -0600, ibuprofin@painkiller.example.tld
(Moe Trin) wrote:

>On Tue, 20 Dec 2005, in the Usenet newsgroup comp.os.linux.security, in article
><25pgq15ff7p7sjd0fa1rfdgk38jvabg1im@4ax.com>, Alan Jones wrote:
>
>>And here is the list of ARIN IP blocks...
>>http://www.arin.net/reference/ip_blocks.html#ipv4
>
>I prefer to use the actual data.

All you need to know is which IP blocks belong where. You'll have
to look elsewhere if you don't know how to input that into your
iptables.

>>> As for SSH, why are you permitting ANY connections to your SSH ports
>>>from addresses other than your own?
>>
>>I'm not allowing any connections to port 22 but my own. That's
>>the whole point of what I'm doing; talking about.
>
>Quoting your earlier posting
>
>>'Tactical Nuclear' and 'Draconian' is how I describe spamming
>>and SSH attacks. Why should I play nice when they don't...
>
>Your firewall is blocking them - they are not attacks.

I didn't say the attacks were still happening, now did I? The
fact is, if I open port 22 back up, the attacks remain and will
immediately resume. I'm really sorry to say it at this time of
year but your arguments are moronic! Lay off the Motrin.

>You are sounding
>like some windoze wankers firewall that screams "ATTACK!!! ATTACK!!!"
>every time a packet passes by.
>
>>Are you really this thick?
>
>And a merry Christmas to you too. But don't bother replying.
>
> Old guy

(rolls eyes)

On Thu, 19 Jan 2006 00:26:47 -0600, spm wrote:

> I have been trying to capture the flag on this IANA reserved IP issue.

[...]

You are invited to mail directly any questions, and I will assist in
discretely resolving the issues to your satisfaction. I would really like
to know the nature of this issue. Thank you.

You may contact me at this address:

colloquy_no_9 [ at ] mailingaddress.org

(Please remove the " [ at ] " and replace it with "@".)

Thank you.

Now I Am Positive

Warning: long-winded whining to follow ...

When I wrote last asking for advice re: bogus IP logons, I reported that
the IPs in question had come back as IANA Reserved. Later, they were
reported to belong to akamai. In another log, they were reported to
belong to a.r.tv.com. I went to the website of my firewall/anti-virus
software vendor and asked why _all_ traffic in and out of my machine was
being routed through these certain IPs. I received an e-mail back from
the vendor, as I posted (with the name and other identifiers of the
software package redacted) to this newsgroup.

I have now switched to Linux completely. The software for my Windows XP
firewall, ZoneAlarm, has nothing to do with this installation of Linux.
There is absolutely no reason for those IPs, which they assured me were
their servers and legitimate IPs, to have anything to do with this Linux
installation. It is now apparent that the e-mail did not come from a
legitimate source, for, surely, ZoneAlarm would not take over a
Linux-based machine that did not have their software installed. Surely.

The IPs are:

84.53.144.7
84.53.144.9
84.53.144.15
84.53.144.16
84.53.144.17
84.53.144.22

length=44; TOS=0x00; port=80; prot=TCP; serv=HTTP

active connections:

localhost.localdomain port 32769 service=unknown
localhost.localdomain port 631 lpp


As before, my scanner is disabled. As before, there are problems with my
printers now, which were printing merrily away until this morning. Now,
both of them will only print Postscript Level 2 files. Neither printer
is a Postscript printer. The legitimate options are gone. As before,
every time I work on a file, then save or try to print, there is network
activity. Right before I switched over to Linux, I found several *.dmp
files that were being transmitted over the internet that contained
everything I was doing at the time. (So I sent them some red herrings
right back at them ... I will see if the bogus info crops up somewhere.)

I also found log entries in XP that alerted on memory handle leaks,
anywhere from 2 to 58 at a time. When the leaks were high, non-apartment
impersonation code logging in as Local Service from the internet would
try desperately to unload hive5 and clear user profile, successfully
preventing usrenv from reporting about half the time.

I signed up at the SciFi Channel this morning and never got the
confirmation e-mail. Instead, I got spam from hotmail. In Firefox, I had
HTML disabled, message preview disabled, and the character set was
UTF-8. That was changed today to the same thing that happened over under
WinXP ... the character set was set to Western European 8559-1. I
removed it, put it back to UTF-8, closed it, opened it back up, and
there was Western European again. Six times. US-ASCII has been removed
from the list of choices I can designate, although it is still listed in
the main View Menu (from yesterday). I am betting that when I close and
do a restart, it will be gone, just like before under WinXP.


Unfortunately, I don't know _near_ enough about Linux to track down
whatever changes were made yesterday or this morning. I can not trust
any whois or DNS name server that I might try to go to because at this
point, I have no idea where I would be actually going. I don't even know
how to kill/terminate this active connection on port 32769 with service
unknown. How does one do that under Linux?

Just wanted to report back with the IPs, now that I am sure they are not
legitimate ZoneAlarm servers as I was told in that e-mail sent to me in
response to my query at what I thought was the ZoneAlarm website. (It
may have been but the real response may have been intercepted and
edited.)

One might legitimately ask why this is happening to a nobody down in
Podunk. I can think of four reasons: 1) my machine is being zombified;
2) somebody thinks my machine has been zombified by someone overseas and
is checking it out (I don't have a problem with this one ... hope they
get them); 3) there is a promiscuous port sniffer in my neighborhood
with _nothing_ better to do; 4) something else that is going on in my
life that involves a potential lawsuit.

The bright side? This is a brand new install and I don't have very much
to lose at all (g). Easy to wipe and start over.

If anyone knows of a legitimate reason for the above IPs to be acting as
proxy for all traffic coming in and out of first a WinXP machine and now
a Linux machine, please educate me. I have worked hard studying texts
such as Windows Security, Windows XP Command Line, numerous trips to the
Knowledgebase, on and on, trying to figure this one out myself. I
surrender ... white flag is waving ...

spm under WinXP ... blueskye under Linux ...

On Wed, 25 Jan 2006 20:20:20 -0600, blueskye
<replygroup@example.net> wrote:
>
> Unfortunately, I don't know _near_ enough about Linux to track down
> whatever changes were made yesterday or this morning. I can not trust
> any whois or DNS name server that I might try to go to because at this
> point, I have no idea where I would be actually going. I don't even know
> how to kill/terminate this active connection on port 32769 with service
> unknown. How does one do that under Linux?
>
netstat -tnp, look for the line that refers to port 32769. The last
field on that line should give the PID which you can kill.


--
I know not how I came into this, shall I call it a dying life or a
living death?
-- St. Augustine

blueskye wrote:

> One might legitimately ask why this is happening to a nobody down in
> Podunk. I can think of four reasons: 1) my machine is being zombified;
> 2) somebody thinks my machine has been zombified by someone overseas and
> is checking it out (I don't have a problem with this one ... hope they
> get them); 3) there is a promiscuous port sniffer in my neighborhood
> with _nothing_ better to do; 4) something else that is going on in my
> life that involves a potential lawsuit.

> The bright side? This is a brand new install and I don't have very much
> to lose at all (g). Easy to wipe and start over.

3) is more likely on cable connections than any other kind of connection.
From your description it's hard to tell what might have already happened
to your system. Do the reinstall. Install and initialize tripwire. Disable
any external services. Connect via dial-up to a free, out-of-town ISP, and
see if your same problems don't go away. 1), 2) & 4) are probably
controllable from your end but 3) is not. Your cable ISP will need
to do that. Read up on "man in the middle".

On Thu, 26 Jan 2006 02:48:12 -0500, slvm wrote:
> blueskye wrote:

>> get them); 3) there is a promiscuous port sniffer in my neighborhood

> 3) is more likely on cable connections than any other kind of connection.

What about WiFi though.

> From your description it's hard to tell what might have already happened
> to your system. Do the reinstall. Install and initialize tripwire.
> Disable any external services. Connect via dial-up to a free,
> out-of-town ISP, and see if your same problems don't go away. 1), 2) &
> 4) are probably controllable from your end but 3) is not. Your cable
> ISP will need to do that.

Probably they can only do unreliable traffic like ICMP, UDP or port-scans
this way though.

> Read up on "man in the middle".

Well if ARP spoofing is used to do MITM, given one knows thier ISP' IP/MAC
adresses (for the GW and DHCP plus maybe DNS), maybe staticly-arp then:

echo "192.168.0.1 router.isp.tld router" >>/etc/hosts
echo "00:DE:AD:BE:EF:00 192.168.0.1" >>/etc/ethers

arp -f
ifconfig eth0 -arp

--
-Menno.

On Wed, 25 Jan 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1138241168.3455.2.camel@localhost.localdomain>, blueskye wrote:

>When I wrote last asking for advice re: bogus IP logons, I reported that
>the IPs in question had come back as IANA Reserved. Later, they were
>reported to belong to akamai. In another log, they were reported to
>belong to a.r.tv.com.

You're showing IPs in the 84.53.144.x range. 84.0.0.0/8 was assigned to
RIPE (the European Internet Registrar) in November 2003. Any tool you are
using that says that this IP range is reserved is severely out of date.
RIPE allocated 84.53.128.0 - 84.53.191.255 to Akamai Technologies on 5
November 2004. Akamai seems to have divided that range into six
sub-assignments, and 84.53.128.0 - 84.53.147.255 is the one you are
concerned with actually seem to be located near Washington DC in the US.

tv.com is registered to CNET in San Francisco. a.r.tv.com is a hostname
within that domain, but resolves as a CNAME to something at akamai. That
something would depend on where you are in the world, and perhaps the
time of day and traffic loads. At the moment, I see

[compton ~]$ host a.r.tv.com
a.r.tv.com is a nickname for a868.g.akamai.net
a868.g.akamai.net has address 80.67.74.10
a868.g.akamai.net has address 80.67.74.18
[compton ~]$

which seems to be an akamai server farm in San Jose, California.

You might want to do a web search who 'akamai.net' is, and how they
make their money. Briefly, they are a content provider - used by a large
number of companies to deliver stuff (everything from web pages to
software updates to streaming video) from servers they have scattered
in facilities around the world. Anecdotally, one of their customers was
microsoft - there was much hilarity some time ago when it was discovered
that microsoft was using *nix servers to deliver one of the important
security updates for windoze, and it turned out these were akamai servers.

Before that, there was a big cry raised on some user-level security news
groups because when connecting to an akamai hosted site, there would be
"attacks" to "ICMP Port 8" (a simple ping) from sites scattered all over.
The explanation was akamail trying to map the nearest/fastest server to
an individual client address. Haven't seen much of that lately, presumably
because akamai now has a reasonable map of the Internet and can tell which
server to respond with based on the client IP address.

>I have now switched to Linux completely. The software for my Windows XP
>firewall, ZoneAlarm, has nothing to do with this installation of Linux.
>There is absolutely no reason for those IPs, which they assured me were
>their servers and legitimate IPs, to have anything to do with this Linux
>installation.

Do you have no windoze boxes anywhere that might be using your Linux
box as a router?

>It is now apparent that the e-mail did not come from a legitimate source,
>for, surely, ZoneAlarm would not take over a Linux-based machine that did
>not have their software installed. Surely.

Case not proven either way.

>active connections:
>
>localhost.localdomain port 32769 service=unknown
>localhost.localdomain port 631 lpp

Your redacting prevents any comment. If those are what you see with
netstat, try using 'netstat -tupan' and identify the process involved.

>Unfortunately, I don't know _near_ enough about Linux to track down
>whatever changes were made yesterday or this morning.

man find

find / -mtime -2 -type f -exec ls -l {} \; > /tmp/files.that.changed

but be aware that is going to take some time, and may well turn up a bunch
of meaningless noise.

>I can not trust any whois or DNS name server that I might try to go to
>because at this point, I have no idea where I would be actually going.

tcpdump -n should provide clues.

>I don't even know how to kill/terminate this active connection on port
>32769 with service unknown. How does one do that under Linux?

[compton ~]$ whatis kill fuser lsof netstat
kill (1) - terminate a process
kill (2) - send signal to a process
fuser (1) - identify processes using files or sockets
lsof (8) - list open files
netstat (8) - Display network connections, routing tables,
interface statistics, masquerade connections and netlink messages
[compton ~]$

>Just wanted to report back with the IPs, now that I am sure they are not
>legitimate ZoneAlarm servers as I was told in that e-mail sent to me in
>response to my query at what I thought was the ZoneAlarm website. (It
>may have been but the real response may have been intercepted and
>edited.)

You seem to have a WAY OVER active imagination.

>One might legitimately ask why this is happening to a nobody down in
>Podunk. I can think of four reasons:

"I got my paranoia the old fashioned way: I earned it."

Old guy

On Mon, 23 Jan 2006 02:57:28 -0500, Newsbox wrote:

> On Thu, 19 Jan 2006 00:26:47 -0600, spm wrote:
>
>> I have been trying to capture the flag on this IANA reserved IP issue.
>
> [...]
>
> You are invited to mail directly any questions, and I will assist in
> discretely resolving the issues to your satisfaction. I would really like
> to know the nature of this issue. Thank you.
>
> You may contact me at this address:
>
> colloquy_no_9 [ at ] mailingaddress.org
>
> (Please remove the " [ at ] " and replace it with "@".)
>
> Thank you.
Well, I got your mail, and you can mail me again with a valid return
address for a private response if you like. I don't care for the
hostility here.

Menno Duursma wrote:

> On Thu, 26 Jan 2006 02:48:12 -0500, slvm wrote:
>> blueskye wrote:
>
>>> get them); 3) there is a promiscuous port sniffer in my neighborhood
>
>> 3) is more likely on cable connections than any other kind of connection.
>
> What about WiFi though.

Yes of course you are correct that WiFi would be at least as vulnerable.
I guess I wasn't thinking of WiFi as a (primary?) connection method,
though some might. Good point.

>> From your description it's hard to tell what might have already happened
>> to your system. Do the reinstall. Install and initialize tripwire.
>> Disable any external services. Connect via dial-up to a free,
>> out-of-town ISP, and see if your same problems don't go away. 1), 2) &
>> 4) are probably controllable from your end but 3) is not. Your cable
>> ISP will need to do that.
>
> Probably they can only do unreliable traffic like ICMP, UDP or port-scans
> this way though.
>
>> Read up on "man in the middle".
>
> Well if ARP spoofing is used to do MITM, given one knows thier ISP' IP/MAC
> adresses (for the GW and DHCP plus maybe DNS), maybe staticly-arp then:
>
> echo "192.168.0.1 router.isp.tld router" >>/etc/hosts
> echo "00:DE:AD:BE:EF:00 192.168.0.1" >>/etc/ethers
>
> arp -f
> ifconfig eth0 -arp

Yes again. Although, I do think MITM on a community cable should really be
handled with the cooperation and support of the ISP. Your suggestion is
surely the direct and effective response. ("given one knows thier ISP'
IP/MAC adresses".) Good message and points. :)

Moe Trin wrote:

[...]

>>Just wanted to report back with the IPs, now that I am sure they are not
>>legitimate ZoneAlarm servers as I was told in that e-mail sent to me in
>>response to my query at what I thought was the ZoneAlarm website. (It
>>may have been but the real response may have been intercepted and
>>edited.)
>
> You seem to have a WAY OVER active imagination.

If the man (woman, child or alien [other?]) got a patently forged e-mail,
would not he (or she, it or other) have reason for suspicion?

>>One might legitimately ask why this is happening to a nobody down in
>>Podunk. I can think of four reasons:
>
> "I got my paranoia the old fashioned way: I earned it."

And your stupidity? How did you get that? :)

> Old guy