About 5 seconds after I start SeaMonkey v2.31, I get a notification from MalwareBytes that it blocked outgoing from local port (variable) to, I kid you not, my external IP, the one on the WAN side of the router that my ISP issues every once in a while. That's on Win7. Nothing special in the Outpost firewall log. On XP - the same thing. So I turned on logging in the firewall. I don't have MBAM pro with its traffic scans on XP. Here, on the same SeaMonkey start, the same router, the firewall (Kerio or Sunbelt) shows it's outbound by TCP to ... my external IP, port 80. Can someone explain this? Why would I be going to http port of the other side of the router? Not sure if this post should be here or in Other... Edit: I forgot to mention, this is a quick, fleeting, affair of SYN_SENT, three times or so (on XP) and then no more.
Is NoScript installed? It has an Advanced->ABE->WAN IP feature which detects your public IP Address (via request to external server) so that said IP Address can be treated as a local address (that remote origins shouldn't be allowed to contact). NoScript also sends a request to that public IP Address (triggering a connection attempt). I forget the details, but IIRC the request is part of change detection logic.
Brilliant. Yes, that's what it is. SeaMonkey+NoScript. Odd that they flagged a legitimate thing. Anyway, I disconnected, reconnected, have a new IP in different IP range, MBAM is quiet. I've seen that sort of thing in some logs before but this time didn't connect the dots. Thank you
In some scenarios such traffic would be a threat: a DNS rebinding attack, perhaps some other cross-site exploit attempt. Those are what NoScript is trying to protect against. However, its design is such that it generates somewhat similar traffic. Was MBAM trying to protect you from similar threats and NoScript created a false positive? Was MBAM flagging the connection attempt for some other reason? Your subsequent "MBAM quiet after IP Address change" suggests it may be the later, but it isn't clear whether you restarted the browser to make NoScript generate such traffic again.
