Q: Who will be responsible for configuring and maintaining the AMP (OS upgrades, security patches, turning services off, etc.)?
A: WareOnEarth
Communications, Inc., San Diego
will be maintaining the AMP machines. There are so few services enabled, and no
one ever logs into them (except for maintenance) that patches are seldom needed.
The NLANR AMP boxes are still running FreeBSD 3.0. Our DREN ones are a fresh 3.4
BSD. The ONLY network services running on them are:
ssh, syslog,
ntp, discard, netperf/netserver, and testrig/trafficrcv
Q: Who will have the root access on AMP?
A: Only Phil & Cindy do so far, unless the local site wishes it, in which case we give the site root and we use an alternate "amproot". No one can log in over the network as root or amproot, it’s all done with "su".
Q: Are these questions & answers and requirements approved by HPCMO?
A: "You
indeed have ask very good questions, and Phil I believed has provided the proper
answers. This performance measurement is very important and I would appreciate
it being expedited."
-- Rodger Johnson
Q: Will the AMP use Kerberos and SecurID? Or will the AMP have a static password (which by direction of the HPCMO is not allowed)?
A: The only way to log into the machine is via a console (which is normally not even connected) or ssh. In addition, we normally use AllowHosts to restrict the hosts that can connect via ssh: our server machine and some local site addresses if the site desires it. [And our sshd doesn’t use RSAREF] We chose not put them in an HPC Kerberos realm at this time because it just seemed like that much more complexity (shared secrets) and more software to maintain (potential bugs). If someone insisted on hardware auth to access the AMP box we could implement such a solution, but I would rather not.
Q: If WP security scans or an ST&E team or an SAV team finds security problems with the AMP, who gets nailed - the site or a remote maintainer?
A: I would assume us (WareOnEarth Communications, Inc. San Diego), but I think you had better get a program office decision on that one.
Q: The security folks don’t think it’s a good idea to put a device on our network that we don’t control. (Yet, even if we are given control, the Integration contractor [Nichols] still needs to agree to accept control.)
A: We give each site the option of having accounts and root on their own AMP machine. It is entirely up to you. There should be nothing on the system of interest that isn’t also accessible via the central web server. There is no user data being stored or processed of any kind. In fact, the entire AMP disk image (dd) can be downloaded by anyone from a public web address, and we can reload an entire system at any time by using that image (the local site has to stick in a special floppy and reboot). No other DoD/HPC systems trust the AMP boxes in any way, so breaking into an AMP box gets you almost nothing. And I suggest that the AMP box be put on it’s own switched network segment if possible so it would not be capable of snooping other network traffic.
Q: The security folks also want to reserve the right to take the AMP off the network at their discretion in case of security emergencies.
A: Of course.
Q: They’re worried about being held accountable for a device they don’t control. (I still want the AMP, but I don’t mess with the security guys...)
A: Accountability is an issue we should resolve.
Q: On another issue: I’m still researching the WP (88th Communications Group) GPS clock, but here’s what I’ve found out... The clock has two serial output ports on it. Each serial port is connected to a serial port on a Sun server. (Two Sun servers in all.) So the clock itself doesn’t have an IP address. Since the Sun servers sit behind the base firewalls, we will need to request that the firewall policy be changed to permit you ntp access to them. (This could be a political problem.)
A: Okay, that explains how you got two stratum-1’s from one clock.
Q: You mentioned the possibility of the MSRC hosting it’s own clock. Some folks here like that idea, though the security folks are still thinking about the security ramifications. Does the HPCMP have an available clock? If not, how much does a typical GPS clock setup cost? Can the dish antenna already on the roof serve two clocks?
A: SPAWAR has one "extra" (or so I’ve been told). If we had to buy another I would have to look up the cost. Unfortunately, I think you would have to run another antenna. Often GPS antennas are active and differ from box to box.
Q: In your formula for the theoretical min delays, I assume the 0.66 must be the velocity of propagation of light through glass fiber. Is that right?
A: Yes, that’s what I’ve been able to find anyway. It turns out that in round trip time, the delay is very close to 1 msec per 100 km!
Q: Security: It appears from what I can read that access to the AMP box is via non-kerberized SSH. Is this correct? Our security administrator points out that it is in conflict with HPC policy to have hosts on MSRC networks with local, non-root passwords. If kerberos were used, this would take care of this concern. How have other MSRCs and the program office dealt with this issue?
A: Rodger Johnson has approved our use of ssh for this application because these are not "hosts", i.e. they do not accept HPC user logins, and they do not store or process HPC user data of any kind.
Q: Facilities: The unit as a whole is not UL listed that we can determine. No UL label anywhere on the box. This is a problem for our facilities manager who has a local requirement that we only install UL listed equipment on the computer room floor. Any comments?
A: These units are custom assembled for us from parts. Whether or not the parts are UL listed or not I have no idea, but it wouldn’t surprise me if e.g. generic PC power supplies weren’t. Certainly the "system" as a whole isn’t (since it was a custom build).
Q: What type of network activity should I expect to see on the AMP machine?
A: Expect to see a lot of traceroutes and pings. The AMP machine has a list of destinations (currently 86), mostly on DREN. Every minute it sends one ping packet to each of the 86. Every ten minutes it does a traceroute to each of the 86. There will also be incomming pings and traceroutes from the other DREN AMP machines.
You will also see TCP connections between your AMP system and port 1090 on sd.wareonearth.com. That is being used to transfer the test results back to the central server/ web system.
Q: Why do you run the discard service?
A: Discard is just there so that you can e.g. ttcp into it as a throughput test. It’s not very important but seemed harmless to leave it there. We also run a netperf server for a similar reason.
Q: Is the AMP system Y2K compliant?
A: FreeBSD 3.4 claims to be 100% Y2K compliant: http://www.freebsd.org/y2kbug.html
As for the software we have added, UCSD make a few Y2K changes (which we applied) to the AMP software. And of course we have tested the software after Y2K and it is all working properly.
Q: Can we put in an ICMP filter list for the AMP system?
A: Is it unacceptable to put this machine on its own switched network port (recommended anyway to combat potential sniffing) and allow that port unrestricted ICMP access? The reason is because there are pings and traceroutes, both inbound and outbound, to a list of about 85 IP addresses currently. And that list changes pretty often, especially now while we are installing new systems. Maintaining such a filter list seems like more trouble than it’s worth to me.
Q: We block inbound ping (icmp echo) at our DMZ router. Will this have an impact on other AMP machine’s abilities to gather data? Outbound echo and echo replies are allowed.
A: Yes. The AMP system does both inbound and outbound pings and traceroutes. What we have suggested is putting the AMP system on its own switched network port (to also avoid potential snooping) and allow open access on that port. Since this is probably behind your DMZ router, you may have to punch a hole for it there. You are also welcome to put it in front of your DMZ, i.e. treat it as a DREN device. Up to you.
Q: Is discard critical? ARL blocks outbound discard from Aberdeen to DREN. The block covers outbound discard tcp/udp, source and destination ports. This matches the outbound ANSOC filters at most Army sites.
A: ASC asked about discard also, because they normally disable it. The only reason it is there is so you can do trivial throughput tests, e.g. ttcp into the discard port. If fact, I think that’s what Mike Muuss says he does in his tests to Ft. Belvoir (if so, he must be bypassing your block via his ATM path). It seemed harmless to me to leave it on, and since I know a few people use it for network testing, I left it on (e.g. Andy Germain of NASA does his throughput tests to discard). AMP will function without it, so it’s not critical, but if you will permit an exception for the AMP box it would be nice if they were all the same. [But if the exception is going to impact your router performance, then don’t bother.]
Q: What ports are netperf/netserver and testrig/trafficrcv?
A:
The netperf netserver process listens on tcp port 12865.
The testrig trafficrcv process listens on tcp
port 56117.