|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
In-Reply-To: <003101cd6a17$3f81ddc0$be859940$@iname.com> Date: Tue, 24 Jul 2012 23:10:52 -0500 From: Jimmy Hess <mysidia@gmail.com> To: Frank Bulk <frnkblk@iname.com> Cc: nanog@nanog.org Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org On 7/24/12, Frank Bulk <frnkblk@iname.com> wrote: > Unfortunately I don't have packet captures of any of the attacks, so I > can't exam them for more detail, but wondering if there was some collective > wisdom about blocking port 0. It should be relatively safe to drop (non-fragment) packets to/from port 0. If I recall correctly, there are some routers that perform a "helpful" numeric value validation when the human is entering port numbers for access list rules, that _do_ forward port 0 traffic, and through some sort of oversight by the router/firewall vendor actually _prevent_ the administrator from selecting port 0 in a deny rule, eg. "Port to deny must be a number from 1 to 65535". TCP/UDP port 0 is technically a legal port, but it's also a reserved port, and very unusual for it to be used on the network for any legitimate purpose. Various firewalls will discard anything TCP/UDP sent to/from port 0. Many TCP/UDP sockets implementations won't even let an application select port 0. bind() to port 0 is treated as a signal that the application wants the sockets API to pick a high-numbered ephemeral port. > Regards, > Frank -- -JH
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |