nmap 113/auth on shorewall

I'm curious about some output I'm seeing from nmap. I've shutdown
all ports on the rhel4u3 system and configured shorewall on it with
nothing opened in reverse. However nmap states:

(The 1659 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
113/tcp closed auth

If I comment out my rules file top to bottom, same output. The policy
file doesn't have anything specific to 113 and is the generic two
interface sample.

Why the difference for auth/113 port? It's not listed anywhere in
/etc/shorewall so why is being reported differently?

Don

It's likely that your ISP is restricting traffic on this port so while
the remote host may have nothing configured for that specific port,
nmap doesn't know that, it just knows that 113 is closed something
along the pipeline.


dshesnicky@yahoo.com wrote:
> I'm curious about some output I'm seeing from nmap. I've shutdown
> all ports on the rhel4u3 system and configured shorewall on it with
> nothing opened in reverse. However nmap states:
>
> (The 1659 ports scanned but not shown below are in state: filtered)
> PORT STATE SERVICE
> 113/tcp closed auth
>
> If I comment out my rules file top to bottom, same output. The policy
> file doesn't have anything specific to 113 and is the generic two
> interface sample.
>
> Why the difference for auth/113 port? It's not listed anywhere in
> /etc/shorewall so why is being reported differently?
>
> Don

On 13 Jun 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1150228534.281344.223090@p79g2000cwp.googlegroups .com>, dshesnicky@yahoo.com
wrote:

>(The 1659 ports scanned but not shown below are in state: filtered)

"filtered" - not impressed

>113/tcp closed auth

OK - good idea if any user application is run from here - the remote server
won't wait 30-90 seconds for a 113/tcp request to time out.

>If I comment out my rules file top to bottom, same output.

The assumption is that you are running nmap from some remote location. The
most likely answer is your upstream is blocking the port for you. Many
windoze users have "personal firewalls" that ignore (DROP) incoming packets
because they think it makes them invisible (having no understanding of the
traceroute outputs), and then whine at the ISP for a slow response from
sites that want to use RFC1413 Ident.

To check this scenario, use a packet sniffer on the remote system you
are running nmap on, and look at the headers of ICMP error packet that
indicates the port is closed. Pay particular attention to the TTL and
flags. Compare that response with a legitimate ICMP error generated by
your system when the firewall is not in "stealth" mode.

Old guy

> The assumption is that you are running nmap from some remote location.

Nope, was running on a local network before I rolled it out so nothing
was blocked:

PORT STATE SERVICE
113/tcp closed auth

why is state filtered bad?

Don

On 15.06.2006, dshesnicky@yahoo.com <dshesnicky@yahoo.com> wrote:
>
>> The assumption is that you are running nmap from some remote location.
>
> Nope, was running on a local network before I rolled it out so nothing
> was blocked:
>
> PORT STATE SERVICE
> 113/tcp closed auth
>
> why is state filtered bad?

Do you use IRC or FTP?

--
Feel free to correct my English
Stanislaw Klekot

> >(The 1659 ports scanned but not shown below are in state: filtered)
>
> "filtered" - not impressed

>From the nmap docs:

The state is either open, filtered, closed, or unfiltered. Open
means that an application on the target machine is listening
for connections/packets on that port. Filtered means that a
firewall, filter, or other network obstacle is blocking the port
so that Nmap cannot tell whether it is open or closed.
Closed ports have no application listening on them, though
they could open up at any time. Ports are classified as
unfiltered when they are responsive to Nmap's probes, but
Nmap cannot determine whether they are open or closed.
Nmap reports the state combinations open|filtered and
closed|filtered when it cannot determine which of the two
states describe a port.

- Old Guy Too

>
> Do you use IRC or FTP?

I'm not doing anything to the net from the
firewall. All connections are through the firewall
and all connections to the firewall have
to come from inside the network ie. loc in
Shorewall terms.

Don

Have you tried these proceedures?

user@someotheroutsidehost1:$ sudo nmap -sS your.fire.wall.box
user@someotheroutsidehost1:$ telnet your.fire.wall.box 113

user@someotheroutsidehost2:$ sudo nmap -sS your.fire.wall.box
user@someotheroutsidehost2:$ telnet your.fire.wall.box 113

How does 113 look from other networks?

user@yourfirewallbox:$ sudo nmap -sS 127.0.0.1
user@yourfirewallbox:$ sudo nmap -sS your.firewalls.outside.ip

Is port 113 still in state closed from the localhost's perspective?

Finally:

user@yourfirewallbox:$ sudo /sbin/iptables -F
user@remotehost:$ sudo nmap -sS your.fire.wall.box

Is 113 still closed?



dshesnicky@yahoo.com wrote:
> >
> > Do you use IRC or FTP?
>
> I'm not doing anything to the net from the
> firewall. All connections are through the firewall
> and all connections to the firewall have
> to come from inside the network ie. loc in
> Shorewall terms.
>
> Don

On 16.06.2006, dshesnicky@yahoo.com <dshesnicky@yahoo.com> wrote:
>
>>
>> Do you use IRC or FTP?
>
> I'm not doing anything to the net from the
> firewall.

I didn't ask if you use any service from firewall. I asked if you use
IRC or FTP _anywhere_.

--
Feel free to correct my English
Stanislaw Klekot

On 15 Jun 2006, in the Usenet newsgroup comp.os.linux.security, in article
<1150400187.407676.116840@y41g2000cwy.googlegroups .com>, dshesnicky@yahoo.com
wrote:

>>> (The 1659 ports scanned but not shown below are in state: filtered)
>
>> "filtered" - not impressed

>From the nmap docs:

I'm aware of them. As hinted in my reply above, "filtered" is the
most common configuration of the windoze "personal firewalls" because
the user has no concept of what networking looks like, and is relying
on really bad advise from the likes of Steve Gibson. The argument of
'filtered verses closed' has been going on for years, with neither
side able to convince the other of the merits of their concept.

The perimeter firewall where I work (and the one in my home) are set
to drop (ignore) incoming UDP packets that don't match up with a
previous outgoing, because UDP is truly connectionless, and (especially
for windoze messenger spam) the claimed source address is often spoofed.
Sending anything back is thus a waste of time and bandwidth. (At work,
we port-shift _outgoing_ UDP out of the _source_ range 1024 - ~1075, so
there is no legitimate reply traffic to those ports. This allows our
upstream to silently discard all inbound traffic to those ports - presto,
no windoze messenger spam wasting bandwidth.) Because TCP requires a
three-way handshake before data can flow, it's not very easy to spoof
the source address, and thus a RST (or ICMP type 3 of some flavor) is
likely to reduce bandwidth waste, compared to ignoring the incoming
packet and the subsequent retries.

All other inbound traffic is filtered such as to drop unrelated ICMP,
and reject unrelated TCP and all other protocols. This is done on the
perimeter router.

The whole world knows an address exists. If there isn't a working computer
at that address, the upstream would have sent a Type 3 Code 1 plainly
saying so (unless it is blocked even further upstream).

Old guy