Safely Experimenting With Sockets

Question

I'm learning about TCP/IP and (Berkeley/UNIX) socket programming. Let's say I have two scenarios:

1) I write two programs in C, a client and a server, and bind them each to a non-well-known port on the same (Linux) host, and experiment with exchanging data using my (novice) C skills.

2) I run the server on the Linux and run the client from a Windows that is on the same LAN (behind NAT). I think this means that the port on the Windows is "active open"? (Note that I don't yet know anything about WinSock or getting around NAT.)

In each of these cases, is it conceivable that some bot could scan for open ports while one or both of the programs are running behind NAT? If so, is there a way for an attacker to see the source of the custom programs I'm running and exploit misused pointers, do buffer overruns, etc.? This is a home network, and there's no reason that anyone would target it specifically.

Answer 1

I already had bots connect to my applications when experimenting with client/server applications (only on well-known ports, though). However, the abuse potential is small. Bots which connect to random hosts usually first try to fingerprint what application is running (which will fail because nobody knows your application exists) and then run known exploits against that application (they won't know any for an application they have never seen).

If you want to be more careful (or just get rid of the noise), you can configure your router to disable port forwarding for your server application. That way it can only be reached from the local LAN.

If you want to be really careful, use virtualization software to run client and server on virtual machines which communicate through a virtual network.

If you want to be totally crazy paranoid careful, disconnect both client and server from the internet and have them communicate on an airgapped wired LAN.

Regarding your question "is there a way for an attacker to see the source of the custom programs I'm running": Did you intentionally write a program which responds with its own code to certain network messages (i.e. a networked quine)? If not, an unintentional bug which causes this to happen is quite unlikely, especially when you consider that C programs usually don't have access to their own code anymore after they are compiled. A buffer overrun vulnerability which dumps parts of the compiled code of the application is conceivable, but the attacker would have to invest quite a lot of work to reverse-engineer it and find more exploits. And I doubt anyone would bother to invest that much work to pwn a test program by a learner who might never even run it again.