We just got Cyclops alerts showing several of our prefixes sourced from
AS23474 propagating through AS4134. Anyone else?
aut-num: AS23724
as-name: CHINANET-IDC-BJ-AP
descr: IDC, China Telecommunications Corporation
country: CN
aut-num: AS4134
as-name: CHINANET-BACKBONE
descr: No.31,Jin-rong Street
descr: Beijing
descr: 100032
country: CN
Hi!
We just got Cyclops alerts showing several of our prefixes sourced from
AS23474 propagating through AS4134. Anyone else?aut-num: AS23724
as-name: CHINANET-IDC-BJ-AP
descr: IDC, China Telecommunications Corporation
country: CNaut-num: AS4134
as-name: CHINANET-BACKBONE
descr: No.31,Jin-rong Street
descr: Beijing
descr: 100032
country: CN
More alerts from :
88.159.0.0/16 being advertised with aspath 286 4134 23724 23724.
route: 88.159.0.0/16
descr: Edutel Network
origin: AS39309
mnt-by: MNT-EDUTEL
source: RIPE # Filtered
Cant someone properlyu filter the crap inside Chinanet? This is silly.
Bye,
Raymond.
I'm starting to wonder if someone is 'testing the waters' in China to see what they can get away with. I hate to be like this, but there's a reason why I have all of China filtered on my routers.
Amazing how much SSH hammering, spam, and other nastiness went away within minutes of the filtering going in place.
There comes a point where 'accidental' and 'isolated incident' become "we no care" and "spam not illegal". And no, i'm not quoting that to mock, but rather repeat exactly what admins in China send to me in response to abuse reports and blocking in the AHBL.
I think the folks at Google have been down the same path.
Is it possible for you to share that filter list you have for china?
im getting bogged down by those ssh-bruts as well coming in from
china.
-B
Sure, check off-list momentarily, you'll have a nice Foundry formatted ACL that can easily be adjusted to work with cisco or anything else that uses a similar format.
Anyone else want a copy of the ACLs while i've got it in front of me?
Do share!
Please.
Since there's been alot of requests for the ACLs, i've gone ahead and put the info on our wiki for easy access.
http://wiki.sosdg.org/sosdg:internal:chinafilter
Hope it comes in handy, and please let me know if i'm missing anything.
+1
If you're going to post this and folks are actually going to consider
employing it I suspect it'd be well worthwhile to include on that page
how you generated it and how you keep it updated -- so that it can be
updated by others as necessary.
Additionally, folks should note that this policy would have made zero
difference in this particularly incident, most of you likely realize that.
Furthermore, a policy such as this does nothing to mitigate exfiltration
of data TO those address blocks you've listed.
FWIW, this is a lot like putting a bandaid on a headache - it's not going
to do much good in reality, and likely cause more harm than good in properly
secured networks - but it might make some folks feel a little better.
-danny
Since there's been alot of requests for the ACLs, i've gone ahead and put the info on our wiki for easy access.
http://wiki.sosdg.org/sosdg:internal:chinafilter
Hope it comes in handy, and please let me know if i'm missing anything.
If you're going to post this and folks are actually going to consider
employing it I suspect it'd be well worthwhile to include on that page
how you generated it and how you keep it updated -- so that it can be
updated by others as necessary.
Its sorta a mess to generate that final list.
The best way, is to take the County IP Blocks list, use a tool like cidr-convert.c (http://www.spamshield.org/cidr-convert.c) to aggregate blocks.
For Foundry, there's the ability to enter into an input mode for ACLs where you can dump a list of CIDR blocks, and it will handle the conversion into access-list commands.
I grabbed that access-list from the routers directly, so thats why it's been generated already. If there's a tool for UNIX/Linux that can generate the wildcard masks from CIDR in bulk for use in creating ACLs, I'd be happy to put it up on the page.
Additionally, folks should note that this policy would have made zero
difference in this particularly incident, most of you likely realize that.
Furthermore, a policy such as this does nothing to mitigate exfiltration
of data TO those address blocks you've listed.
Of course, this wont fix the prefix leaks. I think everyone here knows that. 
FWIW, this is a lot like putting a bandaid on a headache - it's not going
to do much good in reality, and likely cause more harm than good in properly
secured networks - but it might make some folks feel a little better.
More harm then good is a matter of opinion. Denying all of mainland China reduces the amount of attacks on my network. If you consider that masking security problems rather then fixing them, then *shrugs*. Its just one of many layers. It also allows me to make and enforce the statement that I will not tolerate the bullshit China pulls.
behavior modification. chinanet doesn't listen to complaints from victims. perhaps they'll listen to complaints from customers when they can't reach anyone anymore.
this is after all how spam RBLs work. providers don't care one whit about everyone who gets spammed, but they care if their customers walk because they can't reach anyone.
-Dan
FWIW, I get it - folks are surely going to implement local security
policies that are first aligned with corporate [and national] security
objectives.
My concern is that if people think bogon filters break stuff, just wait
until a couple thousand networks start selectively filtering countries
based on some notion of geoIP mappings (e.g., CN today, KP and IR
tomorrow, etc..), when in many cases prefixes span lots of national
boundaries (as do many ASNs) - the Internet will continue to fragment
and brokenness will result.
As an example of how such network filtering policies might well become
an operational problem consider a client using Online Certificate Status
Protocol (OCSP) with X.509 digital certificates before setting up a secure
connection to a web server somewhere in Asia (the server itself may well
NOT be inside of China). The client, wanting to inquire as to the state
(revocation status) of a particular certificate generated by that CNNIC
CA embedded in their Firefox client, reaches out to an OCSP server that's
authoritative for the cert - in this case CNNIC. Unfortunately, CNNIC,
which primarily resides within 218.241.0.0/16, isn't reachable because
of this entry in your ACL:
access-list 199 deny ip 218.240.0.0 0.7.255.255 any
Now, whether you or any of the users on your network choose to leave that
CNNIC CA (or others) enabled in your client is a separate issue, but
default drop policies such as you're recommending can certainly result
in some collateral damage that can be very tedious to debug, and possibly
even broaden attack surfaces themselves.
I'm not particularly a fan of bogon filters for reasons outlined here
and elsewhere many times before - and bogon addresses theoretically
don't have live clients and servers folks might be legitimately be
transacting with.
-danny
UNIX/Linux users can probably accomplish using simple scripting,
since there are perl modules such as NetAddr::IP available.
eg
#!/usr/bin/perl
use Net::CIDR qw/cidradd/;
use NetAddr::IP;
@list=();
while (<>) {
chomp;
while ( $_ =~ s/^\s*([a-fA-F0-9:.]+)\/(\d+)\s*/ / ) {
@list = cidradd($1 . '/' . $2, @list);
}
}
for (@list) { $ip = new NetAddr::IP($_);
print "access-list 199 deny " . $ip->addr() . " " . $ip->wildcard() . "\n"
;
}
I'm starting to wonder if someone is 'testing the waters' in China to
see what they can get away with. I hate to be like this, but there's a
reason why I have all of China filtered on my routers.
Beware of prejudice influencing observations and their interpretation.
....
Amazing how much SSH hammering, spam, and other nastiness went away
within minutes of the filtering going in place.
Objectively for my networks the vast majority of the SSH hammering, spam
and other nastiness would go away if I filtered out the prefixes allocated
by ARIN. I do not do that because I want to talk to hosts at these addressses.
Sometimes I even want to talk to hosts that originnate the nastiness. I certainly
do not want my upstreams start preventing me from doing that.
**** Selectively preventing packet flow is *not* a security measure.
**** Selectively preventing packet flow leads to unexpected and hard to diagnose breakage.
**** Many independent actors selectively preventing packet flow will eventually
partition the Internet sufficiently to break it beyond recognition.
Preventing packet flow may be necessary to mitigate DoS and to do local
security; I have pulled out the network cable before too. However doing it at
many different places in the network according to local policies leads to
bad breakage.
Daniel
It depends. Preventing packet flow from a rather more carefully
selected list of prefixes may actually make sense.
These for example - www.spamhaus.org/drop/
Filtering prefixes that your customers may actually exchange valid
email / traffic with, and that are not 100% bad is not the best way to
go.
Block specific prefixes from China, the USA, Eastern Europe, wherever
- that are a specific threat to your network .. great. Even better
if you are able to manage that blocking and avoid turning your router
ACLs into a sort of Hotel California for prefixes.
And now for the political analysis in our morning programming
broadcasted to North America:
Beware of unintentionally helping the Chinese government to implement
the Great Firewall by blocking packet flow right there in the land of
Free Speech(TM).
The satisfaction of vigorously loosing shots will qiuckly dissipate as
soon as the bullets start impacting feet very nearby.
Now let us return to our regular mix of operationally tinted programming.
See ipdeny.com for allocations covering about 225 countries. Alternatively,
please see http://www.okean.com/asianspamblocks.html for lists that cover
China and Korea only. The former is furnished in CIDR; the latter in CIDR,
Apache htaccess, Cisco ACL, and Linux iptables.
---Rsk
Is it possible for you to share that filter list you have for china?
im getting bogged down by those ssh-bruts as well coming in from
china.
Good ones available here : in several notations (including Cisco ACL) :
Cheers,
Michael Holstein
Cleveland State University