Go daddy port scanning me?
-
Hi all,
I've tried to contact Go-daddy support on multiple occasions now but just get the empty promise of "I'll pass this to 3rd line".
I have NEVER heard back with an answer to this.
So the facts:
I bought an SSL cert from Go-daddy for my exchange server.
occasionally I can see traffic coming from the exchange server to a Go-daddy IP.
That's find and I understand that it has to do it for the cert and some checks etc.what I don't understand is why go-daddy is hitting me from 3 different IPs constantly (and I mean 24/7) on random high numbered ports?
My server has NOT entered any communication with these IPs.
they just constantly hit my IP on random ports.An example from the last 12 minutes on my firewall logs - all of these have been dropped. not dropped due to any firewall Rule but dropped as they are not in the state table.
2013-08-05T19:00:10+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.57181: Flags [.], cksum 0x565d (correct), ack 2848295902, win 54, length 0
2013-08-05T19:00:21+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.54808: Flags [.], cksum 0x2055 (correct), ack 572831821, win 54, length 0
2013-08-05T19:01:02+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.20297: Flags [.], cksum 0x0ff1 (correct), ack 4012816923, win 54, length 0
2013-08-05T19:01:12+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.20352: Flags [.], cksum 0xaf06 (correct), ack 2142914745, win 54, length 0
2013-08-05T19:01:18+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.54259: Flags [.], cksum 0x360c (correct), ack 2737154759, win 54, length 0
2013-08-05T19:01:22+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.28821: Flags [.], cksum 0xa482 (correct), ack 175413104, win 54, length 0
2013-08-05T19:01:40+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.35576: Flags [.], cksum 0xb686 (correct), ack 91424366, win 54, length 0
2013-08-05T19:02:16+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.63004: Flags [.], cksum 0x2010 (correct), ack 1410901440, win 54, length 0
2013-08-05T19:02:31+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.47535: Flags [.], cksum 0xd590 (correct), ack 4036366745, win 54, length 0
2013-08-05T19:02:39+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.5839: Flags [.], cksum 0x1b47 (correct), ack 1634135729, win 54, length 0
2013-08-05T19:03:12+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.48300: Flags [.], cksum 0x7cff (correct), ack 1792687180, win 54, length 0
2013-08-05T19:03:20+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.4877: Flags [.], cksum 0x65cd (correct), ack 3579224629, win 54, length 0
2013-08-05T19:03:41+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.12750: Flags [.], cksum 0x5aa1 (correct), ack 1740329923, win 54, length 0
2013-08-05T19:04:08+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.33824: Flags [.], cksum 0x6a7f (correct), ack 156017432, win 54, length 0
2013-08-05T19:04:17+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.62423: Flags [.], cksum 0x11cc (correct), ack 2160985759, win 54, length 0
2013-08-05T19:04:49+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.51973: Flags [.], cksum 0x01ac (correct), ack 2847148268, win 54, length 0
2013-08-05T19:05:05+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.16909: Flags [.], cksum 0x7780 (correct), ack 976004893, win 54, length 0
2013-08-05T19:05:23+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.54314: Flags [.], cksum 0x540b (correct), ack 2955017419, win 54, length 0
2013-08-05T19:05:53+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.9158: Flags [.], cksum 0x4665 (correct), ack 3215629520, win 54, length 0
2013-08-05T19:05:57+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.28921: Flags [.], cksum 0xdd63 (correct), ack 173551790, win 54, length 0
2013-08-05T19:06:17+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.54174: Flags [.], cksum 0xe488 (correct), ack 3769398783, win 54, length 0
2013-08-05T19:06:42+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.13246: Flags [.], cksum 0x370d (correct), ack 323718597, win 54, length 0
2013-08-05T19:07:06+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.50088: Flags [.], cksum 0xb37e (correct), ack 781143282, win 54, length 0
2013-08-05T19:07:22+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.49555: Flags [.], cksum 0xccc5 (correct), ack 3071189719, win 54, length 0
2013-08-05T19:07:23+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.57673: Flags [.], cksum 0xaf8c (correct), ack 3134473919, win 54, length 0
2013-08-05T19:07:38+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.15725: Flags [.], cksum 0x8002 (correct), ack 19263428, win 54, length 0
2013-08-05T19:08:03+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.20606: Flags [.], cksum 0x841e (correct), ack 2173056951, win 54, length 0
2013-08-05T19:08:17+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.25582: Flags [.], cksum 0x185d (correct), ack 4862421, win 54, length 0
2013-08-05T19:08:43+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.60625: Flags [.], cksum 0xb930 (correct), ack 873043464, win 54, length 0
2013-08-05T19:09:15+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.3255: Flags [.], cksum 0x5008 (correct), ack 657860668, win 54, length 0
2013-08-05T19:09:23+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.43793: Flags [.], cksum 0x0106 (correct), ack 1806628257, win 54, length 0
2013-08-05T19:09:40+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.5446: Flags [.], cksum 0xd0bb (correct), ack 2530153798, win 54, length 0
2013-08-05T19:09:41+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.59716: Flags [.], cksum 0x48c3 (correct), ack 1794803338, win 54, length 0
2013-08-05T19:10:18+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.22608: Flags [.], cksum 0x6883 (correct), ack 3562874930, win 54, length 0
2013-08-05T19:10:20+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.7782: Flags [.], cksum 0x2695 (correct), ack 8569135, win 54, length 0
2013-08-05T19:10:28+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.33352: Flags [.], cksum 0x111d (correct), ack 3522733269, win 54, length 0
2013-08-05T19:10:28+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.47391: Flags [.], cksum 0xc62d (correct), ack 2310059695, win 54, length 0
2013-08-05T19:10:44+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.41116: Flags [.], cksum 0x49de (correct), ack 2520945552, win 54, length 0
2013-08-05T19:10:57+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.52781: Flags [.], cksum 0x431e (correct), ack 1086986376, win 54, length 0
2013-08-05T19:11:08+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.54984: Flags [.], cksum 0x932d (correct), ack 2971314106, win 54, length 0
2013-08-05T19:11:15+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.17226: Flags [.], cksum 0x7069 (correct), ack 3751053583, win 54, length 0
2013-08-05T19:11:22+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.55899: Flags [.], cksum 0x0abb (correct), ack 1095526808, win 54, length 0
2013-08-05T19:11:22+01:00 192.168.0.254 pf: 188.121.36.178.80 > MY_IP_ADDRESS.54494: Flags [.], cksum 0xb6ca (correct), ack 3688078037, win 54, length 0
2013-08-05T19:12:13+01:00 192.168.0.254 pf: 188.121.36.177.80 > MY_IP_ADDRESS.10939: Flags [.], cksum 0x62eb (correct), ack 3049159105, win 54, length 0
2013-08-05T19:12:45+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.49417: Flags [.], cksum 0x1baa (correct), ack 721603039, win 54, length 0
2013-08-05T19:12:53+01:00 192.168.0.254 pf: 188.121.36.176.80 > MY_IP_ADDRESS.28159: Flags [.], cksum 0x7011 (correct), ack 3391201692, win 54, length 0Any ideas?
-
Hmmm. Are you using a service of theirs?
-
"That's find and I understand that it has to do it for the cert and some checks etc."
What? That doesn't make any sense.
How about the whole stream.. Those are acks – you sure there is nothing going out syn where these are answers too? Where exactly and how are you pulling that data? That its showing you cksum being correct
-
Hmmm. Are you using a service of theirs?
eh?
@Deadringers:So the facts:
I bought an SSL cert from Go-daddy for my exchange server. -
"That's find and I understand that it has to do it for the cert and some checks etc."
What? That doesn't make any sense.
How about the whole stream.. Those are acks – you sure there is nothing going out syn where these are answers too? Where exactly and how are you pulling that data? That its showing you cksum being correct
So occasionally my server hits an IP of godaddy's:
2013-08-06T11:13:49+01:00 192.168.0.254 pf: EXCHANGESERVERIP.18203 > 188.121.36.239.80: Flags [SEW], cksum 0xbe5c (correct), seq 226130666, win 8192, options [mss 8960,nop,wscale 8,nop,nop,sackOK], length 0
This is fine as I understand for the SSL cert my server has to occasionally check with go-daddy that it's up to date, hasn't been revoked and is still valid etc.
I GET THAT!But what I don't understand is why godaddy then seemingly port scan me from 3 different IPs (all source port 80)?
I log every single packet that goes in and out of my firewall.
I have checked the state table and there is no entry for these 3 rogue IPs:
188.121.36.178
188.121.36.177
188.121.36.176My server has NEVER entered communication with those 3 IPs. but they constantly send me packets?
And interesting what you say about the checksum. I thought this was just a checksum to ensure the packet is okay and not any relevance to whether or not the firewall was expecting it?
-
Oh noes, your firewall is getting hits from Internet? That must be a serious problem indeed. Do you make such fuss everytime an unsolicited packet hits your firewall? (On that note, these are not even unsolicited apparently.)
-
Oh noes, your firewall is getting hits from Internet? That must be a serious problem indeed. Do you make such fuss everytime an unsolicited packet hits your firewall? (On that note, these are not even unsolicited apparently.)
:)
it's the fact that its 24/7 and from Go-daddy where I got my cert that I am puzzled as to why this is happening.
-
"This is fine as I understand for the SSL cert my server has to occasionally check with go-daddy that it's up to date, hasn't been revoked and is still valid etc."
What?? Where do you get that idea from? What part in your http service is going to check its cert for validity?? Now your clients that are talking to your sever and getting handed your cert might check its crl, but that is not going to come from your IP.
Why don't you LOOK at the whole stream and see what actually being sent, vs just some stupid headers and assuming its this or that.
And sorry acks to random ports is not a port scan.. And that is NOT a any sort of amount of traffic to be worried about.. 46 packets over a 12 minutes.. That is a pretty freaking slow "port scan" ;) Why would I be scanning 28921 – what maybe your running a service on that I can exploit? ;)
You seem to be a fan of capturing packets -- why don't you grab all of it in both directions, and then open it up in say wireshark and follow the stream to see what is actually in the packets vs being worried about some acks to some ports..
-
"This is fine as I understand for the SSL cert my server has to occasionally check with go-daddy that it's up to date, hasn't been revoked and is still valid etc."
What?? Where do you get that idea from? What part in your http service is going to check its cert for validity?? Now your clients that are talking to your sever and getting handed your cert might check its crl, but that is not going to come from your IP.
Why don't you LOOK at the whole stream and see what actually being sent, vs just some stupid headers and assuming its this or that.
And sorry acks to random ports is not a port scan.. And that is NOT a any sort of amount of traffic to be worried about.. 46 packets over a 12 minutes.. That is a pretty freaking slow "port scan" ;) Why would I be scanning 28921 – what maybe your running a service on that I can exploit? ;)
You seem to be a fan of capturing packets -- why don't you grab all of it in both directions, and then open it up in say wireshark and follow the stream to see what is actually in the packets vs being worried about some acks to some ports..
Go daddy told me that my server which has the SSL cert has to communicate with their servers every so often?
I understand it's not a port scan - bad choice of wording on my part.
I'm not worried about this - all the packets are getting blocked from not being in the state table.
I'm trying to figure out why I'm getting hit by these IPs with all these ACKs when I've sent nothing to them? -
"This is fine as I understand for the SSL cert my server has to occasionally check with go-daddy that it's up to date, hasn't been revoked and is still valid etc."
What?? Where do you get that idea from? What part in your http service is going to check its cert for validity?? Now your clients that are talking to your sever and getting handed your cert might check its crl, but that is not going to come from your IP.
Why don't you LOOK at the whole stream and see what actually being sent, vs just some stupid headers and assuming its this or that.
And sorry acks to random ports is not a port scan.. And that is NOT a any sort of amount of traffic to be worried about.. 46 packets over a 12 minutes.. That is a pretty freaking slow "port scan" ;) Why would I be scanning 28921 – what maybe your running a service on that I can exploit? ;)
You seem to be a fan of capturing packets -- why don't you grab all of it in both directions, and then open it up in say wireshark and follow the stream to see what is actually in the packets vs being worried about some acks to some ports..
Go daddy told me that my server which has the SSL cert has to communicate with their servers every so often?
I understand it's not a port scan - bad choice of wording on my part.
I'm not worried about this - all the packets are getting blocked from not being in the state table.
I'm trying to figure out why I'm getting hit by these IPs with all these ACKs when I've sent nothing to them?This is what I was told by go-daddy:
-
I see what is happening here.
What all the guys here are trying to tell you, is don't worry about it.
What you are seeing it nothing all that strange. So relax. You are not hacked.
-
I see what is happening here.
What all the guys here are trying to tell you, is don't worry about it.
What you are seeing it nothing all that strange. So relax. You are not hacked.
Thanks mate - I know I'm not hacked or anything like that.
Just trying to figure out why 3 IPs owned by Godaddy, who I've never contacted, are sending me thousands of acks a day on different ports?
-
:'(
-
So I take it english is not your first language.. Since you don't really seem to understand what that CRL and OCSP stated..
–
CRLs and OCSP use HTTP to retrieve information from the following servers. If you are a network administrator for your organization, make sure all computers in your network that might encounter a digital certificate issued by us can access these CRL and OCSP services.So all computers that might encounter a ssl issued by godaddy.. And when is your exchange server going to encounter one of those?? When does your exchange server go to HTTPS pages and need to check a cert crl? Is your exchange server sending mail via tls and getting certs back from where its trying to send too, so its checking the crl for the cert it got from the domain its sending too..
That is possible -- but NO your httpd does not go and check the SSLs installed on it to use.. Clients check the CRL of certs they have been presented when accessing something via HTTPS..
BTW -- that IP you listed as hitting you with acks, is not on that list of IPs
188.121.36.178 and .177 is what your seeing.. but that list shows
188.121.36.237
188.121.36.238
188.121.36.239Question for you -- is your IP there you list the same IP users would be using to access the internet..
Again.. Lets get a running sniff.. All the TRAFFIC to and from your IP.. For a few minutes.. And lets look to see if your IP in fact does generate traffic to these IPs... And what kind of traffic it is.. Since they are sourcing from 80, I have to assume you contacted them on port 80 so these are answers to your syn..
But traffic should not be encrypted, and should be able to see what is actually in the traffic.
And again where are you pulling that info, that is not from the firewall log. I don't see any drop or rejects or anything in that.. Looks to me headers from a sniff.
That you are filtering in some way, because only seeing one way traffic.
-
I am British :)
So I take it english is not your first language.. Since you don't really seem to understand what that CRL and OCSP stated..
–
CRLs and OCSP use HTTP to retrieve information from the following servers. If you are a network administrator for your organization, make sure all computers in your network that might encounter a digital certificate issued by us can access these CRL and OCSP services.So all computers that might encounter a ssl issued by godaddy.. And when is your exchange server going to encounter one of those?? When does your exchange server go to HTTPS pages and need to check a cert crl? Is your exchange server sending mail via tls and getting certs back from where its trying to send too, so its checking the crl for the cert it got from the domain its sending too..
That is possible -- but NO your httpd does not go and check the SSLs installed on it to use.. Clients check the CRL of certs they have been presented when accessing something via HTTPS..
BTW -- that IP you listed as hitting you with acks, is not on that list of IPs
188.121.36.178 and .177 is what your seeing.. but that list shows
188.121.36.237
188.121.36.238
188.121.36.239Question for you -- is your IP there you list the same IP users would be using to access the internet..
Again.. Lets get a running sniff.. All the TRAFFIC to and from your IP.. For a few minutes.. And lets look to see if your IP in fact does generate traffic to these IPs... And what kind of traffic it is.. Since they are sourcing from 80, I have to assume you contacted them on port 80 so these are answers to your syn..
But traffic should not be encrypted, and should be able to see what is actually in the traffic.
And again where are you pulling that info, that is not from the firewall log. I don't see any drop or rejects or anything in that.. Looks to me headers from a sniff.
That you are filtering in some way, because only seeing one way traffic.
I'll start a packet capture tonight.
Thanks for your help.
-
-
I think packet capture is the wrong answer here. Its just going to lead to more questions and suspicion.
Perhaps never looking at the logs at all is a better answer. -
;D
Perhaps.
my original question was perhaps worded badly.
I am not really concerned or worried about this just wondering why on earth their servers are sending me lots of acks 24/7.
Just seems very strange to me when they would get blocked 24/7.
-
Wanna prank hackers? Open all your ports to a machine running no services at all and not listening on any ports.
-
Here is a question for you
Is it possible you have an asynchronous routing condition.. Is it possible that packets could leave your network in one direction, while return traffic gets routed to wrong host (pfsense)?
I am not clear on what you posted as being anything but a tcp dump.. How do you know those packets weren't passed.. What you posted didn't look like a firewall log to me. Looks like a tcpcump with some sort of filter applied.
Could you post the exact details of where that info came from, if you ran a tcpdump, what was the command line parameters you used? If you pulled it from a log, which exact log?
