While you have your friend's ear, ask him why they maintain a spam policy of
blocking complete /24's when:
a) the space has been divided into multiple sub-blocks and assigned to
different companies, all well-documented and queryable in ARIN
b) there have been repeated pleas to whitelist a certain IP in separate
sub-block that is only being punished for the behavior of others in a
different sub-block.
Frank
<realitycheck>
You're complaining of blocked /24's. I block off up to /6's from reaching
certain ports on my networks. Sound crazy? How many times should I contact
the netblock owner and here the same generic "well you have to open up a
complaint with our abuse desk... golly gee Joseph." Only to have the same
repeat attacks over and over and over. Sure, I'll start out blocking the
offensive address, then shoot off an email here and there, even post to
this or another list or search Jared's list for a contact and ask them
politely "Hey... I see X amount of attackers hitting me from your net"
But how long should I go on for before I could just say "to hell with
your users and network... They just won't connect." It's my own right to
when it comes to my network.
People complain? Sure, then I explain why, point out the fact that I
HAVE made attempts at resolutions to no avail. So should the entire
network be punished... No, but the engineers who now have to answer
THEIR clients on why they've been blacklisted surely are punished aren't
they. Now they have to hear X amount of clients moan about not being
able to send either a client, vendor or relative email. They have to
either find an alternative method to connect, or complain to their
provider about connectivity issues.
Is it fair? Yes it's fair to me, my clients, networks, etc., that
I protect it. Is it fair to complain to deaf ears when those deaf
ears are the ones actually clueful enough to fix? On a daily basis
I have clients who should be calling customer service for issues
contact me directly. Know what I do? ... My best to fix it, enter
a ticket number on the issue and go about the day. One way or the
other I'm going to see the ticket/problem so will it kill me to
take a moment or two to fix something? Sure I will bitch moan and
yell about it, a minute later AFTER THE FIX since things of this
nature usually don't take that much time, guess what? Life returns
to normal.
http://www.infiltrated.net/bforcers/5thWeek-Organizations
Have a look will you? These are constant offending networks with
hosts that are repeatedly ssh'ing into servers I maintain. Is it
unfair to block off their entire netblock from connecting via
ssh to my servers. Hell no it isn't. If I have clients on this
netblock, in all honesty tough. Let them contact their providers
after I tell them their provider has been blocked because of the
garbage on their network. Let their provider do something before
I do because heaven knows how many times have I tried reaching
someone diplomatically before I went ahead and blocked their
entire /6 /7 /8 /9 /10 and so on from connecting to me via ssh
or whatever other service they've intruded or attempted to
intrude upon.
Blocks? They usually last for 2 weeks then I take them off and
start ALL over again. Of course I've automated this so its no
sweat off shoulders. So you tell me in all honesty why someone
should not escalate and block off entire blocks.
</realitycheck>
Joe:
I understand your frustration and appreciate your efforts to contact the
sources of abuse, but why indiscriminately block a larger range of IPs than
what is necessary?
Here's the /24 in question:
Combined Systems Technologies NET-CST (NET-207-177-31-0-1)
207.177.31.0 - 207.177.31.7
Elkader Public Library NET-ELKRLIB (NET-207-177-31-8-1)
207.177.31.8 - 207.177.31.15
Plastech Grinnell Plant NET-PLASTECH (NET-207-177-31-16-1)
207.177.31.16 - 207.177.31.31 (dial-up, according to DNS)
Griswold Telephone Co. NET-GRIS (NET-207-177-31-32-1)
207.177.31.32 - 207.177.31.63
Griswold Telephone Co. NET-GRIS2 (NET-207-177-31-64-1)
207.177.31.64 - 207.177.31.95 (dial-up, according to DNS)
Jesco Electrical Supplies NET-JESCOELEC (NET-207-177-31-96-1)
207.177.31.96 - 207.177.31.103
American Equity Investment NET-AMREQUITY (NET-207-177-31-104-1)
207.177.31.104 - 207.177.31.111
** open **
Butler County REC NET-BUTLERREC (NET-207-177-31-120-1)
207.177.31.120 - 207.177.31.127
Northeast Missouri Rural Telephone Co. NET-NEMR2
(NET-207-177-31-128-1)
207.177.31.128 - 207.177.31.191
Montezuma Mutual Telephone NET-MONTEZUMA (NET-207-177-31-192-1)
207.177.31.192 - 207.177.31.254 (dial-up, according to DNS)
Block the /24 and you cause problems for potentially 8 other companies. Now
the RBL maintainer, or in this case, GoDaddy, has to interact with 8 other
companies -- what a lot of work and overhead! If they just dealt with the
problem in a more surgical manger they wouldn't have to deal with the other
companies asking for relief.
Frank
Far too many times I've tried to contact those who have the DIRECT ability
to make things happen and the same constant whiny "Contact our abuse desk"
reponse was given. What mainly happens here on out is the following, if
someone on that subnet needs to do something on mine, many will contact me
or others that work with me and state "Why can't we connect?!" The situation
will be explained and they'll be told to contact their provider. This seems
to be the only logical method I've personally found for some of the bigger
provider to respond to incidents. Hit them where it hurts, let them have
their own customers bitch and moan about their inability to get things
done. Sure its not fair to single out an entire subnet. I've gone as far
as blocking LACNIC, APNIC, RIPE, /8's on ARIN at a clip for days on end
until someone from the offending provider contacted me. Then and only
then was I able to get something done.
So to answer your question about fairness... It's not fair by any
means, but it is effective. I see it as follows... If someone on one
of my networks is offending someone else, I'm nipping it in the bud
to avoid the possibility of any legal repercussions. And although it
may seem far fetched to look at things in such fashion, I'd rather
be safe than sorry. I'd also like to be accountable since after all
when it boils down to it, it is my job as a network engineer, security
engineer to ensure nothing malicious comes into my network as well
as exits my network. Its a two way street.
1. There's nothing "indiscriminate" about it.
I often block /24's and larger because I'm holding the *network* operators
responsible for what comes out of their operation. If they can't hold
the outbound abuse down to a minimum, then I guess I'll have to make
up for their negligence on my end. I don't care why it happens -- they
should have thought through all this BEFORE plugging themselves in
and planned accordingly. ("Never build something you can't control.")
Neither I nor J. Oquendo nor anyone else are required to spend our time,
our money, and our resources figuring out which parts of X's network
can be trusted and which can't. It is entirely X's responsibility to
make sure that its _entire_ network can be permitted the privilege of
access to ours. And (while I don't wish to speak for anyone else),
I think we're prepared to live with a certain amount of low-level,
transient, isolated noise. We are not prepared to live with persistent,
systemic attacks that are not dealt with even *after* complaints are
filed. (Which shouldn't be necessary anyway: if we can see inbound
hostile traffic to our networks, surely X can see it outbound from
theirs. Unless X is too stupid, cheap or lazy to look. Packets do
not just fall out of the sky, y'know?)
2. "necessary" is a relative term.
Example: I observed spam/spam attempts from 3,599 hosts on pldt's network
during January alone. I've blocked everything they have, because I find it
*necessary* to not wait for the other N hosts on their network to pull the
same stunt. I've found it *necessary* to take many other similar measures
as well because my time, money and resources are limited quantities,
so I must expend them frugally while still protecting the operation from
overty hostile networks. That requires pro-active measures and it
requires ones that have been proven to be effective.
If X, for some value of X, is unhappy about this, then X should have
thought of that before permitting large amounts of abuse to escape
its operation over an extended period of time. Had X done its job
to a baseline level of professionalism, then this issue would not
have arisen, and we'd all be better off for it.
So. If you (generic you) can't keep your network from being a persistent
and systemic abuse source, then unplug it. Now.
If on other hand, you decide to stick around anyway while letting the
crap flow: no whining when other people find it necessary to take steps
to defend themselves from your incompetence.
---Rsk
because it's go-daddy's policy not yours and their customers aren't upset
enough about 'broken' email to force a change?
If you are a go-daddy customer you ought to speak up if this policy really
does affect you.
-Chris
J. Oquendo wrote:
...
So to answer your question about fairness... It's not fair by any
means, but it is effective. I see it as follows...
Well, that's the reason why I have a gmail account and all my
customers have.
I can send even from my dynamic ip-address and still they
let me in.
They can send to my dynamic ip-address.
Important mails are sent host to host.
For the records are sent via gmail.
There is no need for any other mail provider. They are
blocking mails most of the time only allowing spam to
get through.
Cheers
Peter and Karin
> I understand your frustration and appreciate your efforts to contact the
> sources of abuse, but why indiscriminately block a larger range of IPs
than
> what is necessary?
1. There's nothing "indiscriminate" about it.
I often block /24's and larger because I'm holding the
*network* operators responsible for what comes out of
their operation.
Define network operator: the AS holder for that space or the operator of
that smaller-than-slash-24 sub-block? If the problem consistently comes
from /29 why not just leave the block in and be done with it?
I guess this begs the question: Is it best to block with a /32, /24, or some
other range? Sounds a lot like throwing something against the wall and
seeing what sticks. Or vigilantism.
If they can't hold the outbound abuse down to a minimum, then
I guess I'll have to make up for their negligence on my end.
Sure, block that /29, but why block the /24, /20, or even /8? Perhaps your
(understandable) frustration is preventing you from agreeing with me on this
specific case. Because what you usually see is an IP from a /20 or larger
and the network operators aren't dealing with it. In the example I gave
it's really the smaller /29 that's the culprit, it sounds like you want to
punish a larger group, perhaps as large as an AS, for the fault of smaller
network.
I don't care why it happens -- they should have thought through
all this BEFORE plugging themselves in and planned accordingly.
("Never build something you can't control.")
Agreed.
Neither I nor J. Oquendo nor anyone else are required to
spend our time, our money, and our resources figuring out which
parts of X's network can be trusted and which can't.
It's not that hard, the ARIN records are easy to look up. Figuring out that
network operator has a /8 that you want to block based on 3 or 4 IPs in
their range requires just as much work.
It is entirely X's responsibility to make sure that its _entire_
network can be permitted the privilege of access to ours.
And (while I don't wish to speak for anyone else),
I think we're prepared to live with a certain amount of low-level,
transient, isolated noise.
Noise like that is inevitable part of the job.
We are not prepared to live with persistent, systemic attacks
that are not dealt with even *after* complaints are
filed. (Which shouldn't be necessary anyway: if we can see inbound
hostile traffic to our networks, surely X can see it outbound from
theirs. Unless X is too stupid, cheap or lazy to look. Packets do
not just fall out of the sky, y'know?)
Smaller operators, like those that require just a /29, often don't have that
infrastructure. Those costs, as I'm sure you aware, are passed on to
companies like yourself that have to maintain their own network's security.
Again, block them, I say, just don't swallow others up in the process.
2. "necessary" is a relative term.
Example: I observed spam/spam attempts from 3,599 hosts on
pldt's network during January alone. I've blocked
everything they have, because I find it *necessary*
to not wait for the other N hosts on their network
to pull the same stunt. I've found it *necessary* to take
many other similar measures as well because my time,
money and resources are limited quantities, so I must
expend them frugally while still protecting the operation
from overtly hostile networks.
That's my point: you want to spend time dealing with the other 8 networks
because you blacked them, out, too?
That requires pro-active measures and it requires ones
that have been proven to be effective.If X, for some value of X, is unhappy about this, then X should have
thought of that before permitting large amounts of abuse to escape
its operation over an extended period of time. Had X done its job
to a baseline level of professionalism, then this issue would not
have arisen, and we'd all be better off for it.
Agreed, but economics usually dictate otherwise.
So. If you (generic you) can't keep your network from being
a persistent and systemic abuse source, then unplug it. Now.
They want to run a business, too. So when you blacklist they will end up
calling you asking for mercy, telling you that it's been cleaned up.
Inevitably something/someone gets infected, you black them out, rinse,
repeat.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sure, block that /29, but why block the /24, /20, or even /8? Perhaps your
(understandable) frustration is preventing you from agreeing with me on this
specific case. Because what you usually see is an IP from a /20 or larger
and the network operators aren't dealing with it. In the example I gave
it's really the smaller /29 that's the culprit, it sounds like you want to
punish a larger group, perhaps as large as an AS, for the fault of smaller
network.
Well it sounds like the original poster is trying to punish the "network operator" by intentionally blocking innocent bystanders and therefore causing them grief so if that is your goal then a /24 seems like a decent arbitrary size. You are mostly sure you won't block across providers that way at least.
However, even if this isn't your goal it can be really hard sometimes to have any clue how big a netblock is for a particular IP address. ARIN may make small folks like us jump through hoops but apparently this isn't true for larger providers. We often run into abuse from IP addresses (or a range of addresses) where there is no rwhois sever and the entire /19 or larger is SWIPed as a single netblock. I've seen some really, really large blocks with absolutely no sub-delegation when clearly the addresses are sub-delegated.
We will often temporary block a /24 on email blacklists for instance. When you're getting pounded from a range of 30 or 50 IP addresses and can't get any response from the upstream then it is farily obvious they are less than white hat so we're willing to live with the collateral damage.
Chris
Frank Bulk wrote:
> [[Attribution deleted by Frank Bulk]]
Neither I nor J. Oquendo nor anyone else are required to spend our time, our money, and our resources figuring out which parts of X's network can be trusted and which can't.
It's not that hard, the ARIN records are easy to look up. Figuring out that
network operator has a /8 that you want to block based on 3 or 4 IPs in
their range requires just as much work.
It's *very* hard to do it with an automated system, as such automated look-ups are against the Terms of Service for every single RIR out there.
Please play the bonus round: try again.
Stephen:
Are you saying that if there's nefarious IP out there let's automatically
blacklist the /24 of that IP? J. Oquendo was describing his own methods and
they sounded quite manual, manual enough that he's getting down to a /8 as
necessary to blacklist a non-responsive operator. My point is that if
you're going to block something, either block the /32 or do the research to
justify blocking a larger group.
And despite ToS, I think many operators are running automated lookups, and
there are lots of examples out there for ARIN.
Frank
>> Neither I nor J. Oquendo nor anyone else are required to spend our
>> time, our money, and our resources figuring out which parts of X's
>> network can be trusted and which can't.
you should only spend resources on activities which will benefit you, of
course. research into a /N to find out which /(M>N)'s are good and which
are evil can pay back in a lower false-positive rate, which will matter to
some blockers more than others.
> It's not that hard, the ARIN records are easy to look up. Figuring out
> that network operator has a /8 that you want to block based on 3 or 4
> IPs in their range requires just as much work.
as several others have pointed out, detailed records are often unavailable
and are sometimes wrong. my theory is that folks don't want to put abuse
contact info into WHOIS that will just cause them to be reportbombed with
low quality automated trash having no particular format, lacking useful
detail, and often complaining to the wrong place. (for example, as one of
the WHOIS contacts for AS112, i am reportbombed frequently by folks whose
reportbot's best guess at who-spammed-them is an RFC 1918 address.)
It's *very* hard to do it with an automated system, as such automated
look-ups are against the Terms of Service for every single RIR out there.
perhaps appropos of this, http://www.arin.net/announcements/article_352.html
says that there's a movement afoot to remove one of the WHOIS query limits
at ARIN. if someone here thinks that a TOS change that permitted automated
lookups for the purpose of abuse reporting would be good, then in the ARIN
region, http://www.arin.net/policy/irpep.html says how you can suggest such.
Define network operator: the AS holder for that space or the operator of
that smaller-than-slash-24 sub-block? If the problem consistently comes
from /29 why not just leave the block in and be done with it?
Because experience...long, bitter experience...strongly indicates that
what happens today often merely presages what will happen tomorrow.
Because I haven't got unlimited time. Or money. Or resources.
Because I haven't got unlimited WHOIS queries. (Although I and everyone
else *should* have those. There are no valid reasons to rate-limit any
form of WHOIS query.)
Because there are way, WAY too many incompetently-managed networks whose
operators can often be heard complaining about the abuse inbound to them
at the same time they fail to take rudimentary measures to control the
abuse outbound from them. <cough> port 25 blocking <cough>
Because I was more patient for the first decade or two, and it proved
to be a losing strategy.
Because This Is Not My Problem. If by chance someone benign has chosen
to locate their operation in known-hostile, known-negligently-operated
network space, then their failure to perform due diligence may have
consequences for them.
I guess this begs the question: Is it best to block with a /32, /24, or some
other range? Sounds a lot like throwing something against the wall and
seeing what sticks. Or vigilantism.
1. Gratuitously labeling carefully-considered measures as random is not a
route to productive conversation.
2. It is hardly "vigilantism" to take passive measures to protect one's
network/systems/users from hostile activity. Doubly so when those measures
consist merely of a refusal to grant a *privilege* after it's been repeatedly,
systemically abused.
---Rsk
Because I haven't got unlimited WHOIS queries. (Although I
and everyone
else *should* have those. There are no valid reasons to
rate-limit any
form of WHOIS query.)
Yes there are. The current whois returns way more information on a query
than you need for network operations. That's because the current whois
was designed back in the 1970's so that ARPANET network managers could
identify all the users of the network in order to help them make the
business case for their budget requests to cover the cost of high-speed
56k frame relay links.
There is no good reason to rate-limit a query that takes an IP address
(or IP address range or CIDR block) and returns with a list of database
record identifiers for the enclosing blocks. The record identifiers for
organizations who directly received an allocation or assignment from
ARIN would be their org-id. The other ones, SWIP records, would have
some fixed database key like REASG20060000000022812536. If no
REASsiGnment record exists, you now have the orgid to contact and have
no need to do an additional query if they are a known organization. If
the REASiGnment records do exist, you can look them up in your own
database to see if they are a re-offender. And if you really need to,
then you can do a RATE-LIMITED lookup of contact info.
One type of query is justifiably rate limited to prevent DB scraping by
spammers et al. The other type is not, however it does not currently
exist because the RIR whois directory was not created for network
operations support nor is it designed to do this job. You can hack
together all kinds of mashups that sort of work if you squint the right
way, but the bottom-line is that whois does not do the job that many
network operators think it does or would like it to do.
Because This Is Not My Problem. If by chance someone benign
has chosen
to locate their operation in known-hostile, known-negligently-operated
network space, then their failure to perform due diligence may have
consequences for them.
It would be interesting if you, and other like-minded hard-nosed network
admins would get together and write a requirements document for a whois
type directory lookup that would actually support you in what you are
trying to do while minimizing collateral damage. The only caveat is that
it must be legal to implement in the USA, i.e. you will never get GPS
coordinates and a photo of the registrant in such a system.
In my opinion, the purpose and scope of such a directory is to provide
contact info for people who are ready, willing and able to communicate
regarding network operations and interconnect issues and who are able to
act on that communication. All contact info should be verified with the
contactee who must EXPLICITLY agree to have the info published. All
contact info will be verified periodically (maybe every 4 months?) by
out-of band means, i.e. the directory operator will keep track of
individual email addresses and phone numbers for role account managers.
If such a directory did exist, then it would be smaller than whois. You
would get many more failures on a quick query which is a good thing. It
means that the network operator did not make it a contractual
requirement for their customer to maintain an up-to-date network
contact. In that case, the network operator is not just morally
responsible for abuse, they are contractually responsible.
Or maybe you could come up with something better?
1. Gratuitously labeling carefully-considered measures as
random is not a
route to productive conversation.
Agreed. I think a lot of the problem stems from assumptions. People make
a lot of assumptions on what whois does based on the net folklore that
was handed down to them when they "joined" the Internet. Few people seem
to question such folklore and few people notice that not everybody
shares the same understanding. However, it is a lot easier for people to
notice that your carefully-considered measures look like a lot like a
crude weapon that causes lots of collateral damage. They feel that you
could do better and attack you rather than attacking their own
assumptions which are the real root of the problem. If you had better
data to work with, then your carefully-considered measures would evolve
to appear highly sophisticated wisdom, and would also cause little
collateral damage.
--Michael Dillon
...
Yes there are. The current whois returns way more information on a query
than you need for network operations. That's because the current whois
was designed back in the 1970's so that ARPANET network managers could
identify all the users of the network in order to help them make the
business case for their budget requests to cover the cost of high-speed
56k frame relay links.
Mike, that's twice in two days that you've made that assertion. I don't
remember any financial administrator in those days that would have
accepted WHOIS output as justification for anything. I do remember,
however, that those "high-speed" 9600 baud and 56Kb links were point-to-
point and went down a lot. And so what I remember the WHOIS entries
being used for was:
...
In my opinion, the purpose and scope of such a directory is to provide
contact info for people who are ready, willing and able to communicate
regarding network operations and interconnect issues and who are able to
act on that communication. All contact info should be verified with the
contactee who must EXPLICITLY agree to have the info published. All
contact info will be verified periodically (maybe every 4 months?) by
out-of band means, i.e. the directory operator will keep track of
individual email addresses and phone numbers for role account managers.
...
so that we could contact the person at the other end who was responsible
for and knowledgable of their side of the network connection, to fix it.
At o-dark-thirty, if necessary.
Unfortunately, the way WHOIS is maintained these days, this can no
longer be trusted.
Note: at the time, I was a bit younger and did not often encounter
financial managers, so it's possible some might have accepted WHOIS
output. But most people thought computers were some weird thing out
THERE [point in random direction], and would sooner have accepted a
hand-written note than one printed on a TTY33 or chain printer.