|
I’m not sure if this is the right thread but it's the closest I've found and I figure all the smart cisco people hang out here, so here it goes. I have a cisco docsis modem that's affected by this vulnerability and my ISP refuses to acknowledge the problem or do anything about it: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/ciscosa-20140716-cm http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3306 Obviously the vulnerability is very serious but I don't have the option of changing the provider. From what I can tell the modem itself has no open ports on the WAN and the webinterface is only available via LAN on the modems internal address. If I drop all packets to the modem from the LAN then it should be impossible to access the webinterface from the LAN and I should be safe because the exploit requires access to the webserver. Is that correct? Would you guys feel safe enough with this workaround? I don't really see any other options.
|
#
?
Jan 1, 2015 13:47
|
|
|
|
| # ? Apr 17, 2024 00:43 |
|
|
That sounds right to me. You could also hardcode a bad mac address for the ip address of your modem / gateway.
|
|
#
?
Jan 2, 2015 23:48
|
|
|
Ninja Rope posted:Can I ask what your use case is for doing IPS on that much traffic? One of the largest school districts in the country. A few hundred thousand users.
|
|
#
?
Jan 3, 2015 03:34
|
|
|
eames posted:I have a cisco docsis modem that's affected by this vulnerability and my ISP refuses to acknowledge the problem or do anything about it: Serve it up in a scary suggestion to your local media? Causing a PR issue is pretty much the only way it'll get looked at. Channel 5 freaking out "One easy trick for HACKERS to take control of your Comcast Wifi!" is pretty much the only thing you can do other than switching ISPs. less than three fucked around with this message at 08:51 on Jan 5, 2015 |
|
#
?
Jan 5, 2015 08:49
|
|
|
Not a Cisco question specifically, but an enterprise networking question and I couldn't think of a better thread. I work for an ISP and designed their DWDM platform. It uses 40 channel passive muxes to make a ring between 4 sites. I recommended EDFAs at the start but management didn't want to use them - now we have a customer wanting to have a passive wave between 2 non-adjacent sites (so spanning 2 legs), requiring us to patch through mux-mux at the site in the middle. Because of this, management are looking at amplifiers again. Each leg looks like this: Input -- Mux -- Dark fibre -- Mux -- Output In reality, more along the lines of: Input -- Mux -- Patching tray -- ODF -- Dark fibre -- ODF -- Patching tray -- Mux -- Output Where the muxes have 5.8dB insertion loss, loss on the dark fibre is <2.5dB. Based on this, I figured a rough guide for loss on one leg would be in the order of 17dB. Obviously I've said we should be using appropriate gain amplifiers on each leg, but they only want to put them on one for now. My boss is wanting to amplify only one leg to deliver this, but I am interested to know the downsides. On the face of it it looks like it'd work - putting a 20dB amplifier in one leg resulting in 20dB reduction in loss - however I'm interested to know what problems there's likely to be, and any things we may not have thought of if anyone can comment please?
|
|
#
?
Jan 8, 2015 14:30
|
|
|
Anjow posted:Not a Cisco question specifically, but an enterprise networking question and I couldn't think of a better thread. EDFAs mean balancing your power levels so you don't drown out adjacent signals, so you probably need a transponder at the hub site where you were goring to patch through unless your optics can deal with the insertion loss. You need to ensure all the channels coming in in that leg (assuming you're pre-amp'ing) are coming in low enough to not overload the amp or receiver as well (you pre-amp the receive to bring the incoming channels all up to a uniform -3/0/+3 level so they'll match the new channels you're inserting at that node. Tl;dr if you're not dealing with an inter-city network with spans in the range of 15dB or more of loss, you probably don't need amplifiers, and you should just put a transponder at the hub site to regen.
|
|
#
?
Jan 8, 2015 17:49
|
|
|
I'm working on a project to bring in two Nexus 3172s, which I'm hoping to connect together in a vPC, and two 4500X's, that I'm hoping to stack with VSS. Question is, the interconnect between the 3172s and the 4500Xs, what's the best practice? A single port channel with 4 10g member links? Is it just standard LACP? I'm a little in the dark on the possible configurations between a Nexus vPC and VSS. Any insight would be appreciated.
|
|
#
?
Jan 8, 2015 20:41
|
|
|
jwh posted:I'm working on a project to bring in two Nexus 3172s, which I'm hoping to connect together in a vPC, and two 4500X's, that I'm hoping to stack with VSS. VSS is treated as a single switch, so it would be a single LACP port-channel with connections to each Nexus and each 4500-X. On the Nexus, it's a vPC link. Here is a 4500-X config: code:code:http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11_589890.html madsushi fucked around with this message at 21:26 on Jan 8, 2015 |
|
#
?
Jan 8, 2015 21:24
|
|
|
Excellent, thank you so much!
|
|
#
?
Jan 8, 2015 22:05
|
|
|
I realize that this isn't a Cisco question, but does anyone have experience with Huawei CloudEngine switches? They're about half the price of comparative switches, and networking is kind of their thing, I just wonder if they're total crap, or if they're worthwhile.
|
|
#
?
Jan 8, 2015 23:43
|
|
|
Giving Huawei money is literally supporting the theft of American IP.
|
|
#
?
Jan 9, 2015 13:13
|
|
|
ragzilla posted:EDFAs mean balancing your power levels so you don't drown out adjacent signals, so you probably need a transponder at the hub site where you were goring to patch through unless your optics can deal with the insertion loss. You need to ensure all the channels coming in in that leg (assuming you're pre-amp'ing) are coming in low enough to not overload the amp or receiver as well (you pre-amp the receive to bring the incoming channels all up to a uniform -3/0/+3 level so they'll match the new channels you're inserting at that node. Thanks very much for this. I understand what you're getting at with the transponder, and I initially suggested this as it would allow us to offer passive services handed off at 1310nm, but they were not keen due to the cost. In terms of the cost, we've had 17dB EDFAs quoted at £2,100 and 20dB at £3,200 - the issue now is that if we end up wanting to have lots of services that span 2 legs, we have to buy 4 optics for each service, which could get quite expensive. Are you able to elaborate on overloading the amp/receiver please? I understand that the amp may have min/max input power levels so I've enquired with the manufacturer about this, but what effects could too high power levels have on the adjacent services? I have not come across this before, it's all a learning experience for me - I'm just the guy who knows most about it in this company. Also I'm aware of MRV for transponders, but are there any other recommended manufacturers?
|
|
#
?
Jan 12, 2015 15:04
|
|
|
FatCow posted:Giving Huawei money is literally supporting the theft of American IP. Also there is a very high likelihood that you'd be installing a backdoor into your network.
|
|
#
?
Jan 12, 2015 15:10
|
|
|
Anjow posted:Thanks very much for this. I understand what you're getting at with the transponder, and I initially suggested this as it would allow us to offer passive services handed off at 1310nm, but they were not keen due to the cost. In terms of the cost, we've had 17dB EDFAs quoted at £2,100 and 20dB at £3,200 - the issue now is that if we end up wanting to have lots of services that span 2 legs, we have to buy 4 optics for each service, which could get quite expensive. RAS covers the problem briefly in his NANOG presentation (p 59-60), but I'm having a hard time finding other resources on channel balancing. From what I recall in training (Infinera ATN) it mainly causes issues with crosstalk, raises the noise floor on adjacent channels (reducing OSNR), and will result in uneven channel amplification (amplifiers are naturally uneven across the spectrum, and typically use gain equalizing filters to get consistent per-channel gain, and unbalanced channels will cause issues with those filters). Transition also make transponders, anyone that makes media converters are pretty much set up to make transponders. The way I could see you making use of amplifiers (assuming the ring is sufficiently small) would be something like (assuming muxes are at the hub site): MUX - PREAMP - OADM - ... - OADM - PREAMP - MUX Having pre-amps in incoming directions at the hub site will ensure all your entering channels are at a consistent power level (ideally +0) coming into the hub site, which ensures you can reinject them into the network at +0 -filter drop loss (so maybe around -3 to -5 so you can get 15-25dB out of the ring including OADMs assuming you're using a 20-30dB pre-amp). Then you ensure all your signals you add there are padded to that same insertion power (not too big an issue if you're not going to amp any of those signals, but always balance or you'll regret it later). Then at all the OADMs you measure the optical power (ideally with an OSA, but if you know your channels are balanced, and how many channels you have passing through, you can do it with a light meter and some math) and note the OADM pass-through channel power so when you insert there you can pad down to that value (this is the important one to balance since both directions from the OADM will hit your pre-amps and you'll get the aforementioned cross talk and gain equalization issues). If you need more than 15-25dB in the ring you pick a site on the opposite side of the ring and give it a pair of pre-amps as well, everything in-between gets the same treatment.
|
|
#
?
Jan 12, 2015 22:47
|
|
|
Slickdrac posted:Also there is a very high likelihood that you'd be installing a backdoor into your network. http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/  I think this will always be a concern, no matter where you buy your hardware from.
|
|
#
?
Jan 12, 2015 23:08
|
|
|
Methanar posted:http://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa-upgrade-factory-show-cisco-router-getting-implant/ The difference is that Cisco isn't installing that stuff at their factories. EDIT: That's the concern here, not saying categorically that Huawei are doing that. Inspector_666 fucked around with this message at 23:22 on Jan 12, 2015 |
|
#
?
Jan 12, 2015 23:19
|
|
|
Does it really matter who puts in the backdoor though? The problem is that you have a backdoor, whether it was put there by the US government, the Chinese government, or the manufacture.
|
|
#
?
Jan 12, 2015 23:25
|
|
|
Methanar posted:Does it really matter who puts in the backdoor though? Well yes, because the assumption is that it comes from the Chinese government with every single Huawei device, whereas TAO isn't intercepting every single Cisco/Juniper device.
|
|
#
?
Jan 12, 2015 23:33
|
|
|
Inspector_666 posted:Well yes, because the assumption is that it comes from the Chinese government with every single Huawei device, whereas TAO isn't intercepting every single Cisco/Juniper device. There is a lot of work being done to prevent this as well. Older hardware is an easier target for this sort of thing. When that got released to the public there were a lot of folks at Cisco that had a poo poo fit and are working to make it better.
|
|
#
?
Jan 13, 2015 19:55
|
|
|
Re Huawei, I think enough time has passed that I'm ok with posting this hilarity http://falz.net/static/huawei-typo-2014.jpg They did fix it the day before the tradeshow started (a large US tradeshow in Vegas)
|
|
#
?
Jan 14, 2015 21:44
|
|
|
I've got a cisco short question. I've configured an IPSec remote access VPN connection on one of our newer ASAs, replacing the super old VPN concentrator they were previously using. SSLVPN is up and working fine. The IPSec push came because a lot of the employees don't want to install AnyConnect and use the SSLVPN, or they don't want to install the prereqs for AnyConnect. The issue I'm currently having is that they would like the IPSec VPN connection to push DNS search suffixes to the client, without needing to modify the client settings. The desired functionality is that the user does not need to use FQDN when trying to access things over the connection. Most of the stuff I've googled so far is people having issues with split-tunnel, or people having my issue and the responders assuming it is an issue with split-tunnel. This is a non-split-tunnel connection for compliance reasons, all DNS requests are being routed through the tunnel, they just aren't resolving without the FQDN. It is my (somewhat limited) understanding that DNS search suffixes are 100% a client setting so I assumed that the ASA would have little or no control over this due to the variables involved with a given client's networking stack. I've come across two possible solutions but they seem iffy at best so I wanted to run them by someone with potentially more experience first. First, apparently I can set a comma delimited list of values in the RADIUS attribute IPSec-Default-Domain. All the cisco documentation I can find about this attribute seems to indicate otherwise, however. Second, apparently if I configure a separate DHCP server and assign the client IP Address that way, the DHCP server can push search suffixes for me? I didn't know this was a thing.
|
|
#
?
Jan 15, 2015 22:21
|
|
|
DHCP assigns the search suffixes for you. For the reasons you're finding I massively prefer VPNs that come with a client because then there's something at the other end to configure the endpoint, and you can do split tunnelling without having to manually add routes. But yes, if you're doing DHCP over the VPN then that should be able to push a suffix for you, as well as the DNS servers.
|
|
#
?
Jan 15, 2015 22:30
|
|
|
group-policy foo attributes dns-server value <dns.ip> default-domain value my.domain.local should do the trick for you.
|
|
#
?
Jan 15, 2015 22:33
|
|
|
That would do the trick for me, except I need to be able to do: default-domain value domain.1 domain.2 domain.3 Looks like I'll have set up DHCP for this or convince the end users to use FQDNs. 
|
|
#
?
Jan 16, 2015 00:21
|
|
|
You can have one primary suffix and then a list of others. I think it's option 119 or something.
|
|
#
?
Jan 16, 2015 00:29
|
|
|
Sorry for non-Cisco, but since there's no other general enterprise networking thread: does anyone happen to know how to do a manual failover in a Vyatta cluster?
|
|
#
?
Jan 16, 2015 05:51
|
|
|
Reiz posted:That would do the trick for me, except I need to be able to do: I had to look this up a while back, just put them all there, comma separated. That *should* work.
|
|
#
?
Jan 16, 2015 17:21
|
|
|
Reiz posted:I've got a cisco short question. Also be aware that with the ipsec model you've chosen, it is impossible to prevent savvy users (users that can google) from turning on split-tunneling on their side. You say it's for compliance only, so you are fine, but don't actually expect any sort of enforcement mechanism and make sure you shut down anyone who requests something like that.
|
|
#
?
Jan 16, 2015 21:28
|
|
|
Am I correct in that 2960 switches do not support EEM? 
|
|
#
?
Jan 26, 2015 22:47
|
|
|
Hey friends, nat question. I am currently not NAT'ing for a DMZ that I admin. We've got a /24 of public IP space. Our upstream firewall blocks basically everything that isn't on a list of a few standard ports. I have a synology NAS that seems to only want to host its management web page on port 5000. There doesn't seem to be a good way to change this on the device itself, and most of the recommendations seem to point to port forwarding, which makes since for a consumer NAS. My NAT'ing is a little rusty, so my question is this. Can I static NAT for a single IP address, solely for doing a 80 -> 5000 translation, without affecting non-NAT traffic for any other device? Or will all other traffic attempt to NAT itself once I add a nat rule? This is on an ASA 5520.
|
|
#
?
Jan 28, 2015 20:08
|
|
|
sudo rm -rf posted:Hey friends, nat question. Yes, this is definitely do able.
|
|
#
?
Jan 28, 2015 22:10
|
|
|
Yep. 1:1 NAT your public host to a private host of your choice, configure the private host on the NAS management interface, TCP 80 outside, 5000 inside, build the inbound access rule and you're good to go.
|
|
#
?
Jan 28, 2015 23:33
|
|
|
Okay, route redistribution has been kicking my rear end for so long I tried to tab complete the word redistribution. I have OSPF running for the two clusters and on rtr-lan 4. I have eigrp running in the yellow box and on rtr-lan 4. What is the proper way of redistributing the routes that lead off to the clusters to my eigrp AS. If it means anything I have all of the eigrp 13 AS being aggregated when being advertised to rtr-lan 4. Ultimately, I want the bottom PCs to be able to access resources within the clusters. If it matters here are the running configs and routing tables for the 2 important devices. http://pastebin.com/bvX1F4RJ rtr a http://pastebin.com/X8rFj2Rv rtr lan 
Methanar fucked around with this message at 03:34 on Jan 30, 2015 |
|
#
?
Jan 30, 2015 03:29
|
|
|
On your border routers between protocols redistribute your routes into the protocol of choice. These will come in as external routes and have a different AD to prevent loops. I generally like to restrict what I'm redistributing with a prefix list or route map. Route maps are nice because you can make adjustments on the fly, assign tags, etc. to have further control.
|
|
#
?
Jan 30, 2015 09:02
|
|
|
The most important thing to avoid with redistribution is relearning a route redistributed into another protocol back into the original protocol. This leads to all sorts of interesting race conditions. The easiest way to do this is via route-maps/tags.
|
|
#
?
Jan 30, 2015 16:56
|
|
|
Any nerds in this thread at NANOG63?
|
|
#
?
Feb 2, 2015 23:58
|
|
|
One of these years I'll actually make it to a NANOG meeting.
|
|
#
?
Feb 3, 2015 06:00
|
|
|
I was at the last one in Baltimore. Pretty sure they are streaming the meetings now anyway.
|
|
#
?
Feb 3, 2015 12:54
|
|
|
falz posted:Any nerds in this thread at NANOG63? Hi inignot posted:I was at the last one in Baltimore. Pretty sure they are streaming the meetings now anyway. The streaming was hosed up yesterday not sure if it was fixed today. Either way the talks should be going up on youtube now.
|
|
#
?
Feb 4, 2015 02:26
|
|
|
|
| # ? Apr 17, 2024 00:43 |
|
|
I tried watching the stream yesterday morning (2/3) and it was a wreck. I gave up after a while.
|
|
#
?
Feb 4, 2015 13:43
|
|