you do not need to know the source ports for filtering outgoing connections.
(i usually use "shorewall" as a nice and handy wrapper around iptables and a "reject everything else policy" when i configured everything as i wanted. so i only occasionally use iptables directly, if my examples dont work, i simply might be wrong with the exact syntax)
something like:
iptables -I OUTPUT -p tcp --dport 22 -j REJECT
should prevent all new tcp connection TO ssh ports on other servers when initiated locally (the forward chain is again another story)
so ...
one could run an http/s proxy under a specific user account, block all outgoing connections except those of that proxy (i.e. squid)
then every program that wants to connect somewhere using direct ip connections would have to use that proxy.
better try this first on a VM on your workstation, not your server in a datacenter:
"-I" inserts at the beginning, so that the second -I actually becomes the first rule in that chain allowing tcp for the linux user named "squiduser" while the very next would be the reject everything rule.
here i also assume "squiduser" exists, and hope i recall the syntax for owner match correctly.
then create user accounts within squid for all applications (that support using proxies) with precise acl's to where (the fqdn's) these squid-users are allowed to connect to.
there are possibilities to intercept regular tcp/http connections and "force" them to go through the http proxy, but if it comes to https and not-already-known domains the programs would connect to, things become way more complicated (search for "ssl interception") like the client program/system needs to trust "your own" CA first.
so the concept is to disallow everything by iptables, then allow more finegrained by http proxy where the proxy users would have to authenticate first. this way your weather desktop applet may connect to w.foreca.st if configured, but not e.vili.sh as that would not be included in its users acl.
this setup, would not prevent everything applications could do to connect to the outside world: a local configured email server could probably be abused or even DNS would still be available to evil applications to "transmit" data to their home servers, but thats a different story and abuse of your resolver or forwarder, not the tcp stack then. there exists a library to tunnel tcp streams through dns requests and their answers, a bit creepy, but possible and already prepaired. and only using a http-only proxy does not prevent tcp streams like ssh, i think a simple tcp-through-http-proxy-tunnel software was called "corckscrew" or similar and would go straight through a http proxy but would need the other ond of the tunnel software to be up and running.
much could be abused by malicious software if they get executed on your computer, but in general preventing simple outgoing connections is possible and more or less easy depending on what you want to achieve