Re: What is going on with my Dialup?

On 2008-07-19, Moe Trin <ibuprofin@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sat, 19 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <slrng828c1.ajo.allergic-to-spam@xxxxxxxxxxxxxxxxxxxxxxx>,
Jim Cochrane wrote:

Moe Trin <ibuprofin@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Bottom line - no servers on your end means only a tiny blip of traffic
as your computer tells the remote "I'm sorry, but the number you dialed
is not in service - CLICK!".

Cannot a firewall be configured to simply ignore any incoming requests,
so that there would be no response at all, instead of saying the
equivalent of "not in service"?

In addition to the regular HOWTOs from then LDP, see

http://www.netfilter.org/documentation/HOWTO/

That's the "default" result when using 'iptables' "DROP" rule. To have
the firewall reject with an ICMP Type 3 Code 3 (Port Unreachable) or
similar, you have to provide an extra rule of "REJECT with". In most
cases, you provide a "default" rule which would be a DROP, but you can
also forward it to an unused port, and have that port provide the
"normal" RST flagged TCP packet.

Thanks, Moe, for the excellent response.

I guess the situation is a lot less black-and-white than one would be
led to believe by using GRC's port test:

https://www.grc.com/x/ne.dll?bh0bkyd2

You're one of those rare persons from whose posts people can actually
gain good, detailed knowledge, rather than just reading opinions with
perhaps a little bit of data to back them up.


Thanks.

There is a huge debate of whether it's better to provide no response
verses the RST or ICMP 3,3. Some feel this makes their computer
invisible, neglecting to note that were their computer non-existent,
the upstream router would normally provide an ICMP Type 3 Code 1 (Host
Unreachable). I've actually seen idiots who configured their firewall
to mimic the 'Host Unreachable' response - I say 'idiots' because the
resulting ICMP error comes from the IP address that is supposedly
unreachable. The lack of response causes the remote computer to make
additional tries - so you aren't saving any bandwidth by silently
discarding unwanted packets. As far as the bad guys are concerned, the
lack of response confirms that the computer does exist, is reachable,
and is using some form of firewall. This _MAY_ attract more attention
compared to the effect of a more normal RST or ICMP 3,3. Your choice.

Others think that by not responding to unwanted packets, they can hide
information about their computer, such as operating system type and
version. See the documentation that comes with the popular 'nmap' tool

[compton ~]$ whatis nmap
nmap (1) - Network exploration tool and security scanner
[compton ~]$

for considerably more details on this technique, and some simple means
of defeating such probes.

There is one situation when it _IS_ desirable to ignore unwanted
packets. This is the case for UDP. Messenger spam (usually messages
that appear to be windoze warning messages, directed to UDP ports 1025
to 1030 or so) are often using spoofed source addresses. Looking at the
IP headers of such packets, there are usually some glaringly obvious
indications that the source is spoofed (such as using IP addresses that
haven't been released by IANA - see that one fairly often). This means
that there is no reason to send a FOAD packet to a non-existent or
innocent host that had nothing to do with the UDP spam.

Finally, there is a case where dropping packets causes you problems.
The most common problem is 'identd' or 'auth' on tcp/113. You connect
to a remote system, and it sends a query to this port - basically
asking "who is your user who is connecting to my port <mumble>?". It
waits until it gets an answer - either a response from the identd that
is running on your system, or a port rejection from the network stack
because you aren't running identd. If you DROP these packets, rather
than rejecting or answering them, you have to wait ten to thirty
seconds for the remote client to time out before your desired
connection goes through. I see this on a number of servers I connect
to on a regular basis. My solution is to have a special rule for
these known servers to this specific port.

The gotcha if you are silently discarding unwanted packets is that you
have to do so for all 65536 ports and all 256 possible protocols (there
is more to the world of IP than TCP, UDP, and ICMP). See the 'nmap'
documentation for a lot more details and concepts.

Old guy


--

.

Relevant Pages

  • Re: What is going on with my Dialup?
    ... also forward it to an unused port, and have that port provide the ... There is a huge debate of whether it's better to provide no response ... The lack of response causes the remote computer to make ... Others think that by not responding to unwanted packets, ...
    (comp.os.linux.networking)
  • Re: UDP port scan results
    ... "A router which sends ICMP Source Quench messages MUST be able to ... So, let's assume you want to scan 64K port, 10 packets a port to try ...
    (Pen-Test)
  • RE: Simple Scan
    ... ping!= information about a particular port. ... The icmp protocol operates at a higher level than a specific tcp or udp ... Think of ICMP as a scooter, udp as a sports car and tcp as a SUV. ... scan networks/hosts that block ping packets. ...
    (Security-Basics)
  • Windows Vista - Unable To Receive ICMP Destination Unreachable - P
    ... I am running into an issue receiving ICMP Destination Unreachable - Port ... Unreachable packets on a raw socket in Windows Vista - SP1. ...
    (microsoft.public.windows.server.networking)
  • Re: kitty.avast.com scanning my ports and internal process trying to access their ip
    ... A port scan often indicates ... >>The ICMP you see is most likely an ICMP port unreachable or host ... attempting to get out to avast, rather there might be some packets ... I've seen nothing in my firewall logs to indicate ...
    (comp.security.firewalls)