Public IP’s for switch, best practices?

pwjohnston

Recently I have been doing work for a client of ours who has Public IP’s attached to their Catalyst 2960’s. Now each office has a Cisco router in place and we can get into those via the WAN, but every other Cisco installation I’ve done work for, and it has not been many, usually will allow you to SSH into the router from the WAN and then you can SSH into the switch from there.

So, is there ever a good reason to attach a public IP to an internal switch or were these set up wrong? I’m going to guess it was set up wrong since all the management, routers, and switches, connect over public IP Telnet with no VPN…

Qord

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

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.

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.

Qord

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.

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.

SteveO86

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.

MentholMoose

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.

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.

dustinmurphy

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.

Either way, to me... it's a security risk if you have Telnet/ssh open to the world... even on routers...

As SteveO86 said... at least add an access-group to the vty lines to limit the availability to the internet. Personally, I do not allow ANY vty access to my routers/switches/firewalls unless you are inside the network.

Forsaken_GA

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.

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.

dustinmurphy

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.

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.

I have no problem assigning public IPs to routers... since many times it's necessary... HOWEVER... I do not allow management through WAN links. One must access them from the inside. (I always setup VPN connections, so that if I'm not at location, I have a private IP)

dustinmurphy

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 assume that they are not using any type of security above the passwords/secret as he has not said that they do.

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

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.

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

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.

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. Personally, I use static logins (I use RADIUS for VPN access, but that's only for convenience for my users)... I admin small networks with only a few sites, connected via VPN. I keep my firewalls at the edge of the network with the public addressing and my routers all are internally addressed and admin'd. If I have to be at a remote location, I use VPN to connect to the network and do not allow unnecessary access. I also don't leave RDP open to the world... nor do I leave Telnet/SSH open to the world. There is no good reason to.... and there is a good reason to keep it secure (see brute force attacks)

As I said before... if you're going to leave telnet/ssh open to the world... secure it. Personally, I don't do it... and see it as a security risk that I'm not going to take.

Telling someone that it's "fine" to leave administration/management ports open without understanding the other security measures they've taken is rather stupid... and careless. Unless stated, I assume that they have the most basic of configurations and will offer my advice based on that. 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.

Forsaken_GA

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.

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.

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.

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.

You, on the other hand, decided to go for the scare tactic. To paraphrase your initial response, 'don't do it, your network will get AIDS'.

Forsaken_GA

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.

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

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.

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.

I stated my opinion based on what was asked. I still feel that it's unnecessary in most situations to open unnecessary ports and have administration/management interfaces open to the public, regardless of "other" security measures. BUT.. I also say that in security, we have to sometimes make concessions. We HAVE to open ports at times. If that's the case, make sure you have other security measures in place.

Perhaps I made a snap judgement based on my experiences and feelings about security. I will be the first to admit that I am fairly new to the Cisco game. I don't know all there is to know... and from the appearance, you have more experience than I do... so maybe I don't have all the answers 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)

BTW - I also didn't say "this is what you should do, period"... I said that "PERSONALLY.... I feel it's an unsafe practice and wouldn't do it... but that's just me" I also said that "IF you are going to open it to the WAN side, protect it" That, in no way said that "this is what you should do, period".

dustinmurphy

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.

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

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.

I'm not making any assumption in answering a question. If a person doesn't have the prerequisite knowledge to understand the answer they've been given, it is their responsibility to either do some research, ask follow up questions, or remain ignorant. What they do or do not know doesn't really effect my answer.

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)

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

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.

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!

dustinmurphy

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.

Well, in your words... 'it depends'

There are many different uses of a network. There are many different topologies as well. Different networks provide different services and require different approaches. I agree that it's not all black and white. I never said it was. Some networks utilize internal services only and access to the outside world is to just use the internet and do not require any outside traffic to come in. Other networks provide services that require outside access to come inside. In those situations, you make concessions (as I've said) and allow the traffic to come in, but you protect your network devices in other ways.

There are other ways to configure remote administration without making it available to the world. Locking the necessary doors is important to safety. Leaving a door open to the world is inviting ANYONE in. In my opinion, it's not necessary in most situations to allow outside access to the management/administration of core devices. Do you leave the doors open to the public in your datacenter that houses the servers? I don't. (and if you're SOX compliant, I highly doubt you do). I have a locked door to my server rooms. I limit the access to only people who need it. Do I leave my fire safe on my front porch? Nope. I don't. I also don't leave my network open to outside influences, if I can help it.

Forsaken_GA

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

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!

Understood, and I do not like spreading misinformation, either. (which is why I accepted the correction) I don't think that telling someone that keeping your internal network internal is a bad thing. I don't think that telling someone that opening unnecessary ports (especially management/administration ports) creates a security risk is "misinformation". I DO think that telling someone that it's safe to open ports to the outside and allow anyone to access your core network is definitely risky... and I would be careful... only for the fact that they may misread it... and not understand that other security measures are necessary to mitigate the risk.

Let me ask you this... assuming that it's a small company in a Windows domain and no secondary authentication method with only a few remote employees ...which would you consider "safer":

A) Use a VPN for connecting to a company terminal server from the outside
Open port 3389 to the internal server to the outside world

dustinmurphy

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.

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.

Forsaken_GA

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.

We're one of the largest ISP's in the united states... we are *very* interconnected (to the point that, a couple weeks ago, a fiber cut took out about 500 gigs worth of bandwidth for about 30 hours... didn't interrupt our service at all). We're so distributed that there really isn't a main site. We have large aggregation points in all the major IX's, but the majority of our links are our own fiber, or leased fiber.

MentholMoose

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.

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.

dustinmurphy

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.

Well, I learned something... so, now I understand what you were talking about. I have always used the firewall as the connection point for public IP's.... I usually give the firewall the public IP and assign an internal IP to my hosts.... and NAT everything (in and out). I've always had more simple topologies, though.... never thought about using the firewall as more of a router, without NAT.

pwjohnston

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.

Heero

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.

You can close it off to the world with a firewall the same way NAT would close it off to the world...Just wait until IPv6! Then what will we all do, everything will have public IP addresses!

dustinmurphy

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.

Yeah, I think I'd be OK with that as well. If I was your boss, I'd warn them of the possibilities if they do not secure their stuff.

That picture is HORRIBLE... although I *HAVE* seen worse. I used to work for a small ISP, back in 1999. Their "network" closet for one of their satellite offices was a bunch of 5-12 port switches daisy chained together. It was HORRIBLE. I didn't know it back then, but thinking back... wow.