BGP hijack from 23724 -> 4134 China?
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 -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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: CN
aut-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.
On 4/8/10 2:23 PM, Jay Hennigan wrote:
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
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On 4/8/10 1:36 PM, Brielle Bruns wrote:
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. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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 On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns <bruns@2mbit.com> wrote:
On 4/8/10 2:23 PM, Jay Hennigan wrote:
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
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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.
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
On 4/8/10 6:29 PM, Beavis wrote:
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.
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? -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
Do share! On Thu, Apr 8, 2010 at 7:29 PM, Beavis <pfunix@gmail.com> wrote:
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
On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns <bruns@2mbit.com> wrote:
On 4/8/10 2:23 PM, Jay Hennigan wrote:
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
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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.
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
Please. -----Original Message----- From: Will Clayton [mailto:w.d.clayton@gmail.com] Sent: Thursday, April 08, 2010 8:43 PM To: Beavis Cc: nanog@nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China? Do share! On Thu, Apr 8, 2010 at 7:29 PM, Beavis <pfunix@gmail.com> wrote:
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
On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns <bruns@2mbit.com> wrote:
On 4/8/10 2:23 PM, Jay Hennigan wrote:
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
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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.
-- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
-- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.801 / Virus Database: 271.1.1/2796 - Release Date: 04/08/10 13:32:00
On 4/8/10 7:50 PM, Aaron Wendel wrote:
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. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Apr 8, 2010, at 8:05 PM, Brielle Bruns wrote:
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. 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
On 4/8/10 8:17 PM, Danny McPherson wrote:
On Apr 8, 2010, at 8:05 PM, Brielle Bruns wrote:
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. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
On Apr 8, 2010, at 8:35 PM, Brielle Bruns wrote:
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.
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
On Thu, Apr 8, 2010 at 9:35 PM, Brielle Bruns <bruns@2mbit.com> wrote:
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.
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" ; } -- -J
On Thu, 8 Apr 2010, Danny McPherson wrote:
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.
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
-----Original Message----- From: Brielle Bruns [mailto:bruns@2mbit.com] Sent: Thursday, April 08, 2010 7:06 PM To: nanog@nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China?
On 4/8/10 7:50 PM, Aaron Wendel wrote:
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.
I suppose it is easier and takes less of your resources to get the world to block you than it is to block the world.
From China's point of view, it might just make their firewalling a whole lot easier.
On Fri, 9 Apr 2010, George Bonser wrote:
I suppose it is easier and takes less of your resources to get the world to block you than it is to block the world.
operating a bullet proof spam network, ignoring complaints, is certainly one way to achieve that. anyone remember chinanet's lying autoresponder: In your SPAM eMail,I can't find the IP or the IP is not by my control.Please give me the correct IP.Thank you. ? -Dan
+1 On Thu April 8 2010 20:50, Aaron Wendel wrote:
Please.
-----Original Message----- From: Will Clayton [mailto:w.d.clayton@gmail.com] Sent: Thursday, April 08, 2010 8:43 PM To: Beavis Cc: nanog@nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China?
Do share!
On Thu, Apr 8, 2010 at 7:29 PM, Beavis <pfunix@gmail.com> wrote:
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
On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns <bruns@2mbit.com> wrote:
On 4/8/10 2:23 PM, Jay Hennigan wrote:
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
-- Jay Hennigan - CCIE #7880 - Network Engineering - jay@impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV
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.
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) : http://www.okean.com/antispam/china.html Cheers, Michael Holstein Cleveland State University
So basically, the idea is to disconnect China's Internet even more than what it inflicts to itself? How fun. What was the FCC/Comcast case about again? I'm totally against this practice, but if you (stupidly) want to apply it, do it for good. http://ftp.apnic.net/stats/apnic/delegated-apnic-latest grep '|CN|ipv4|' and to get your network length from the number of IP in the range: $len=32-log($num_of_IP)/log(2) Michael Holstein a écrit :
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) :
http://www.okean.com/antispam/china.html
Cheers,
Michael Holstein Cleveland State University
Benjamin BILLON wrote:
So basically, the idea is to disconnect China's Internet even more than what it inflicts to itself?
And that is wrong why exactly? ;-)
How fun. What was the FCC/Comcast case about again?
It's only port 25, at least here: http://www.okean.com/antispam/iptables/iptables.html
So basically, the idea is to disconnect China's Internet even more than what it inflicts to itself? And that is wrong why exactly? ;-) Nah, I'm not answering that =D Nice try, though. How fun. What was the FCC/Comcast case about again? It's only port 25, at least here: http://www.okean.com/antispam/iptables/iptables.html This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart?
If you think Chinese DUL would be interesting, please tell me.
Benjamin Billon wrote:
And that is wrong why exactly? ;-) Nah, I'm not answering that =D Nice try, though.
Hah ;-)
This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart?
It depends. I'am not a fan of country blocking. But in my case it can work for a home server. You could adapt the list and block port 22 only for production servers where you can't expect to never have email from China, but can safely block brute force ssh attacks. Regards, Jeroen
This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart?
It depends. I'am not a fan of country blocking. But in my case it can work for a home server. You could adapt the list and block port 22 only for production servers where you can't expect to never have email from China, but can safely block brute force ssh attacks.
Yep, home server, your server. That's not the same when you have customers who rely on your server. IMHO, port 22 and other critical ports should always be blocked except from known places.
On 4/9/2010 15:42, Benjamin Billon wrote:
This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart?
It depends. I'am not a fan of country blocking. But in my case it can work for a home server. You could adapt the list and block port 22 only for production servers where you can't expect to never have email from China, but can safely block brute force ssh attacks.
Yep, home server, your server. That's not the same when you have customers who rely on your server. IMHO, port 22 and other critical ports should always be blocked except from known places.
I personally use a port knocking setup and it pretty much eliminates SSH brute force account/password hacks. Actually, on one box that didn't have the ability to do that, I simply moved the SSH port. This was surprisingly effective, although a bit inconvenient. I'll have to say that a very large number of the brute attempts were from Chinese IPs. Hopefully they're not reading this. ;-)
Benjamin Billon wrote:
So basically, the idea is to disconnect China's Internet even more than what it inflicts to itself? And that is wrong why exactly? ;-) Nah, I'm not answering that =D Nice try, though. How fun. What was the FCC/Comcast case about again? It's only port 25, at least here: http://www.okean.com/antispam/iptables/iptables.html This is also blocking Sina, Netease, Yahoo.cn and other major Chinese ISP/ESP. Am I the only to think this is not very smart?
If you think Chinese DUL would be interesting, please tell me.
This DID actually bite my company about 3 years ago. A customer went to China (usually in NYC) and could not send email through the mail server because they were using POP-before-SMTP instead of the mail submission port . Upon return, the customer switched mail service away from us. --Patrick
Patrick Giagnocavo wrote:
This DID actually bite my company about 3 years ago.
A customer went to China (usually in NYC) and could not send email through the mail server because they were using POP-before-SMTP instead of the mail submission port .
The problem did not lie with blocking IPs. But with offering a flawed service such as pop before smtp to begin with. I know many ISPs/ESPs still do, much to my chagrin. The only way to submit email should be port 587 with TLS encryption, 3 years ago one could be forgiven for offering deprecated (*) port 465 with SSL, but not anymore (msoft clients have been fixed). Regards, Jeroen http://www.iana.org/assignments/port-numbers * urd 465/tcp URL Rendesvous Directory for SSM
On Thu, Apr 08, 2010 at 06:29:07PM -0600, Beavis wrote:
Is it possible for you to share that filter list you have for china?
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
Rich Kulawiec wrote:
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.
Thanks, the iptables list comes in quite handy. People may wish to block port 22 as well as port 25. Although something like fail2ban takes care of that nicely. Greetings, Jeroen
Are we to believe that filtering .cn will filter all Chinese attacks? I know that if I was up to no good in China, I'd buy a cheap VSAT connection, tld's are probably not a good way to identify bad guys. My two cents.. //warren -----Original Message----- From: Jeroen van Aart [mailto:jeroen@mompl.net] Sent: Friday, April 09, 2010 11:14 AM To: nanog@nanog.org Subject: Re: BGP hijack from 23724 -> 4134 China? Rich Kulawiec wrote:
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.
Thanks, the iptables list comes in quite handy. People may wish to block port 22 as well as port 25. Although something like fail2ban takes care of that nicely. Greetings, Jeroen
-----Original Message----- From: Warren Bailey [mailto:wbailey@gci.com] Sent: Friday, April 09, 2010 12:31 PM To: Jeroen van Aart; nanog@nanog.org Subject: RE: BGP hijack from 23724 -> 4134 China? Are we to believe that filtering .cn will filter all Chinese attacks? I know that if I was up to no good in China, I'd buy a cheap VSAT connection, tld's are probably not a good way to identify bad guys. My two cents.. //warren -------------------------- As was pointed out that might have been the point of hijacking IP space from outside cn.net. -Jim
On 08.04 14:36, Brielle Bruns wrote:
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. On Fri, Apr 9, 2010 at 11:52 AM, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
**** 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.
-- Suresh Ramasubramanian (ops.lists@gmail.com)
:-) ;-) ;-) 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. :-) ;-) ;-)
Jay Hennigan <jay@west.net> writes:
We just got Cyclops alerts showing several of our prefixes sourced from AS23474 propagating through AS4134. Anyone else?
For the record, yes. Two of our blocks were announced via 7575 4134 23724 yesterday. First seen by Cyclops at 2010-04-08 15:57:13 UTC and lasted about 20 minutes. Does AS7575, Australian Academic and Reasearch Network, do any filtering? -- Bob Poortinga K9SQL <http://www.linkedin.com/in/bobpoortinga> Technology Service Corp. <http://www.tsc.com> Bloomington, Indiana US
participants (23)
-
Aaron Wendel -
Beavis -
Benjamin Billon -
Benjamin BILLON
-
Bob Poortinga -
Brielle Bruns -
Daniel Karrenberg -
Danny McPherson -
George Bonser -
goemon＠anime.net -
James Hess -
Jay Hennigan -
Jeroen van Aart -
Jim Burwell -
Jim Templin -
Larry Smith -
Michael Holstein -
Patrick Giagnocavo -
Raymond Dijkxhoorn -
Rich Kulawiec -
Suresh Ramasubramanian -
Warren Bailey -
Will Clayton