April 2016 - Test - lists.nanog.org

how to deal with port scan and brute force attack from AS 8075 ?
by marcel.duregards＠yahoo.fr 07 Apr '16

07 Apr '16

Dear Nanog'er, We are facing a lot of port scan and brute force attack on port 22 (but not limited to) from Microsoft AS 8075 range toward our own infra, or toward our customers. We have sent email to abuse(a)microsoft.com, but no answer. source ip are: NetRange: 40.74.0.0 - 40.125.127.255 CIDR: 40.74.0.0/15, 40.112.0.0/13, 40.124.0.0/16, 40.76.0.0/14, 40.80.0.0/12, 40.125.0.0/17, 40.96.0.0/12, 40.120.0.0/14 NetName: MSFT We consider port scan and brute force on ssh port as an attack, and even as a pre-DDOS phase (could be use to install botnet, detect unpatched host, and so one). It's one thing to propose services and make money over an infra, it's an other thing to take care that you clients do not use this infra to make illegal stuffs. How do you deal with such massive amount of 'illegal' traffic ? Thank, Best Regards Marcel He are some examples (we have more than 3000 such packets per day just from them, probably Azure), and source ip is always differents of course: Flow Filtering Expression src AS 8075 and dst port 22 and packets=1 Limit Flows 40000 Sorting By Date Date_first_seen Duration Proto _IP_Addr:Port Dst_IP_Addr:Port Flags Packets 2016-02-29 14:55:20.108 0.000 6 104.45.210.69:1160 -> x.x.231:22 ...... 1 2016-02-29 14:55:20.611 0.000 6 104.45.210.69:1161 -> x.x.231:22 ...... 1 2016-02-29 14:56:41.004 0.000 6 40.76.55.204:1090 -> x.x..14:22 ...... 1 2016-02-29 14:56:41.324 0.000 6 40.76.55.204:1091 -> x.x..14:22 ...... 1 2016-02-29 15:00:05.670 0.000 6 40.76.55.204:1088 -> x.x.125:22 ...... 1 2016-02-29 15:00:06.003 0.000 6 40.76.55.204:1089 -> x.x.125:22 ...... 1 2016-02-29 15:01:17.358 0.000 6 40.76.70.58:1168 -> x.x..80:22 ...... 1 2016-02-29 15:01:17.676 0.000 6 40.76.70.58:1169 -> x.x..80:22 ...... 1 2016-02-29 15:02:42.637 0.000 6 40.76.55.204:1176 -> x.x.193:22 ...... 1 2016-02-29 15:02:42.878 0.000 6 40.76.55.204:1177 -> x.x.193:22 ...... 1 2016-02-29 15:02:48.067 0.000 6 104.45.210.69:1160 -> x.x.173:22 ...... 1 2016-02-29 15:02:48.394 0.000 6 104.45.210.69:1161 -> x.x.173:22 ...... 1 2016-02-29 15:03:18.854 0.000 6 40.121.53.153:1041 -> x.x..88:22 ...... 1 2016-02-29 15:03:19.172 0.000 6 40.121.53.153:1042 -> x.x..88:22 ...... 1 2016-02-29 15:06:36.248 0.000 6 40.76.55.204:1056 -> x.x..45:22 ...... 1 2016-02-29 15:07:31.882 0.000 6 40.76.80.17:44895 -> x.x..75:22 ...... 1 2016-02-29 15:07:32.245 0.000 6 40.76.80.17:44896 -> x.x..75:22 ...... 1 2016-02-29 15:09:08.433 0.000 6 40.76.70.58:1168 -> x.x..31:22 ...... 1 2016-02-29 15:09:08.744 0.000 6 40.76.70.58:1169 -> x.x..31:22 ...... 1 2016-02-29 15:11:45.668 0.000 6 40.76.80.17:47993 -> x.x.157:22 ...... 1 2016-02-29 15:11:45.987 0.000 6 40.76.80.17:47994 -> x.x.157:22 ...... 1 2016-02-29 15:12:09.543 0.000 6 40.76.70.58:1168 -> x.x..24:22 ...... 1 2016-02-29 15:12:09.925 0.000 6 40.76.70.58:1169 -> x.x..24:22 ...... 1 2016-02-29 15:17:05.920 0.000 6 40.76.70.58:1168 -> x.x.243:22 ...... 1 2016-02-29 15:17:06.241 0.000 6 40.76.70.58:1169 -> x.x.243:22 ...... 1 2016-02-29 15:19:21.364 0.000 6 40.83.121.211:62936 -> x.x..81:22 ...... 1 2016-02-29 15:19:21.704 0.000 6 40.83.121.211:62937 -> x.x..81:22 ...... 1 2016-02-29 15:19:45.891 0.000 6 40.76.70.58:1168 -> x.x..39:22 ...... 1 2016-02-29 15:19:46.273 0.000 6 40.76.70.58:1169 -> x.x..39:22 ...... 1 2016-02-29 15:21:52.030 0.000 6 40.76.70.58:1168 -> x.x.120:22 ...... 1 2016-02-29 15:21:52.349 0.000 6 40.76.70.58:1169 -> x.x.120:22 ...... 1 2016-02-29 15:24:07.614 0.000 6 40.76.55.204:1048 -> x.x.237:22 ...... 1 2016-02-29 15:24:07.933 0.000 6 40.76.55.204:1128 -> x.x.237:22 ...... 1 2016-02-29 15:27:31.289 0.000 6 40.121.53.153:1041 -> x.x.133:22 ...... 1 2016-02-29 15:27:31.544 0.000 6 40.121.53.153:1042 -> x.x.133:22 ...... 1 2016-02-29 15:27:59.120 0.000 6 40.76.70.58:1168 -> x.x.9.3:22 ...... 1 2016-02-29 15:27:59.440 0.000 6 40.76.70.58:1169 -> x.x.9.3:22 ...... 1 2016-02-29 15:29:30.933 0.000 6 40.76.70.58:1168 -> x.x.211:22 ...... 1 2016-02-29 15:29:31.031 0.000 6 40.76.70.58:1169 -> x.x.211:22 ...... 1 2016-02-29 15:29:33.729 0.000 6 40.76.55.204:1142 -> x.x.166:22 ...... 1 2016-02-29 15:29:34.032 0.000 6 40.76.55.204:1143 -> x.x.166:22 ...... 1 2016-02-29 15:31:41.947 0.000 6 40.76.70.58:1168 -> x.x.137:22 ...... 1 2016-02-29 15:31:42.266 0.000 6 40.76.70.58:1169 -> x.x.137:22 ...... 1 2016-02-29 15:32:10.044 0.000 6 40.121.53.153:1041 -> x.x..71:22 ...... 1 2016-02-29 15:32:10.348 0.000 6 40.121.53.153:1042 -> x.x..71:22 ...... 1 2016-02-29 15:32:10.442 0.000 6 104.45.210.69:1161 -> x.x.246:22 ...... 1 2016-02-29 15:32:10.475 0.000 6 104.45.210.69:1160 -> x.x.246:22 ...... 1 2016-02-29 15:32:29.165 0.000 6 40.121.143.132:1040 -> x.x..62:22 ...... 1 2016-02-29 15:32:29.466 0.000 6 40.121.143.132:1041 -> x.x..62:22 ...... 1 2016-02-29 15:37:07.616 0.000 6 40.76.80.17:56902 -> x.x..51:22 ...... 1 2016-02-29 15:37:07.925 0.000 6 40.76.80.17:56903 -> x.x..51:22 ...... 1 2016-02-29 15:40:04.546 0.000 6 40.121.53.153:1041 -> x.x.186:22 ...... 1 2016-02-29 15:40:04.866 0.000 6 40.121.53.153:1042 -> x.x.186:22 ...... 1 2016-02-29 15:40:28.870 0.000 6 40.76.70.58:1168 -> x.x.171:22 ...... 1 2016-02-29 15:40:29.125 0.000 6 40.76.70.58:1169 -> x.x.171:22 ...... 1 2016-02-29 15:41:57.034 0.000 6 40.76.55.204:1128 -> x.x.181:22 ...... 1 2016-02-29 15:41:57.354 0.000 6 40.76.55.204:1176 -> x.x.181:22 ...... 1 2016-02-29 16:55:49.183 0.000 6 40.117.96.192:1120 -> x.x.163:22 ...... 1 2016-02-29 16:55:49.183 0.000 6 40.117.96.192:1120 -> x.x.176:22 ...... 1 2016-02-29 16:55:49.183 0.000 6 40.117.96.192:1120 -> x.x.206:22 ...... 1 2016-02-29 16:55:49.183 0.000 6 40.117.96.192:1120 -> x.x.158:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.185:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.251:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.255:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.141:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.136:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.235:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.242:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.240:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.100:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.244:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x.217:22 ...... 1 2016-02-29 16:55:49.186 0.000 6 40.117.96.192:1120 -> x.x..72:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.221:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.5.4:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.150:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.145:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.119:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..52:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..75:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.127:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..22:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..77:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.246:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x.137:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..85:22 ...... 1 2016-02-29 16:55:49.187 0.000 6 40.117.96.192:1120 -> x.x..35:22 ...... 1

