- NANOG - lists.nanog.org

Attacking on Source Port 0 (ZERO)
by Shahab Vahabzadeh 16 Oct '12

16 Oct '12

Hi everybody, Does any body know what kind of attack can be come to port 0? I see such a logs in my routers which make high cpu loads: MYROUTERIP:0 *41.78.77.178:2816* MYROUTERIP:0 *217.160.5.153:2816* Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90

5 8

Re: If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set.
by Randy Bush 16 Oct '12

16 Oct '12

> APNIC will be switching to a new RPKI 'split' trust anchor system on > the 25th of October. This change is needed to align APNIC administered > resources with their allocation hierarchy. These resources will also > be certified under each responsible parent registry at the appropriate > time. > ... > If you have any questions please contact me. ok. i'll bite. what the heck is this meant to support? i thought the rirs were moving from five TALs to one. randy, very confused

5 5

Internet-wide port scans
by Florian Weimer 16 Oct '12

16 Oct '12

Are there somewhat reputable service providers for Internet-wide TCP port scans? What's the typical rate per TCP port? (I'm interested in rather obscure services whose identification may need additional probing, and this data is unlikely on file already.) A full scan needs just 0.5 TB of data per TCP port, so "roll your own" is definitely an option. But I expect that any halfway decent hosting provider will start asking questions after the first billion packets or so, and at least over here, broadband access without abuse management lacks sufficient upload bandwidth, making the results difficult to interpret because the measurements would span several days.

2 1

Anyone w/ clue @netsol?
by chris 15 Oct '12

15 Oct '12

I am having a issue delivering mail to a specific domain hosted @netsol for a significant amount of time now (several days) only and getting a vague error from the remote side: inbound.xxx.com.netsolmail.net [206.188.198.64]: 451 4.3.2 Please try again later I have tried the support channels referenced on the netsol website called support phone num and emailed emailhelp(a)networksolutions.com and still cant seem to find anyone with a clue or get this escalated past level 1 call center staff. I have an existing open ticket for some time now If you are @netsol or have any good technical contacts please contact me offlist thanks chris

4 4

CLI Roadmap
by Kasper Adel 15 Oct '12

15 Oct '12

Hello, I have never used any CLI other than Cisco so i am curious what useful and creative knobs and bolts are available for other network appliance Vendors. I guess what makes *NIX CLI/Shell so superior is that you can advanced stuff from the CLI using sed, awk and all the great tools there so maybe this is also one thing missing. Regards, Kim

4 3

If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set.
by George Michaelson 15 Oct '12

15 Oct '12

If you are using APNIC as an RPKI trust anchor, please update your Trust Anchor Set. APNIC will be switching to a new RPKI 'split' trust anchor system on the 25th of October. This change is needed to align APNIC administered resources with their allocation hierarchy. These resources will also be certified under each responsible parent registry at the appropriate time. In accordance with RFC6490 the old APNIC Trust Anchor Locator, associated certificate and repository will be removed, when the certificate expires on the 28th of October. 5 new Trust Anchor Locator (TAL) have been published. These will be kept up to date as an independent trust anchor set for resources maintained by APNIC. The production cycle will start on the 25th of October. Relying parties must add these new TAL by the 25th of October in order to maintain continuity of validation. If you have any questions please contact me. George Michaelson (ggm(a)apnic.net) Please add the following to your trust anchor set: rsync://rpki.apnic.net/repository/apnic-rpki-root-afrinic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuMLL96YV9pf0rZ4Ow/bk cgpoPfsRzkcgmisyCuMUdotHwrp8pepujhohatScRK09ILRrZYCdpX4121MJhqXC P3u3hy9fF0CeARKX/Q82nJccD4dtUp23UcFys8hwJgNYZI910ajkAxwNT//H/TFw oUYbzZGBR7o2awMc7GdQl/j6dgOkV6AfYy5DyDEgOUNHnUxED2rreefL/E2Fr2ST Esar6bTR4Tg4+nVF1PjAkgN0tKZYe4wZ6VmtqV/VTngSLysim6av7ki+JR3cVgVU OqXeh1vPjH2tNu6u9bX37ZrdVb6NBRer9I99IDbKvyhELb6nzo8+Q74zga9HI+Pf QwIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-arin-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp6vscYtzhe0CfFk5Ro44 llPhsInXtfAxqfYmK7m9V3khkqK3d3/ZAW6pcJm7qW8XhEGl+F5mUeeLIm5JoIhr kT5B5M6uL0VlCCkZJH4h76ybOa83vWITNZEDy9L3c3nK4S+Basu3vYoE4ICXGG+J 7zg5Iw9saV+p03E2w1g16pt1QI3Cnggp6edkeWClEz3aPw/ULOIHb7YmatWwdERl tL9LsuMSKszQLUY7F4XVpxey/rJYAZgzDUh+b6813WAClCkkydNjsbviuekAWJbx sW7Mcw53u30K4g8MP03CjkDOubyoR4Qo99R1UQJCdrRsFKbSSfN/fOA4y7ikc3xs jQIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-iana-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9RWSL61YAAYumEiU8z8 qH2ETVIL01ilxZlzIL9JYSORMN5Cmtf8V2JblIealSqgOTGjvSjEsiV73s67zYQI 7C/iSOb96uf3/s86NqbxDiFQGN8qG7RNcdgVuUlAidl8WxvLNI8VhqbAB5uSg/Mr LeSOvXRja041VptAxIhcGzDMvlAJRwkrYK/Mo8P4E2rSQgwqCgae0ebY1CsJ3Cjf i67C1nw7oXqJJovvXJ4apGmEv8az23OLC6Ki54Ul/E6xk227BFttqFV3YMtKx42H cCcDVZZy01n7JjzvO8ccaXmHIgR7utnqhBRNNq5Xc5ZhbkrUsNtiJmrZzVlgU6Ou 0wIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-lacnic-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyoYPp3l3DWyPtLWrmRn4 Oux9hQ5bxd0SX/f6ygHxik+I3eMJP5J0Pr2e500tyXb2uKsX9kDqu/kckr+TUMhV BHd5yAv8OAE3YYEvpz/7uTX7cYy2yUeA76OEP75Y88OIQEzGpPLNpIzDxMggxuDh IhkA5xMiUJgVoEgmWSzR+MuRBjv2422wAGB5GpLgYsOjpwvG0VPmhnE+39+10ucQ CLt0Ny5kOR4an2tkvHjm7rzKDnFm8MWxPzAWESdf+8g7ITzSglqxDNiK5E5rdzNt h1Kvp+9RwaFArw6Ky1A4HhnoplN4EfKwxq0YamuKV0ZTTpWyT2+qDuE6sOfHRbJ0 5QIDAQAB rsync://rpki.apnic.net/repository/apnic-rpki-root-ripe-origin.cer MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwsQlXmEklLYApoDo7GEa NNTEGFPU5wJpi04iXuga2xn+g/TMLOlyJbjuPYRtRm/7VbRnN3m9Ta+WETy03+Fm EbXzB4xxhJKVik/ARHBnrBWhLyURy8Q5/XplE9cJein37IE1mIsbKM7o/90S225w 7GuvW7T4kjPWYmBFOywHWsfQO1EdsgiJrkz+Ab67ZkdSIiKHkf2UE6/MrbDEj+QK 9+s/vKH8BtDhaLmTWY+bVvfJ3+AWDH6roo1ozbl5yamQFbLOl3ns30f3yOJcNSNu /qgMQRRyp2sXXQovhTy8yqm3LFspaCWnTmQtBieWZwibuOa4Z27A1FzTMst2T4wY /wIDAQAB

