Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 2 subscribers
  • Views 2746 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Packet Filter and cdsXX.ewr9.msecn.net

joequick
In a previous post I had found that unconfigured browsers could access the internet and bypass AD Auth thru port 80. My bad. THere was a rule in place and I corrected that.

In doing so It blocked Windows Update (which was using port 80). I added a rule for that and and access to llnw.net which is also needed for WinUpdate to work.

BUt now I am seeing the packet filter blocking connections to msecn.net

3 unknown 70.37.129.92 cds87.ewr9.msecn.net 54 3.09
4 unknown 70.37.129.171 cds166.ewr9.msecn.net 45 2.57
5 unknown 70.37.129.18 cds13.ewr9.msecn.net 45 2.57
6 lan 192.168.1.100 n/a 45 2.57
7 unknown 70.37.129.23 cds18.ewr9.msecn.net 42 2.40
8 unknown 70.37.129.91 cds86.ewr9.msecn.net 39 2.23
9 unknown 70.37.129.17 cds12.ewr9.msecn.net 36 2.06
10 unknown 70.37.129.179 cds174.ewr9.msecn.net 30 1.72


Does anyone have a clue what mcecn.net is used for?
Or what application would use it?

Thanks.


This thread was automatically locked due to age.
  • 0
    Joe, that doesn't look like any packet filter log I've ever seen...  I don't think the PF even see domain names.

    Cheers - Bob
  • 0
    Hi Bob.
    Thats from the executive report.

    This is from NetworkSecurity/WebAdmin

    2 tcp/80  70.37.129.84 48 3.29 
    3 tcp/80  70.37.129.76 48 3.29 
    4 tcp/80  70.37.129.165 45 3.08 
    5 tcp/80  70.37.129.162 42 2.87 
    6 tcp/80  70.37.129.134 39 2.67 
    7 tcp/80  192.168.1.100 39 2.67 
    8 tcp/80  70.37.129.109 36 2.46 
    9 tcp/80  70.37.129.36 36 2.46 
    10 tcp/80  70.37.129.72 33 2.26 


    This is from the packet filter log:

    /var/log/packetfilter.log:2009:09:30-09:03:53 qcspcxx1 ulogd[3364]: id="2003" severity="info" sys="SecureNet" sub="packetfilter" name="Packet rejected" action="reject" fwrule="8" seq="0" initf="eth1" outitf="eth1" dstmac="00:14:38:eb:51:1f" srcmac="00:c0:f0:55:b1:3f" srcip="192.168.60.3" dstip="70.37.129.36" proto="6" length="48" tos="0x00" prec="0x00" ttl="126" srcport="2408" dstport="80" tcpflags="SYN" 
    /var/log/packetfilter.log:2009:09:30-09:03:59 qcspcxx1 ulogd[3364]: id="2003" severity="info" sys="SecureNet" sub="packetfilter" name="Packet rejected" action="reject" fwrule="8" seq="0" initf="eth1" outitf="eth1" dstmac="00:14:38:eb:51:1f" srcmac="00:c0:f0:55:b1:3f" srcip="192.168.10.19" dstip="70.37.129.36" proto="6" length="48" tos="0x00" prec="0x00" ttl="127" srcport="1077" dstport="80" tcpflags="SYN" 
    /var/log/packetfilter.log:2009:09:30-09:04:11 qcspcxx1 ulogd[3364]: id="2003" severity="info" sys="SecureNet" sub="packetfilter" name="Packet rejected" action="reject" fwrule="8" seq="0" initf="eth1" outitf="eth1" dstmac="00:14:38:eb:51:1f" srcmac="00:c0:f0:55:b1:3f" srcip="192.168.10.19" dstip="70.37.129.39" proto="6" length="48" tos="0x00" prec="0x00" ttl="127" srcport="1078" dstport="80" tcpflags="SYN" 
    /var/log/packetfilter.log:2009:09:30-09:04:14 qcspcxx1 ulogd[3364]: id="2003" severity="info" sys="SecureNet" sub="packetfilter" name="Packet rejected" action="reject" fwrule="8" seq="0" initf="eth1" outitf="eth1" dstmac="00:14:38:eb:51:1f" srcmac="00:c0:f0:55:b1:3f" srcip="192.168.10.19" dstip="70.37.129.39" proto="6" length="48" tos="0x00" prec="0x00" ttl="127" srcport="1078" dstport="80" tcpflags="SYN" 


    I have a fwrule=8 is block all http traffic on port 80.
  • 0
    There are lots of ways to skin a cat... some of them are more like to leave you covered with scratches! [;)]

    You should not need any rules in the PF for inbound traffic except in very specific circumstances - and most of those are done with automatic PF rules in DNATs.  Your PF rule 8 would only be in place if you had an earlier rule allowing some in-bound traffic, and neither it nor #8 really should be there.

    Even without a rule to let in traffic on port 80 from Microsoft, everyone gets their Windows updates.  The right place to allow access to WinUpdate is in the Exceptions in HTTP/S.  

    If you are scanning HTTPS traffic, then you'll also need to import the Cert into Windows via mmc; Gert's instructions are here.

    Cheers - Bob
  • 0
    Bob,
    Your not following me.
    These packets are outbound.

    I am trying to figure out what is msecn.net and what program/process is trying to connect to it for what reason.

    Google doesnt tell me squat and I figured someone here must have seen this before.

    Joe
  • 0
    Oops!  I was not multi-tasking very successfully, was I?

    Still, I don't understand why you would need an explicit PF rule to reject outbound traffic of any kind.  After the Astaro processes all of the "auto" rules, it runs through the explicit PF rules, then, it drops the packet by default.

    I found: Onecare eating 3GB of bandwidth from my computers daily!

    I'm confused by your situation.  Sorry, I don't think I know enough to help.

    Cheers - Bob
  • 0
    No worries Bob, its all good.

    I just have it there as backup to double check myself.

    Thanks for the link.
    I dont have OneCare installed on any PCs here that I can remember.
    I will double check to be sure.
    I may even allow it to go out and see what happens.

    Thanks again you multiTasker,
    Joe