On Thursday, February 24, 2011 07:06:34 pm Tim wrote: > On Thursday 24 February 2011 00:15:10 Ralph Corderoy wrote: > > Hi Dan, > > > > > On Wednesday 23 February 2011 23:12:31 Dan Dart wrote: > > > > 8.8.8.8 is Google's DNS service. If you're using it, then that'll be > > > > why. The high port numbers are the responses. which were blocked :( > > > > > > I know 8.8.8.8 is google, I have had the same log entries when I was > > > using opendns IP (208.67.222.222). I realise that the log entry is > > > telling me that a port scan was blocked but I want to know why the dns > > > is scanning my system on high port numbers when the dns port number is > > > normal 53, is this high level port number scanning normal activity?? > > > > If I'm remembering my Stevens' correctly, and Andy Paterson will correct > > me if I'm wrong, IP packets use a 5-tuple to fully specify the > > "connection", e.g. TCP. Its members are > > > > protocol, local address, local port, remote address, remote port > > > > When my machine sends a DNS request to Google that tuple might be > > > > UDP, 87.113.175.32, 49681, 8.8.8.8, 53 > > > > 87... is my IP address at the moment, 8.8.8.8 and 53 you recognise as > > one of Google's DNS servers' IP addresses and the domain service's port > > number. The local port, 49681, has been picked randomly by my machine > > because the resolver software said it didn't care what the port number > > was so it just got a spare one. > > > > It's the well-known destination port, 53, that's important when > > initiating a request to a server. The server will see the address and > > port number of the peer, 87.113.175.32 and 49681, and send the reply > > there. > > > > No two duplicate 5-tuples exist at the same moment. If I ssh, port 22, > > from machine foo to machine bar in one terminal, and then do the same in > > another, the tuples may be > > > > TCP, foo, 41839, bar, 22 > > TCP, foo, 38220, bar, 22 > > > > It's the differing local port numbers that allow those two connections > > to exist at the same time; every other member of the tuple is > > identical. > > > > So back to your original issue, > > > > > TCP- or UDP-based Port Scan DETECTED on Wed Feb 23 22:21:20 2011 > > > Â targeting ***.***.***.***,61169, sent from 8.8.8.8,53 (*=my ip > > > address) > > > > 61169 is the local port number that Google's DNS server thinks > > originated the request that it's replying to. Your stateful firewall > > software thinks that's a port scan because it never saw the outgoing > > request or the request to Google didn't come from you and someone is > > spoofing your IP address. Or your firewall is buggy. :-) If they are > > spoofing you then they're probably not picking on you per se, it's just > > one of those things and this email is long enough already. > > > > As for why they still occur when you use OpenDNS, I guess it's because > > something on your LAN is still configured to use Google. You could use > > tcpdump or Wireshark on an appropriate machine to try and see the > > outgoing request. > > > > sudo tcpdump port domain > > > > Cheers, > > Ralph. > > So these inbound TCP\UDP based request, should I continue to block them? if > I allow them through how do I do it, do I need to forward them to > something on my netwrok possibly my firewall? > > Tim > > -- > Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 > Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ > How to Report Bugs Effectively: http://goo.gl/4Xue Hi, I stand corrected if I am wrong - but I beieve with TCP you are blocking CONNECT requests. There shouldn't be anything trying to connect to an unknown (high) TCP port [not specifcally allowed by your firewall] on your m/c - so yes - block them. Once a connection is made (an incoming connect request to an allowed port) accept(2) will grab another port so that the original port is free for further connect requests. The new port [your end of the tcp connection] will be an unused port in the range you are talking about - but this won't matter, since its the connect requests that are blocked not parts of an active tcp connection. However (as Ralph is pointing out) the firewall tries to recognise that a TCP message (datagram) is part of an established connection & if it doesnt think it is - for the reason Ralph gave - it will drop the datagram). With UDP (since its connectionless) you are simply blocking any datagrams (messages) destined to the specified port on your system. Just my 10C Andy
-- Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue
