Slashdot Mirror
Skip The IP Address
j0hnyb1423 writes "Have you ever wanted to be able to connect to that stackless Snort or Hogwash box without walking over to it and plugging in a monitor and keyboard? Well, at last here's your answer - noiptun. Yes, it requires an IP stack to be compiled into the kernel but no IP addresses necessary on the real interface(s). And if stealth IDS setups aren't your bag, then you can at least use it to browse /. without having an IP bound to your linux workstation."
Whats to stop an attacker connecting through the tunnel to the noip'd box?
The box itself will stop such traffic (only if it's a known exploit though). The bad traffic usually comes from outside. The management and this tunnel is supposed to connect from the internal network. The problem with such bridging boxes is, they either don't have an IP address and are only administratable via the console or configurable via booting/floppy/CD, or they have another interface with a secure network to administer. Switches usually have a dedicated network for their administration. In the latter case, the box has an IP address. In all cases, administration is not supposed to be done via an in-band network connection.
The whole point of this noiptun is to get rid of this extra interface which is usually needed to do some kind of administration.
is NOT broadcasting an IP address. You're safe, please move along.
the machine running the client is usually assumed to be running on a bridge interface with no IP of its own. As such it won't be discarding any packets. As far as the naming scheme for client/server, there is actually a good reason why the IP-less side is running the client while the end connecting to it is called the server. When the project began, the idea was to be able to use one "server" to connect to many clients, this functionality isn't currently there and there is at the moment only a one-to-one possible relationship, but the naming scheme makes sense viewed from that angle.
What?
The end that sits there passively waiting for someone to connect is called the "client", and the end you run when you want to talk is called the "server".
That's not how X works, nor is the terminology backwards. In X, the resource that's being served is the terminal (the display and input devices). The server sits around waiting for the clients (applications) to connect to it.
The problem is that you think server means remote and client means local, and that's just wrong; it's actually about who is providing resources and who is consuming them.