Archives of the TeradataForum

Message Posted: Mon, 08 Dec 2003 @ 16:30:09 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Hello-

Coming from not so much a DBA perspective, but more of an SA, there are some things you need to be mindful of...

Teradata systems of more than one node use a lot of administrative tools that rely on the "r" services (rsh, rexec, rlogin). NCR is working on ssh from what I understand, but it is neither available from them nor supported from what I last saw. The machines running the database also run a few networks, each unto itself. The bynet, used for the query parsing and other high speed interconnect types of things is one, there is also the PLAN, and the SLAN, both used for systems admin functions (talk to consoles, talk to machines and distribute software to the nodes). Along with that, many installs will have a number of cops (network interfaces) that are used to access the database engine. Sadly, NCRhas really let MP-RAS go, it's not gotten teh attention that many other OSes have for security, and it has some quirky ways of managing services in the first place.

You'll want to know about tcpconfig and the sdf file, these are teh bane of your existence, and will remain so until MP-RAS goes away. tcpconfig is a shell script that interfaces (bbs style) to config your network hardware and services, then writes these changes to the sdf file (referenced at each restart, so a change in ifconfig is NOT permanent (like it is in some other unix(c)es). and any changes in inetd.conf do NOT stick around for a reboot either, you have to change the services under tcpconfig, and you cna change it in /etc/inetd.conf for on-the-fly changes, but for it to remain after a restart, you need to run tcpconfig.

hosts also resides in both /etc/hosts and /etc/inet/hosts, mine have always been a soft link, so they are sync'd, but I have seen one case where they were separate files (don't ask how that happened).

What I'm relaly getting at here is that you have to run the "r" services to use a lot of the tools (xpsh, psh, and rallsh), and you have some very quirky ways of dealing with them to get it config'd correctly. Along with that, most of the releases of the daemons and such are old enough that they may be susceptible to some attaacks that they should not be (although NCR did release the fix for sendmail a bit ago). The boxes typically come with copious amounts of services enabled, and the ones needed to run the box are dangerous. Since most of the teradata machines that are out there are warehouses, and most of that data is VERY private and confidential, they nearly always reside within a firewall/secure environment. However, most incidents with security are from within the "secured" network, meaning that either someone came into the building, or an employee decided to do something they shouldn't (that employee may even have legitimate access to the system). Consider also Wireless networking and signal leakage, and you have pretty much an open invite to have a good try at the company data warehouse from the parking lot.

My opinion, FWIW, is to take your cops and lock them either behind a firewall or a proxy or at least a good hardware load balancer and remove the services from the general network that just don't need to be there. If NCR had a more updated inetd (like xinetd) you might be able to manage services on an interface basis, but since this isn't happeneing, I'd look to exterior security if that's what you feel you need. Your company firewall can keep exterior threats out, but it can't do much for interior threats. If you have an IDS, I'd look at writing some signatures relating to the cops and the ports that should be seen for the majority of traffic, and alarm anything that isn't within the teradata port (1500, if memory serves).

Thanks for listening, sorry for the rant, have a good day....

loadc

	<Prev	Next>		<<First	<Prev	Next>	Last>>