It's not too hard to detect network scans with a sufficient level of network monitoring. Scanning typically shows up as a rapid flurry of network packets from a single source to a sequence of IP addresses and often also a sequence of TCP and UDP ports on each host. The most basic scanning method is to send ICMP "Echo request" packets to a series of hosts to see which ones reply. It's also possible to send TCP or UDP packets and look for characteristic responses (SYN gets SYN+ACK or RST in reply, a TCP or UDP packet to an unused port generates ICMP "Port unreachable" replies, etc). Intensive port scanning can also generate quite noticeable network traffic from the source of the scan.
Packet filtering (and similarly, firewalls or NAT devices) can defend against scans, if it is possible to filter all traffic going to a set of hosts from most destinations. In many cases this isn't entirely feasible; for example, if you have a need to let a TCP UDP protocol through to a network, then a scan can find the ports you are permitting and thereby indicate the presence of those hosts.
Using packet filtering in an attempt to block scans is no substitute for closing vulnerable services, however. If any one host permits the service that is being scanned for and is vulnerable to an exploit for that service, and it has unrestricted permission to talk to other hosts in your network, then its compromise exposes the other hosts. As another example, laptops infected with the SQL/Slammer worm would wake up inside corporate networks and begin spewing Slammer packets, promptly infecting the unpatched systems inside, even though the network was blocking the Slammer packets at its border.