February 2013 - Test - lists.nanog.org

Re: NYT covers China cyberthreat
by Scott Weeks 20 Feb '13

20 Feb '13

--- calin.chiorean(a)secdisk.net wrote: From: "calin.chiorean" <calin.chiorean(a)secdisk.net> IMO, if we stick to the document and they are organized in military style, then a person who collect information, should focus only on that particular phase. That person is an operator, he or she should not be keep busy remembering long CLI commands. The scope is to deliver ASAP. ----------------------------------------- What's that randy says? >;-) I can only hope you're right, but my point was to bring suspicion to the report itself for (possibly; I'm only on page 19) saying that m$ is the only attacking OS. -------------------------------------- No matter how much I like CLI and to put my fingers into text mode, I have to admit that point and click in windows is an easier and faster method to achieve the task I did mention. As Warren mention, --------------------------------------- bzzzzzt. Wrong answer. Please study more. Next! scott

1 0

Re: NYT covers China cyberthreat
by Scott Weeks 20 Feb '13

20 Feb '13

--- calin.chiorean(a)secdisk.net wrote: From: "calin.chiorean" <calin.chiorean(a)secdisk.net> <snipped> :: when all tools are available for windows os, you just have to compile them. <sniped out the rest> ------------------------------------------------- They're not all available for m$. scott ---- On Wed, 20 Feb 2013 09:02:35 +0100 Scott Weeks wrote ---- >Be sure to read the source: > >intelreport.mandiant.com/Mandiant_APT1_Report.pdf > >I'm only part way through, but I find it hard to believe that >only micro$loth computers are used as the attack OS. Maybe I >haven't gotten far enough through report to find the part >where they use the *nix boxes?

3 4

bidirectional fiber inline amps.
by Eric J Esslinger 20 Feb '13

20 Feb '13

Due to some bundle size restrictions, we are looking at converting some runs over to use bi-directional fiber sfp's (the Cisco version is GLC-BX-D/GLC-BX-U). However a couple of our runs are farther than the spec 6.2 miles. Is anyone aware of a vendor that makes an inline bidirectional amp for this sort of application? I did some digging but either they do not exist or my google fu is weak today. __________________________ Eric Esslinger Information Services Manager - Fayetteville Public Utilities http://www.fpu-tn.com/ (931)433-1522 ext 165 This message may contain confidential and/or proprietary information and is intended for the person/entity to whom it was originally addressed. Any use by others is strictly prohibited.

3 3

Re: switch 10G standalone TOR, core to DC
by Piotr 20 Feb '13

20 Feb '13

W dniu 2013-01-30 12:59, Ingo Flaschberger pisze: > Am 30.01.2013 11:30, schrieb Piotr: >> 2. >> Hp 5900 af 48xg >> large buffer options - configurable buffers >> gpl 30k$ > small: Memory and processor > 512 MB flash, 2 GB SDRAM; packet buffer size: 9 MB > > http://h17007.www1.hp.com/us/en/products/switches/HP_5900_Switch_Series/ind… > Tab models > small in 5900 series: High-performance 10 GbE switching — cut-through and nonblocking architecture delivers industry-leading low latency (~1 microsecond) and very demanding enterprise applications; the switch delivers a 1.28 Tbps switching capacity and 952.32 Mpps packet forwarding rate in addition to incorporating 9 MB of packet buffers or big in 5920: High-performance 10GbE switching — enables you to scale your server-edge 10GbE ToR deployments with 24 high-density 10GbE ports delivered in a 1RU design; delivers a 480 Gbps (357.12 Mpps) switching capacity in addition to incorporating 3.6 GB of packet buffers Ultra-deep packet buffering — provides up to a 3.6 GB packet buffer to reduce network congestion at the I/O that is associated with the heavy use of server virtualization, as well as bursty multimedia, storage applications, and other critical services http://h17007.www1.hp.com/us/en/products/switches/HP_5920_Switch_Series/ind…

7 7

Check this out Review LG Spirit 4G for MetroPCS on Phone Scoop
by Jay Ashworth 20 Feb '13

20 Feb '13

Check this out: http://www.phonescoop.com/articles/article.php?a=11938 This email was sent via Phone Scoop (www.phonescoop.com) The sender thought you might be interested in the page linked above.

1 0

RE: Endpoint Security and Smartphones
by Naslund, Steve 19 Feb '13

19 Feb '13

Well, I guess it all goes back to my original assumption that unless you control physical access to the device there really is no security. Unless someone can prove to me that the pass code is a part of a cryptographically secure system (which is unlikely given the key length of the passcode) that guards the entire file system of the device, then it is nothing more than a lock to keep kids out and prevent butt dialing. This is no different than losing physical control of your laptop computer or desktop machine. Unless you have implemented some of the most draconian security measures including full file system encryption with a removable key store (like a smartcard or such), loss of the physical device is game over in most cases. I think this attack might have value if aimed at a single individual target with a high value reason for needing access to the phone (think CIA going after a high value target). To write an app that randomly grabs pass codes from the general public is a lot less useful because the pass code does nothing for me without the physical device. I still cannot figure out the practical value of this is other than demonstrate that having all of these sensors on your person is a security threat. Steve -----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Tuesday, February 19, 2013 10:41 AM To: Naslund, Steve Subject: Re: Endpoint Security and Smartphones ----- Original Message ----- > From: "Steve Naslund" <SNaslund(a)medline.com> > My knowledge on mobile device security is pretty limited. I am just > trying to wrap my head around the value of your passcode. I suppose it > would be good to know if I could get covert access to the device > itself so I could see what is on it. I would however have to get some > malicious code on the device to get the passcode so it would seem to > be easier to put malicious code on your device that sends me whatever > I need the passcode to access in the first place. I guess one of my > thoughts on computer security in general is that if someone gets > physical access to the device, it is history. I would not count on the > passcode to be very protective because it would seem that there would > be some kind of way around it through the hardware vendor, maybe not > but someone would have to convince me that a backdoor does not exist. Well, certainly it's stored on there, but the received wisdom is that it is somewhere where apps not granted superuser by the user can't reach it, so a "normal" trojan couldn't get to it. It is, of course, in the FBI's best interest to lie about whether they can break this sort of security... But in fact, the point of the pass-swipe is that no, physical access is not enough -- as long as you're not the "disassemble the device and put the flash memory on a scanning-tunnelling microscope" class of attacker; there probably really are uses for this attack. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

Endpoint Security and Smartphones
by Jay Ashworth 19 Feb '13

19 Feb '13

Some time back, the FBI was heard to say in public that draw-your-passpattern security, as seen on Android smartphones and tablets, was too much for them, at least as long as you kept your screen clean of skin oil. :-) Whether or not that's true, there are apparently ways to attack even that, using just the sensors on the platform. Specifically, the accelerometers (which are actually usually just angle sensors): http://www.schneier.com/blog/archives/2013/02/guessing_smart.html If you're responsible for security, BTW (and if you're on NANOG, you probably are), Bruce Schneier should be on your daily bookmark list... even if you think he's full of crap. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

3 3

RE: Endpoint Security and Smartphones
by Naslund, Steve 19 Feb '13

19 Feb '13

My knowledge on mobile device security is pretty limited. I am just trying to wrap my head around the value of your passcode. I suppose it would be good to know if I could get covert access to the device itself so I could see what is on it. I would however have to get some malicious code on the device to get the passcode so it would seem to be easier to put malicious code on your device that sends me whatever I need the passcode to access in the first place. I guess one of my thoughts on computer security in general is that if someone gets physical access to the device, it is history. I would not count on the passcode to be very protective because it would seem that there would be some kind of way around it through the hardware vendor, maybe not but someone would have to convince me that a backdoor does not exist. Steven Naslund -----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Tuesday, February 19, 2013 10:22 AM To: Naslund, Steve Subject: Re: Endpoint Security and Smartphones ----- Original Message ----- > From: "Steve Naslund" <SNaslund(a)medline.com> > Kind of seems to me that if I am deep enough in your mobile device to > get your accelerometer data, I probably can get access to your stored > data in the device. The only reason I think I would want your passcode > would be to physically steal your device and then try to use it. > > This is one of those attacks that is probably possible but not > practical. Interesting blog however. I dunno, Steve; think "trojan horse". -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 0

regarding 188.24.168.0/21
by Mihai Necsa 19 Feb '13

19 Feb '13

Hi list Any help will be appreciated, it seems that apple is filtering prefixes for untraceable reasons I wrote emails to Apple-NOC(a)apple.com droot(a)apple.com but no answer. Staring about 2 weeks ago we encountered several complaints from our customers which are using 188.24.168.0/21. The prefix is allocated to our residential customers, dynamically via pppoe. Actually they are not able to connect AppStore and associated resources like developer.apple.com from their IOS terminal phones or tablets, nor using iTunes or browser from their respective operating systems. Using tcpdump we saw that 17.154.66.17 is not responding to client request. IP 188.27.253.245.63289 > 17.154.66.17.443: tcp 0 Furthermore we did manage to ping hosts from 188.24.168.0/21 using a looking glass server (4.69.185.226) from LEVEL3 San Jose which seems to be last hop provider to apple network. Ping results from San Jose, CA to 188.27.248.26(188-27-248-26.rdsnet.ro) icmp_seq=0 time=188 ms ---- statistics ---- 1 packets transmitted, 1 packets received, 0% packet loss rtt min/avg/median/max/mdev/stddev = 188/188/188/188/0/0 ms Regards, -- Mihai NECSA network engineer @AS8708

1 0

VOA - Voice of America English News
by jra＠baylink.com 19 Feb '13

19 Feb '13

Jay Ashworth has sent you an article from VOAnews.com: http://www.voanews.com/content/skorea-says-nkorean-leadership-wont-be-convi…

2 1