Date: Fri, 6 Oct 1995 15:01:12 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: mbarkah@hemi.com (Ade Barkah) Cc: chuckr@eng.umd.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Fiskars UPS support... Message-ID: <199510062201.PAA02307@phaeton.artisoft.com> In-Reply-To: <199510060622.AAA02872@hemi.com> from "Ade Barkah" at Oct 6, 95 00:22:33 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't find 'privileged ports' in my trusty O'Reillly TCP/IP book, could > > you give me a reference? > > It refers to port numbers below 1024. In Unix systems, only the > super-user can bind a socket to listen to ports < 1024. It is > an "extra" bit of security, but easily defeated if someone has > root priviledges or run a non-Unix operating system on the wire. > > > I just don't see, right now, what would stop someone with a packet > > sniffer, finding how I communicate, then spoofing the remote. > > Authentication is always a problem when dealing with client-server > programs. You need to devise a way for the programs to authenticate > themselves, perhaps by using encryption methods. Popular protocols > use "challenge passwords" to verify that each end is properly > authorized. > > A simple scheme is to have a specific "shutdown password" that is > only sent when a shutdown is necessary, and changes each time > the system is shut down. This scheme defeats packet sniffing > since 1) the password is not normally sent for simple status > checks and 2) when it is sent, it is immediately changed. If we have a monitoring system 'A' and a system that wants to be notified 'B', then: 1) Run a daemon on A that binds a priveldged port. A user written daemon can not bind this port unless system 'A' has had root compromised, in which case you have more problems than graceful shutdowns to worry about. 2) Instead of having 'A' send broadcasts to 'B' (and other boxes that want notification), 'B' connects to the daemon on 'A'. 3) 'A' uses a select to check for exceptional conditions to discard old connections to prevent denial of service attacks. A denial of service attack based on rotorring through a large number of addresses should not be permitted by the firewall. If it is, then your router is vunerable, and you are screwed anyway. 4) When 'A' gets notification of UPS failure, it tells the daemon to send a message to all clients connected to it. Failure modes: 1) Problem: Someone pretends to be 'A' and accepts connections supposed to be bound for 'A'. Soloution: Fire your firewall maintainer; this should not be possible. 2) Problem: Someone connects to 'A' to get failure notification. Solution: You send it. Who cares if they shut down their machine when your UPS warns machine 'A'. 3) Problem: Someone uses the notifications to determine the state of alarm systems at your site to pick an opportune time to break in. Soloution: Don't let machines outside the firewall request notification of power failure. Block the port. Soloution': Verify host addresses in incoming connections via getpeername() and close connections not from machines in a list of allowed machines. No one can "tell 'B' to shutdown"; 'B' can only ask 'A' to tell it, and 'A' is your machine. The only failure modes are someone pretending to be 'A' for an existing connection from 'B' and sending to 'B' or someone completely compromising 'A' (in which case they might as well completely compromise 'B' if they are maintained to similar security standards and the intent is to shutdown 'B'). If you have packet spoofing going on, you need to adjust your sequence determination algorithm to make it unguessable. This will prevent someone from sending a "shutdown" message to a machine that is registered with 'A' via a method that makes it look like 'A' sent it. Spoofing is something you have to fix for the general case anyway. You should also have a firewall so if it happens, it will be someone you can personally kick in the groin instead of someone across the Atlantic from you. > Of course, if someone is packet sniffing your internal organization's > wire, you have bigger problems. Amen. Fire the bugger. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510062201.PAA02307>