Another good reason to stop using telnet (Major hack against Solaris)

Haven't really seen anything like that before. Sounds like it could be useful to test the status of a DNS through batch processes though.I can think of a number of ways to have a shell script query the DSP, and take actions based on what might be going on.

Indeed, I would think this approach could provide an excellent means of status monitoring. Since it requires minimal overhead, it would be resistant to denial-of-service attacks.

Assuming that there's a 16-byte status report that changes at most a few times a second, and that the system keeps a 16-bit counter for how many times it's changed, one could query the status by sending (abcdefghijklmnopqrstabcdefghijklmnopqrstabcd). A lowercase "a" would get translated into the first digit of the counter, "b" into the second digit, "e" the first character of the status report, "f" the second, etc. The server would return three copies of the counter and two copies of the report. If the first two copies of the counter match, the report between them will be valid. Otherwise if the second two copies of the counter match, that report should be good.

This style of server, while it's extremely lightweight on the host side, is not terribly efficient in network traffic utilization. The client sends a packet to the host, and the host sends a packet with the same data to the client but does not acknowledge receipt of the data. The client then acks the data from the host, and the host bounces the ack back to the client.

A little messy, but the beauty of the system is that when a packet comes in the host simply examines it, munges it a little, sends it out, and forgets about it. If the packet gets dropped en route to the client, that will result in the client's not hearing a reply it was expecting. The client will then re-send its packet, and the host will re-send its reply.

If you're confident that the shell presented (i.e., the BBS software) is reasonably secure, it's not horribly different from non-ssl passwords on websites (which are also an abomination IMO).

I wouldn't put any sensitive data on a computer open to the net that is running telnetd.

As for packet sniffing for passwords being easier on non-ssl websites, that might well be true if you don't have very sophisticated sniffing tools. I'm pretty sure that with wireshark, (i.e. tcpdump), you can tell it to show "sessions" where a dialogue between two systems is highlighted, making the login pretty much stand out almost as well.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.