simon
Guest
|
 Posted:
Tue Jan 18, 2005 5:52 pm Post subject:
Ports scanned despite NAT |
|
|
Hi,
I've got a home setup with a D-Link DSL-302G, which provides DHCP/NAT +
ADSL functionality (ie a "DSL router") to my PC running debian sarge.
I also happen to have the gnome firestarter package running. And a while
ago firestarter reported a few attempted connections to TCP ports in the
range 33367-33432.
I'm curious as to how these might have reached my PC, given that NAT
isn't set up to forward any packets inbound.
Long version:
After setting up firestarter, I wanted to double-check my security so I
looked for a few internet sites providing "scan me" functionality. I
used the Sygate Online Services, which reported no services available as
expected. I also visited www.mysonicwall.com, but didn't use their service.
A short while later firestarter alerted me to connection attempts on my
PC that sure look like a "port scan", from source address 64.41.140.174
(partners.mysonicwall.com) against about a dozen ports from 33367-33432.
I'm rather puzzled as to how they could possibly be able to reach my PC
at all. Shouldn't NAT make that impossible? (I have no special NAT rules
defined in the router/dsl-modem device).
Are they perhaps using some sort of broadcast flag attached to a packet
directed at the public IP address of the router, or something nasty like
that?
Or are they perhaps doing a scan of the router's address, and the router
is forwarding packets for these ports to my PC because recent
FTP/HTTP/etc accesses originating from my PC happened to use these ports
and so the router thinks data addressed to these ports are "response"
packets for connections earlier originated by me? If so, is this a flaw
in the D-Link software (surely such tables should be cleared once the
connection has been dropped..)?
NB: I do have custom rules defined via firestarter, allowing all access
for 10.0.0.0/8, so that access from my lan is possible. I don't believe
this opens up any holes, though.
Thanks for any info,
Simon
PS: Firestarter rocks (netfilter made friendly)! |
|
Moe Trin
Guest
|
| Posted:
Wed Jan 19, 2005 5:15 am Post subject:
Re: Ports scanned despite NAT |
|
|
In article <Ov7Hd.9086$mo2.685178@news.xtra.co.nz>, simon wrote:
| Quote: | I also visited www.mysonicwall.com, but didn't use their service.
A short while later firestarter alerted me to connection attempts on my
PC that sure look like a "port scan", from source address 64.41.140.174
(partners.mysonicwall.com) against about a dozen ports from 33367-33432.
|
"A short while later"... means a second, a minute, an hour?
| Quote: | I'm rather puzzled as to how they could possibly be able to reach my PC
at all. Shouldn't NAT make that impossible? (I have no special NAT rules
defined in the router/dsl-modem device).
|
33367-33432 is sixtyfive different ports. That's a lot of different
connections. Do you have any record (in the firewall log perhaps) what
port numbers you were using earlier? Are those are "new" connections, or
could these be responses (look at the SYN and ACK flags). Also, what were
the source port numbers?
| Quote: | Are they perhaps using some sort of broadcast flag attached to a packet
directed at the public IP address of the router, or something nasty like
that?
|
RFC0793 No such flag
| Quote: | Or are they perhaps doing a scan of the router's address,
|
well, they can't be scanning your 10.0.0.0/8 addresses
| Quote: | and the router is forwarding packets for these ports to my PC because
recent FTP/HTTP/etc accesses originating from my PC happened to use
these ports and so the router thinks data addressed to these ports are
"response" packets for connections earlier originated by me? If so, is
this a flaw in the D-Link software (surely such tables should be cleared
once the connection has been dropped..)?
|
Not enough information. How were the connections dropped? Were FIN flagged
packets exchanged (normal completion), or was the rug pulled out (RTS flag),
or did you 'hill -9' whatever process you had been using to "talk" to the
remote site. This would show up TEMPORARILY in the output of the command
'netstat -tupan' on the Debian box. If the connections were not shut down
cleanly, one might expect the D-Link box to hold the connections open for
some time.
| Quote: | NB: I do have custom rules defined via firestarter, allowing all access
for 10.0.0.0/8, so that access from my lan is possible. I don't believe
this opens up any holes, though.
|
Generally no - although some ISPs do use IP addresses within the 10.0.0.0/8
block for internal purposes. If your ISP is not using that block, there
should be a rule on the DSL router that is dropping packets in OR out with
those addresses as source or destination. Obviously, it would normally be
NATing those addresses of yours (10.0.0.0/8 as source outbound and the
resulting replies inbound). If your ISP does use 10.0.0.0/8 internally,
and you don't need 16.7 million addresses on your LAN, I'd suggest changing
to a different RFC1918 address or at the very least a different network
mask, so that you can tell the difference between your local hosts and the
hosts on the ISPs internal network. See RFC1918 and RFC1878.
| Quote: | PS: Firestarter rocks (netfilter made friendly)!
|
It's one of a _huge_ number of helper tools that act as firewall front ends.
Hmmm, where do I send you from here? The Networking-Overview-HOWTO refers
you to the NET3-4-HOWTO, but neither talk about how a TCP connection is set
up and torn down. 'man nmap' has a lot of details, but it's not quite the
tutorial you want (though it's DEFINITELY worth the read). The "Linux
Network Administrator's Guide" from the LDP (also printed by O'Reilly as
ISBN 1-56592-400-2) only skims this. Perhaps the 'TCP/IP Network
Administration" from O'Reilly (ISBN 0-596-00297-1) or the expensive but
reference standard "TCP/IP Illustrated Volume 1" by W. Richard Stevens
(Addison Wesley, ISBN 0-201-63346-9) - if you have access to a good
technical library, those would be worth looking at. Ah, another source
would be RFC1180 which is a tutorial (slightly dated, but free). It also
mentions "Internetworking with TCP/IP Principles, Protocols, and
Architecture" from Prentice Hall, but doesn't give the ISBN number. The
Reading-List-HOWTO doesn't mention it either. The HOWTOs should be on
your system, and perhaps the Linux Network Administrators Guide (look for
the 'network-guide' or 'nag2' - the latter being the second edition).
Old guy |
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in