We have seen a lot Unauthorized attempts from Mid-East, China recently. I wanted to see if there is a blacklist of IPs that is maintained or we as Service Providers should maintain. Maybe a wild idea but worth a shot. I would like to identify whole subnets from even sending traffic to our networks. Here is the IPs we have blocked recently... 188.161.142.151 188.161.135.62 85.114.97.106 113.105.152.137 121.14.149.148 113.105.152.131 113.105.152.135 188.161.130.5 121.14.149.148 188.161.135.62 188.161.155.180 188.225.184.117 95.35.189.89 188.161.241.77 95.35.211.88 188.225.193.97 Shut the buggers out!
good lists to drop http://www.spamhaus.org/drop/drop.lasso http://www.countryipblocks.net/ On Apr 17, 2010, at 10:14 PM, Ujjval Karihaloo wrote:
We have seen a lot Unauthorized attempts from Mid-East, China recently. I wanted to see if there is a blacklist of IPs that is maintained or we as Service Providers should maintain. Maybe a wild idea but worth a shot. I would like to identify whole subnets from even sending traffic to our networks.
Here is the IPs we have blocked recently?
188.161.142.151 188.161.135.62 85.114.97.106 113.105.152.137 121.14.149.148 113.105.152.131 113.105.152.135 188.161.130.5 121.14.149.148 188.161.135.62 188.161.155.180 188.225.184.117 95.35.189.89 188.161.241.77 95.35.211.88 188.225.193.97
Shut the buggers out!
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I've been blocking everything indicated by the APNIC RIR to be assigned in .cn, .kr, and .tw without any apparent material impact to the world whatsoever. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 On Apr 18, 2010, at 1:14 AM, Ujjval Karihaloo <ujjval at simplesignal.com> wrote:
We have seen a lot Unauthorized attempts from Mid-East, China recently. I wanted to see if there is a blacklist of IPs that is maintained or we as Service Providers should maintain. Maybe a wild idea but worth a shot. I would like to identify whole subnets from even sending traffic to our networks.
Here is the IPs we have blocked recently?
188.161.142.151
188.161.135.62
85.114.97.106
113.105.152.137
121.14.149.148
113.105.152.131
113.105.152.135
188.161.130.5
121.14.149.148
188.161.135.62
188.161.155.180
188.225.184.117
95.35.189.89
188.161.241.77
95.35.211.88
188.225.193.97
Shut the buggers out!
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Depending on your scope of service, I personally have found that maintaining static blocklists just creates a heap of support problems, but instead deny traffic outside ARIN allocated IP's and allow customers to turn on international use individually which has severely cut down our fraud, since chasing it statically is just a game of whack-a-mole. Though this topic does raise a question I have been kicking around for a while, has anyone here tried implementing a SIP equivalent of URPF on your border controllers or proxies on the peering side, so if you cannot determine a route back to the calling number you drop the call to IVR or reject? Obviously implementing UPRF at L3 has saved me tons of headaches in other facets, but certainly a L5 solution could alleviate a potential ton of spam calls that come through normal PSTN connections. Thoughts? On Sat, 2010-04-17 at 22:14 -0700, Ujjval Karihaloo wrote:
We have seen a lot Unauthorized attempts from Mid-East, China recently. I wanted to see if there is a blacklist of IPs that is maintained or we as Service Providers should maintain. Maybe a wild idea but worth a shot. I would like to identify whole subnets from even sending traffic to our networks.
Here is the IPs we have blocked recently?
188.161.142.151
188.161.135.62
85.114.97.106
113.105.152.137
121.14.149.148
113.105.152.131
113.105.152.135
188.161.130.5
121.14.149.148
188.161.135.62
188.161.155.180
188.225.184.117
95.35.189.89
188.161.241.77
95.35.211.88
188.225.193.97
Shut the buggers out!
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 04/18/2010 03:37 AM, anorexicpoodle wrote:
Though this topic does raise a question I have been kicking around for a while, has anyone here tried implementing a SIP equivalent of URPF on your border controllers or proxies on the peering side, so if you cannot determine a route back to the calling number you drop the call to IVR or reject? Obviously implementing UPRF at L3 has saved me tons of headaches in other facets, but certainly a L5 solution could alleviate a potential ton of spam calls that come through normal PSTN connections. Thoughts?
This would seem to come down to the question of what exactly it means to have or not have a route to a given calling number. Validate it against basic NANPA form rules? Look it up prefix-wise against a current list of currently allocated NANPA and Pooling blocks, or against the LERG? See if at least one of your termination carriers has a specific route of a certain minimum prefix length (i.e. longer than just "1")? -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Apr 18, 2010, at 3:37 AM, anorexicpoodle wrote:
Depending on your scope of service, I personally have found that maintaining static blocklists just creates a heap of support problems, but instead deny traffic outside ARIN allocated IP's and allow customers to turn on international use individually which has severely cut down our fraud, since chasing it statically is just a game of whack-a-mole.
Though this topic does raise a question I have been kicking around for a while, has anyone here tried implementing a SIP equivalent of URPF on your border controllers or proxies on the peering side, so if you cannot determine a route back to the calling number you drop the call to IVR or reject? Obviously implementing UPRF at L3 has saved me tons of headaches in other facets, but certainly a L5 solution could alleviate a potential ton of spam calls that come through normal PSTN connections. Thoughts?
This is extremely difficult, if not impossible to do, with E.164 addresses. If you have a specific method that doesn't run into the authority/ownership headache issues that I can think of, please let the list know - I don't think there's a foolproof (or even marginally useful) way to do this. IMHO, E.164 should die. Good thing my opinion has little impact on the global telephony infrastructure! ;-) However, there IS a way to implement a semi-robust method for verifying domain identity for calls that come in with a SIP URI as the From: address or other type of asserted-identity. It is kinda-sorta like URPF, or SPF. Check out this idea I had some time ago (code included!): https://archives.internet2.edu/wws/arc/sip.edu/2006-07/msg00012.html I have implemented this on my machines and it worked quite well (using Asterisk, but almost any intelligent SIP platform could easily script this method) and it seems to close a lot of the risk holes in accepting SIP session invitations from "the Internet at large." Note: people reading that letter may assume, without close examination, that this is based on inverse address (in-addr) usage. It is not. :-) JT
participants (5)
-
abalashov＠evaristesys.com -
anorexicpoodle＠gmail.com -
jtodd＠loligo.com -
kyle＠vobisvoice.com -
ujjval＠simplesignal.com