2. A query packet sent from a TCP/IP domain resolver to a root server, having the reply bit set instead of the query bit.
3. Any bogus or incorrectly formed packet sent on a network.
4. A person who is bogus or who says bogus things. This was historically the original usage, but has been overtaken by its derivative sense
If you've spent any time responsible for networks you've probably come across Team CYMRU's network bogon lists before. Basically it's a list of source networks which you should never see on the public internet. Either because they were not yet allocated, reserved by IANA for specific uses or were defined and reserved by RFC's that had been adopted as standards.
The Team CYMRU Bogon List is here, http://www.cymru.com/Documents/bogon-list.html
With IPv4 address space exhaustion about to hit most of those bogon networks are fast being allocated. Worse still many previously reserved networks that were never intended to be allocated will be.
I've already had a situation in which despite receiving emails and otherwise maintaining an awareness for new allocations I missed a new allocation before a legitimate customer wound up with an IP in it and tried to use my services. It has become a pain in the ass updating your bogon lists at this point and it makes more sense I think to identify the networks that will continue to be bogons once there is no more IPv4 addresses to allocate. Particularly when you're not a large ISP acting as a transit AS and you already run a very secure network.
My upstream ISP's are fairly good at filtering the bogon sources themselves, and my ingress ACL's are specific enough and the general security of internet facing servers is good enough that even if someone does use an unallocated source IP to attack your network in the immediate future I'm not particularly concerned.
You can rely on your upstream ISP/s to filter them for you, and if you can utilise Team CYMRU's route server you can automate the process of filtering and removing new allocations using BGP. However if you don't have trust your ISP and have no BGP capability, for whatever reason, you may need to statically filter them.
I log at a warning level so that if I do start seeing a lot of invalid traffic I can start to investigate and possibly tell those upstream ISP's that they need to filter it or may have a misconfiguration of some kind.
Wikipedia has a good overview of the current situation with linkage to RFC documents so you can consider for yourself which networks you'd like to filter.
And the below is a self documenting example for PIX/ASA with a group for placing any malicious sources that annoy you enough to block them.
object-group network RFC-1918
network-object 10.0.0.0 255.0.0.0
network-object 172.16.0.0 255.240.0.0
network-object 192.168.0.0 255.255.255.0
object-group network RFC-2544
network-object 198.18.0.0 255.254.0.0
object-group network RFC-3171
network-object 188.8.131.52 184.108.40.206
object-group network RFC-3330
network-object 0.0.0.0 255.0.0.0
network-object 127.0.0.0 255.0.0.0
network-object 169.254.0.0 255.255.0.0
network-object 192.0.2.0 255.255.255.0
object-group network Nasty-Gnomes
description People we don't like.
network-object host x.x.x.x
object-group network Bogons
access-list outside-ACL-Inbound line 1 remark Deny unwanted source hosts
access-list outside-ACL-Inbound line 2 extended deny ip object-group Bogons any log warning