11 12

Best practices for sending network maintenance notifications
by Dan Mahoney, System Admin 07 Apr '16

07 Apr '16

All, We recently, at $dayjob, had one of our peers (at Symantec) send out a network maint notification, putting 70 addresses in the "To:" field, rather than using BCC or the exchange's mailing list. Naturally, when you mail 30 addresses, of the forms peering@ and noc@ various organizations, you're likely to hit at least a few autoresponders and ticket systems... And at least one or two of those autoresponders are of course brainded and configured to reply-all. (In this case, Verizon's ServiceNow setup was such a stupid responder). And that made things fun in our own ticket system, as our RT setup happily created a bunch of tickets. My question for the group -- does anyone know if there's a "best practices" for sending maint notifications like this? An RFC sort of thing? While it would define a social protocol, rather than a truly technical one, if there's not such a document, it seems like it could useful. And once such a thing exists, exchanges could of course helpfully point their members AT it (for both their humans, and ticket systems, to follow). -Dan --

9 8

RE: Best practices for sending network maintenance notifications
by Scott Weeks 06 Apr '16

06 Apr '16

--- ray(a)orsiniit.com wrote: From: Ray Orsini <ray(a)orsiniit.com> "The other "don't do that" is never configure Music on Hold for any NOC/SOC lines. Few things are more annoying than a eight hour trouble shooting conference bridge, and one of the dozen NOC/SOCs on the bridge hits the Hold button." Now that you've said it it seems so obvious. But, honestly I'd never thought it until right now. Thanks! ------------------------------- It only takes one time on a hectic multi-party call to learn this one. It's painful and at the worst possible time, especially if they left the room and no one can be contacted to get it turned off. scott

1 0

GCN / DigiCell or Columbus Communications ?
by Faisal Imtiaz 06 Apr '16

06 Apr '16

Hello, We are looking for 10g wave between Puerto Rico to Trinidad (Maparippe). Please contact me off list. Thanks. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support(a)Snappytelecom.net

1 0

gmail for business email contact - server blacklisted
by Joseph Jenkins 06 Apr '16

06 Apr '16

Anyone on here from gmail that can help with an issue. One of your email servers has been blacklisted by spam cop and is still in rotation. It's causing individual senders to be blocked on our side. If possible can you remove that server from rotation? IP is: 209.85.161.176

1 0

WEBCAST TODAY: NEDASNYC In-Building Wireless Summit
by Joly MacFie 06 Apr '16

06 Apr '16

This is the second year I've streamed the NEDAS NYC conference. It's a very high quality event that gets into nuts and bolts of bringing connectivity to mobile devices in dense environments. Last year one panel <https://livestream.com/internetsociety/nedasnyc/videos/93602678> was a fascinating dialog on how best to bring wireless to NYC's subway. The first panel today, already underway, is about how to bring "carrier-grade" upload capability to stadiums. Speakers include engineers who have done the Superbowl and the Olympics. *Agenda: https://www.nedas.com/events/nedas-spring-in-building-wireless-summit-nyc <https://www.nedas.com/events/nedas-spring-in-building-wireless-summit-nyc>Webcast: https://new.livestream.com/internetsociety/nedasnyc2016 <https://new.livestream.com/internetsociety/nedasnyc2016>* -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast -------------------------------------------------------------- -

1 0

Some doubts on large scale BGP/AS design and black hole routing risk
by magicboiz＠hotmail.com 05 Apr '16

05 Apr '16

Hi everybody! as part of laboratory work at the university, I'm working on a BGP design study, and I would like to post some questions regarding IP address space allocation and its impact on BGP which are breaking my mind :) Let's suppose we have an ISP/AS with two POPs: PARIS and LONDON. These two POPs are connected with redundant leased lines. Each POP has a BGP router speaking eBGP to different ISP providers/upstreams and also, each POP run its own OSPF area/ISIS area. Something like this: <INET> ---eBGP---<LONDON POP-ospf area1>===redundant leased lines (ospf area0)===<PARIS POP- ospf area2>---eBGP---<INET> Now, this AS/ISP gets one /22 prefix from it RIR (RIPE in this case), and starts to announce it to its upstreams in PARIS and LONDON at the same time. My questions are: 1. What could happen in the case of total failure in the redundant leased lines? Black hole routing between POPs? 2. What are the best design methods to avoid this scenario? 2.1: adding a third POP creating a triangle? What if a POP looses connection with the other two POPs at the same time? Another black hole? 2.2: requesting another prefix and allocating 1:1 prefix:POP, so in the scenario each POP only would announce its prefix to the upstreams? 2.3: other? Thanks in advance! J.

6 9

Colocation Server Lifts
by Jason Lee 04 Apr '16

04 Apr '16

Hi NANOG community, A few questions I have for the community regarding server lifts at colo facilities. 1. Is a server lift something you would typically expect a colo facility to provide? if yes, 2. Do colo facilities typically allow customers to just use them or provide an operator? 3. Is it a free offering or something they rent out? 4. What would be the typical device weight you would lift? 5. What would be the max device weight you would lift? Thanks, Jason

5 4

Better Conversation following tools for Wireshark?
by Jay R. Ashworth 04 Apr '16

04 Apr '16

I have to do a little interactive monitoring this week, and while I want to run Wireshark to log the packets, I'd also like to be able to do some more hands on, flow-based monitoring, and the Conversations tool in WS2.x isn't up to the task; it won't let me roll up all traffic for a local IP into a single line, for example, as iftop will. I thought I'd be able to do this with ntop, but even though I can see that monitoring is enable to the switchport from WS, ntop only shows me the broadcast connections. Are there any better tools for this sort of work, that will cooperate with WS on a Win7Pro box? (Yeah, yeah; I know; it's all I have handy and I'm out of days; I had the flu last week like everyone else.) Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

Re: Some doubts on large scale BGP/AS design and black hole routing risk
by Scott Weeks 04 Apr '16

04 Apr '16

--- hank(a)efes.iucc.ac.il wrote: From: Hank Nussbacher <hank(a)efes.iucc.ac.il> Also providers lie either intentionally or by mistake. ---------------------------------------- s/ or by mistake// There fixed that. ;-) scott

1 0