Go daddy port scanning me?
-
"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:
-
hmm just had a google about and it seems that rule 1/0 is the default deny rule?
-
When I look at my rules the default deny seems to be rule 3
The rule that triggered this action is:
@3 scrub on em3 all fragment reassemble
@3 block drop in log inet all label "Default deny rule IPv4"Which is why I asked if he could actually click the red X in his firewall log and get some details of what rule the firewall says it is.
If this is out of state traffic then yes it will be blocked.. And not uncommon to see such traffic when something gets disconnected, etc. But if this is really response from CRL checking of godaddy certs by his clients should be allowed.
-
When I look at my rules the default deny seems to be rule 3
The rule that triggered this action is:
@3 scrub on em3 all fragment reassemble
@3 block drop in log inet all label "Default deny rule IPv4"Which is why I asked if he could actually click the red X in his firewall log and get some details of what rule the firewall says it is.
If this is out of state traffic then yes it will be blocked.. And not uncommon to see such traffic when something gets disconnected, etc. But if this is really response from CRL checking of godaddy certs by his clients should be allowed.
ahh right mine is:
And yes I'd agree with you on the CRL side of things….but I am the only person at the moment who is using this exchange server.
PLUS these ACKs are coming from just 3 IPs 24/7!either I have missed something here or GoDaddy have...
-
"but I am the only person at the moment who is using this exchange server.
PLUS these ACKs are coming from just 3 IPs 24/7!"So the only traffic outbound from pfsense is this exchange server, there is NO clients behind pfsense?
Also the ips your seeing are NOT on the list from godaddy for their CRLs - but yes crl is a FQDN, and its served up from a CDN so its IP will change I would assume.
;; QUESTION SECTION:
;crl.godaddy.com. IN A;; ANSWER SECTION:
crl.godaddy.com. 855 IN CNAME gdcrl.godaddy.com.akadns.net.
gdcrl.godaddy.com.akadns.net. 12 IN A 50.63.243.228So its quite possible that IP changes..
As to the oscp
;; QUESTION SECTION:
;ocsp.godaddy.com. IN A;; ANSWER SECTION:
ocsp.godaddy.com. 1647 IN CNAME ocsp.godaddy.com.akadns.net.
ocsp.godaddy.com.akadns.net. 31 IN A 72.167.18.239I really would watch a full sniff to see if your sending out traffic to these IPs - which don't really seem to be CRL or OSCP.
