Compare cert salaries and plan your next career move
Qord wrote: » If they've got the IP's to spare, why not? We use public IP's for everything. Every interface and subint has it's own public IP.
dustinmurphy wrote: » Because that opens up the switch/router to the world, if they're allowing telnet/SSH on the WAN side. Personally, I think this is a VERY unsafe practice.... and a good way to get hacked... but that's just me.
SteveO86 wrote: » If you can justify it and need it, secure it. Assign and access-group to the vty lines, TACACS for AAA, SSH/Disable Telnet, proper timeouts. etc.
Qord wrote: » Depends on what the acceptable level of risk is I suppose... I should have added more detail. Where I work, the routers are open to the wan, but the switches are not. Have to be on the same subnet as the switch to ssh to the switch. We either ssh to the local router, and telnet from there or VPN in, RDP to a machine, then telnet to the devices.
MentholMoose wrote: » Exactly. A device having a public IP address is not much of a security risk (if at all) since it can be secured by a firewall or other means (ACLs, etc.). In the future when we are all using IPv6, everything can have a public IP which is fine as long as the device is secured properly.
Forsaken_GA wrote: » Stop believing everything you read, and apply a little bit of brain power to it. It's a perfectly safe practice if you've taken care to do some proper security steps. I have absolutely no problem with network gear being accessible via the WAN provided that the logins aren't static. Ie, use an RSA token or something of the like. That way even if your local box *was* infected, the credentials are absolutely worthless unless they've managed to acquire your seeds and/or your token. This makes it fine to even use telnet for a management protocol. Damn paranoid security feebs.
I do apply brain power... which is why I don't leave an unnecessary open hole in my equipment. You're assuming that people put RSA tokens on stuff... you're giving too much credit to people... not everyone understands how to setup RSA tokens, etc... and are allowing open, unsecured access to their equipment.... taking unnecessary security risks.
Forsaken_GA wrote: » Sometimes you do not have the luxury of accessing everything through local addressing, particularly when there are a crap ton of remote sites. Making blanket statements like no ssh or telnet over the WAN and its an unsafe practice and a good way to get hacked is security alarmism. There are plenty of people out there who *do* understand how to deploy an RSA server and hook things like your RADIUS and TACACS server into it, two-factor authentication isn't exactly a niche market. Hell I can get it on my World of Warcraft account! So yes, allowing telnet or ssh access over the WAN with static or default passwords? Colossal stupidity. Allowing telnet or ssh access over the WAN from only select IP ranges, regardless of password policy? Depends on how limited the scope is. If it's from one particular network (your ops guys), sure, go ahead and use static logins. If it's from multiple sites, then static logins are still dumb. Allowing telnet or ssh over the WAN when you're using non-static login information? Very, very miniscule chance of getting hacked, it will generally require events which are not feasible to forsee, and beyond your control. Unfortunately, security folk have a tendancy to only focus on the first scenario, and assume it's the state of the industry. It's not. I have no problem with the 'shut everything out!!' mentality if you're teaching or discussing intro to security or intro to networking. It's better to encourage paranoia in the initiates and let them figure out down the road where they can afford to ease up a little. As an answer to a general question? Uh uh, that black and white militant security crap doesn't fly with me. Network security has many many many shades of grey.
dustinmurphy wrote: » Don't you think that if he was working with two-factor authentication, he would have said that? Don't you think that if he's asking this sort of a question, that maybe he's not experienced enough to configure these other security measures? You assume that EVERYONE uses two-factor authentication or non-static logins, when in fact... many smaller environments don't. Not everyone works with networks that have thousands of hosts... at hundreds or thousands of sites. Those that do... probably aren't asking if it's safe to have a public IP on a switch... they would already know the answer for themselves. I would assume that one asking this question without already knowing the answer is not as familiar with different configurations, and therefore probably uses static passwords and no ACL's to control access.
If someone takes your blind advice... and gets brute forced... YOU are the jerk that gave them that bogus information... I'd rather err on the safe side.. and give someone information that will protect them from being compromised... because it's likely that if they're asking this type of question... they do not have the proper security measures in place.
dustinmurphy wrote: » Unless you're running a transparent firewall... assigning a public IP to a device goes around the firewall.... and if you're allowing Telnet/ssh through the firewall... and not limiting it to certain IP's... you're opening up your devices to be compromised.
Forsaken_GA wrote: » Here's the difference - I make no assumptions, and you do. I take the question at face value, and the answer to whether it's ok to publicly address management ports on network gear is, as with almost every question in the network world, 'it depends.' You didn't come back with the various options and scenarios under which it is or isn't ok to do so. You just pulled out the standard infosec partyline to shut it all down. I understand why, it's the quick and easy answer, especially in the face of perceived newbism. I don't feel it's appropriate to answer a question for knowledge with 'this is the way you should do it, period.' If you're going to properly educate someone, give them all the options and then let them make their own choice. The short 'this is the way it's done' type of answers are why we have to put up with stupid myths like you should never use autonegotiation and propagates the creation of techs instead of engineers. I suggest you read again. At no point did I give blind advice that would lead to a compromise. I offered my opinion on the subject at hand, *and* I qualified it. I did not say, nor give the implication, that management should be accessible without doing the due dilligence, all I said was don't press the panic button without a damn good reason.
Forsaken_GA wrote: » Yeah, no. You need to go back to network design class. Lets say I have three boxes, PE1 - CEFW - CE1 PE1 = Provider Edge Router = 11.0.0.1/30 CEFW = Customer Edge Firewall = Provider facing interface = 11.0.0.2/30 Internal facing interface = 11.1.1.1/30 CE1 = Customer Edge Router = 11.1.1.2/30 Topology = PE1 <-> CEFW <-> CE1 All of these boxes are using public IP's. In order for someone on the PE network to get to CE1, they have to traverse the firewall via the 11.0.0.0/30 link, since 11.0.0.2 is the next-hop to 11.1.1.2. You think CEFW can't deploy an ACL on it's provider facing port saying 'don't accept telnet or ssh traffic destined for 11.1.1.2'? A public IP address does *not* make a device less secure, nor does it circumvent a firewall that's not in transparent mode. It all depends on how you've designed your traffic flows. What I think you really mean is that once you put a device on a public IP address, it's no longer as secure, because it's no longer behind the NAT... and we've already had that conversation. If that is your line of thought, you've just demonstrated the classic mistake most people make of getting NAT confused with a stateful firewall.
dustinmurphy wrote: » You make assumptions that people understand what static logins are... how to harden a device... and how to configure RSA tokens and two-factor authentication.
BUT... I use common sense... and common sense says that opening anything to the public makes it available to anyone to do what they will. You use your two-factor authentication and have a sense of "security" ... great. I'd rather close and lock my doors. If it's not available to the outside world, it's MUCH more difficult to compromise. (note: I did not say IMPOSSIBLE to compromise... just more difficult)
dustinmurphy wrote: » I stand corrected. I've just added a new topology to my repertoire, as I generally use static NAT through my firewall to assign public IP's to internal servers. As I said... I'm somewhat new... and don't know it all.
Forsaken_GA wrote: » Well let me ask you this: What is the purpose of a network? Once you've figured that out, ask yourself how well the network fulfills that purpose when the doors are locked up tight. As I said, network security is not a black and white proposition.
Forsaken_GA wrote: » That's fine, and I'm not trying to bust your balls just to be a dick... believe it or not, TechExams tends to rank pretty well in the Google search results, so I'm a bit asinine when it comes to making sure correct information gets out. The better the body of knowledge available to the inexperienced, the less f'ed up crap I have to deal with in real life!
Forsaken_GA wrote: » Now, as far as my own opinions go on management addressing.. It depends on the scale of the network. Right now, my area of responsibility includes over 2000 sites, with anywhere from 5 to 100 pieces of network gear at each site. While we certainly could deploy IPSEC tunnels or some other method to keep management interfaces on private addressing, that's an incredible amount of administrative overhead. Adding that many tunnels and that many DNS entries inevitably involves human failures, and when you need to go manage a piece of gear due to a service affecting outage is NOT the time to find out that the tunnel is screwed up, or DNS never got updated. In that scenario, it's much better to just deploy an ACL allowing management traffic to the public IP's from select networks, though with a non-static login backend, that's not really necessary. It's an acceptable amount of administrative overhead for some prudent action, but I'd be just as comfortable without it. The reason we *do* deploy those kind of ACL's is because we have backdoor logins that are static, but are only active if the authentication backend is unavailable. For a small site, I wouldn't allow any management traffic over the WAN. I'd allow ssh into a couple of bastion boxes (personal preference of OpenBSD, you deploy at least two for redundancy purposes and to allow maintenance on one box or the other without interrupting management ability) and only allow those boxes to ssh/telnet into the network gear for management purposes. For a datacenter (especially a multi-tenant one), assuming I had gear to support it, all of the management interfaces would be in their own VRF, and as above, only a couple boxes would be dual-homed to the publicly accessible portions of the network and the VRF, in order to ensure there was no possible way customer or public traffic could hit the management interfaces. It all depends on the nature of the network and the traffic and what your risk analysis dictates. It'd be nice if there was a silver bullet, but there ain't, and if there was, InfoSec wouldn't be a hot job field at the moment.
dustinmurphy wrote: » I agree with this entire statement. I would also like to add that in your large environment, it also depends on how interconnected the sites are. In all of my environments, we used internal services between the sites. (they were smaller sites with 5-50 users... and only 3-5 sites ) We used VPN to connect all sites to the main datacenter... for other environments that require interconnected networks, there's always MPLS.
MentholMoose wrote: » At my last job we had a /16 so we could (and for the most part did) assign a public IP to almost everything. The firewalls were not in bridge/transparent mode and not doing NAT, so it was like Forsaken_GA's topology example.
pwjohnston wrote: » Interesting read guys. Sorry I didn’t get a chance to reply sooner. Ya, no access lists, no tacacs or radius, just plain old telnet to a wan ip. I thought the set up was crap, but if you saw the server closet these guys use, it would fit. Attached a pic from one of their offices. Our boss says we’re not doing work for them anymore and I’m ok with that.
Compare salaries for top cybersecurity certifications. Free download for TechExams community.
