Go daddy port scanning me?
-
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?
-
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?
I mate.
I have all logs go over to my syslog server - I admit I have left out the lines above the logs entries for each entry which shows the action and more detail…
here is an example of the full logs for 1 minute ago:
2013-08-06T16:35:31+01:00 192.168.0.254 pf: 00:00:00.118987 rule 1/0(match): block in on pppoe0: (tos 0x78, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 40)
2013-08-06T16:35:31+01:00 192.168.0.254 pf: 188.121.36.176.80 > MYIPADDRESS.45907: Flags [.], cksum 0xe8da (correct), ack 576104550, win 54, length 0
2013-08-06T16:35:39+01:00 192.168.0.254 pf: 00:00:08.174619 rule 1/0(match): block in on pppoe0: (tos 0x78, ttl 53, id 0, offset 0, flags [DF], proto TCP (6), length 40)
2013-08-06T16:35:39+01:00 192.168.0.254 pf: 188.121.36.177.80 > MYIPADDRESS.22910: Flags [.], cksum 0x1094 (correct), ack 2458028443, win 54, length 0 -
And what is this rule exactly "rule 1/0(match)"
Can you post up your rules?
Can you find one of these blocks in your actual firewall log and click the red X so we can see the details of which rules triggered the block.
-
And what is this rule exactly "rule 1/0(match)"
Can you post up your rules?
to be perfectly honest I'm not sure which rule that would be…
I assumed that it was rejected by rule1/0 as it wasn't in the state table and no connection to that IP / port had been opened?
I though the Rule 1/0 was perhaps a way for the firewall to explain the State table?
my first 4 rules that reject traffic are as follows:
