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 0

    Any ideas?



  • Hmmm.  Are you using a service of theirs?


  • LAYER 8 Global Moderator

    "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



  • @kejianshi:

    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.



  • @johnpoz:

    "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.176

    My 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?


  • Banned

    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.)



  • @doktornotor:

    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.


  • LAYER 8 Global Moderator

    "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..



  • @johnpoz:

    "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?



  • @Deadringers:

    @johnpoz:

    "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.



  • @kejianshi:

    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?



  • :'(


  • LAYER 8 Global Moderator

    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.239

    Question 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 :)

    @johnpoz:

    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.239

    Question 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.



  • @kejianshi:

    :'(

    ?



  • 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.


  • LAYER 8 Global Moderator

    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?



  • @johnpoz:

    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


  • LAYER 8 Global Moderator

    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.



  • @johnpoz:

    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?


  • LAYER 8 Global Moderator

    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.



  • @johnpoz:

    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...


  • LAYER 8 Global Moderator

    "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.228

    So 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.239

    I 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.


Log in to reply