Not to be rude but where do I begin.
First of all SSH is encrypted but TACACS is not (TACACS+ is). Secondly why would
you ever allow syslog, snmp, or tacacs into your internal network from the
outside world or even a DMZ (I will get to SSH in a second)? It shouldn’t
be allowed period. If you need to allow any of these it should be done over a
site to site vpn IPSec tunnel or some sort of encrypted tunneling if you are
managing devices outside your LAN. So you should not be allowing these in
through your firewall to be begin with, without tunneling them, and then on top
of that any syslog, snmp polling or trap servers, or ACS (TACACS servers)
should be on a DMZ regardless.
You say SNMP “might” provide
infrastructure information. From just saying this you are inviting people to
do a trace route to tevausa.com to see the hops into your network then do an
snmpwalk on your core router(s). Then by this statement I am sure you only
have the default public or private community strings (which I really hope is
not the case) configured (even if you did set these they can be easily brute
forced), by which then someone could tell you routers to pass there configs to
them using snmp set. From there on you will be owned. This is only an example
of what bad things could happen if allow snmp inbound (not only to your
networking equipment but to any snmp enabled device) so don’t do it.
Now that I hopefully have explained why
you shouldn’t allow these services in anyways I will let you know why you
should have a DMZ (which I really hope you already have if you are hosting any
public available services such as a web server). A DMZ by design is to
segregate these devices/services from your internal network because obviously
they are more open to attack and potentially being compromised. So if they
were on you internal LAN and were compromised then they will be used as a
launching point for further attacks. At this point you will be having a very
bad day.
“but I fail to see how a DMZ proxy makes this
activity more secure given that information from the DMZ to the firewall would
not be encrypted. “ Huh? Im sorry but why would you even
say this as encryption between the firewall and DMZ has no relevance.
The only thing that is comprehensible from
email is possibly SSH which I still don’t agree with, so now onto SSH.
SSH shouldn’t be allowed as this should only be done via your LAN (specifically
a an ADMIN VLAN or better yet an OOB connection) or over an IPSec tunnel. Yes
its encrypted once the tunnel from the client to the server has been built but
why should you allow anyone to attempt to make this connection externally? It’s
a recipe for disaster. So even if you filter by source IP then there is the
potential to be spoofed and then if you are running an older version of SSH
that is vulnerable to a remote exploit you are sunk.
In summation to this there is no need for
these services coming into your network unless it is over an encrypted tunnel.
Hope this helps.
From: firewall-wizards-bounces@listserv.cybertrust.com
[mailto:firewall-wizards-bounces@listserv.cybertrust.com] On Behalf Of Alan.Freiman@tevausa.com
Sent: Monday, October 30, 2006
6:11 PM
To:
firewall-wizards@listserv.icsalabs.com
Subject: [fw-wiz] Communication
Device Protocols from External router directthrough Firewall
I am trying to determine the risks of allowing the
following protocols from my external routers directly through to my internal
LAN versus setting up a DMZ proxy:
SNMP
(polling / traps) Syslog, SSH, Tacacs, and Netflow
I
know that SNMP and Netflow might provide infrastructure information, but I fail
to see how a DMZ proxy makes this activity more secure given that information
from the DMZ to the firewall would not be encrypted.
Furthermore,
SSH and Tacacs are already fully encrypted.
Any
advice would be appreciated.
Thanks!
Alan
This message is intended solely for the designated recipient(s). It may contain
confidential or proprietary information and may be subject to attorney-client
privilege or other confidentiality protections. If you are not a designated
recipient you may not review, copy or distribute this message.
If you receive this in error, please notify the sender by reply e-mail
and delete this message. Thank you.