Re: NMAP Host Scan picks up private IP's on another network

[Michael Toecker <michael.toecker () gmail com>]

Looks like your ISP has assigned routes within their internal network to
some private address space, and are allowing access to those private
addresses so long as you're a Metrocast customer.

<Speculation>

You are on the 10.X.Y.0/?? subnet, so when you kick off your NMAP scan
for 10.113.63.192, it runs to your default gateway 10.1.1.1 to get the
packet routed.  The next hop in your 10.1.1.1 router for 10.113.63.192
is 10.210.192.1, which I'm guessing is your Metrocast router.

The next hop in your Metrocast router leads you along a merry path, with
each one passing the packet to another one that says it knows where
10.113.63.192 is.  Until you reached 206.53.95.141 that is, which is like
"Oh cool, I'm directly connected to a 10.X.Y.0/?? subnet that contains
10.113.63.192!  I can help you!".

Since it doesn't apparently leave Metrocast, this could be any number of
issues within the internal network of Metrocast.  My bet is that they are
selling private networks to customers, but are minimizing the complexity of
their internal routing to get to those addresses and not blocking those
addresses internally for their own customers.  This is considered a normal
practice, and I know has caused some problems for SCADA operators that
thought they were getting a "private" network, i.e. one that only they can
access.

So yes, this is normal.  You do have a problem though, you think your
firewall is blocking traffic that it's not actually blocking.  If it were
actually blocking traffic from specific IP addresses as you describe, you
wouldn't be getting a valid traceroute back.  Most likely, your firewall is
aware of the pseudo-state of the ICMP packet, and is sending anything it
deems a valid response back to the originating system.  This might also
work for TCP and certain UDP data that originates inside your network and
goes to external IPs as well.

For instance, if you scanned 10.113.63.192 and got back open ports, your
firewall isn't blocking traffic from external IPs when there is an entry in
the TCP state table that shows the connection initiated from within your
internal network. Blocking external IP address that internal users can
access is called egress policy, and it's generally a good idea to block
both ingress and egress to/from private IP ranges at your border.

Happy hunting.

Mike Toecker

On Fri, Oct 16, 2015 at 8:23 AM, Jeffrey G. Gomberg <gomberg () synair com>
wrote:

> What ip block were you scanning? Please post the full nmap command line
> string that you used?
>
> On Oct 14, 2015, at 9:35 AM, Charlie Aquilino <
> Charlie.Aquilino () avianllc com> wrote:
>
> Hello,
>
>
>
> I’m running a host scan via Zenmap and it is picking up 10.x.x.x IP
> addresses on other private networks. Here’s a traceroute for one of those
> IPs:
>
> “C:\Users\admin-charlie>tracert 10.113.63.192
>
>
>
> Tracing route to 10.113.63.192 over a maximum of 30 hops
>
>
>
>   1     1 ms     1 ms     1 ms  10.1.1.1
>
>   2    10 ms    15 ms    10 ms  10.210.192.1
>
>   3    18 ms    11 ms    23 ms  static-216-36-30-138.cpe.metrocast.net
> [216.36.30.138]
>
>   4    38 ms    34 ms    41 ms  static-216-36-30-238.cpe.metrocast.net
> [216.36.30.238]
>
>   5    30 ms    27 ms    26 ms  static-206-53-95-141.cpe.metrocast.net
> [206.53.95.141]
>
>   6    43 ms    35 ms    33 ms  10.113.63.192
>
>
>
> Trace complete.”
>
>
>
> 10.113.63.192 is not on our network. You can see that NMAP seems to leave
> our network, go through some public IP’s of our ISP (MetroCast), and then
> discovers machines behind the ISP’s public IP address. Why is this
> happening? Is there anything I should be concerned about since our firewall
> blocks everything not from a certain few IP addresses?
>
>
>
> Thank you in advance for your help,
>
> Charlie Aquilino
>
> IT Manager
>
> AVIAN LLC
>
>
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
>
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/



-- 

Michael Toecker

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/