1 0

Re: Attacking on Source Port 0 (ZERO)
by Scott Weeks 15 Oct '12

15 Oct '12

--- sh.vahabzadeh(a)gmail.com wrote: From: Shahab Vahabzadeh <sh.vahabzadeh(a)gmail.com> It was TCP and I think it was not a DDoS attack because the traffic was not heavy. ------------------------------- Many/most DoS attacks do not push up the traffic levels considerably. You can see this when looking at packet per second (pps) rates. You may see high pps on the attacked machines, but no correlating large increase in bps traffic rates. scott

1 0

Re: Detection of Rogue Access Points
by Jonathan Rogers 14 Oct '12

14 Oct '12

I should probably mention that we do not have any legitimate wireless devices at these locations. I realize that this complicates matters. The most recent one we found was found exactly like Joe suggested; we were looking at an ARP table for other reasons and found suspicious things (smartphones). --JR On Sun, Oct 14, 2012 at 5:30 PM, Tom Morris <blueneon(a)gmail.com> wrote: > I have used the wigle app as a scanning and direction finding tool.. it > works OK. Not automated really as you'd have to walk and watch the screen > but it works. > > I once walked into a glass wall inside a building while searching for a > rogue AP... FOMP!!!! > On Oct 14, 2012 5:02 PM, "Jonathan Rogers" <quantumfoam(a)gmail.com> wrote: > >> Gentlemen, >> >> An issue has come up in my organization recently with rogue access points. >> So far it has manifested itself two ways: >> >> 1. A WAP that was set up specifically to be transparent and provided >> unprotected wireless access to our network. >> >> 2. A consumer-grade wireless router that was plugged in and "just worked" >> because it got an address from DHCP and then handed out addresses on its >> own little network. >> >> These are at remote sites that are on their own subnets (10.100.x.0/24; >> about 130 of them so far). Each site has a decent Cisco router at the >> demarc that we control. The edge is relatively low-quality managed layer 2 >> switches that we could turn off ports on if we needed to, but we have to >> know where to look, first. >> >> I'm looking for innovative ideas on how to find such a rogue device, >> ideally as soon as it is plugged in to the network. With situation #2 we >> may be able to detect NAT going on that should not be there. Situation #1 >> is much more difficult, although I've seen some research material on how >> frames that originate from 802.11 networks look different from regular >> ethernet frames. Installation of an advanced monitoring device at each >> site >> is not really practical, but we may be able to run some software on a >> Windows PC in each office. One idea put forth was checking for NTP traffic >> that was not going to our authorized NTP server, but NTP isn't necessarily >> turned on by default, especially on consumer-grade hardware. >> >> Any ideas? >> >> Thank you for your time, >> >> Jonathan Rogers >> >

2 1

Is a /48 still the smallest thing you can route independently?
by Jo Rhett 14 Oct '12

14 Oct '12

I've finally convinced $DAYJOB to deploy IPv6. Justification for the IP space is easy, however the truth is that a /64 is more than we need in all locations. However the last I heard was that you can't effectively announce anything smaller than a /48. Is this still true? Is this likely to change in the immediate future, or do I need to ask for a /44? -- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects.

8 8

DNS caches that support partitioning ?
by John Levine 14 Oct '12

14 Oct '12

Are there DNS caches that allow you to partition the cache for subtrees of DNS names? That is, you can say that all entries from say, in-addr.arpa, are limited to 20% of the cache. The application I have in mind is to see if it helps to keep DNSBL traffic, which caches poorly, from pushing other stuff out of the cache, but there are doubtless others. R's, John

19 34