SPI is present in NetMon. Having a rule for OUT in conjunction with SPI means that i can receive packets from outside (lol), as long as they were requested by me, or from a comunication started by me (request webpage- got it).
The thing is, since AppMon apparently does not have SPI, sometimes it nees IN rules to allow comunication started by us.
It’s not an INbound rule in the true sense, since it’s not unsolicited. That’s why even if you open IN for Emule in AppMon, you still have a low id. You have to open a true INbound rule in NetMon for that specific port used by Emule to properly work as P2P, and accept incoming and unsolicited packets.
BUT then, what is IN rule in AppMon?? I’m sure there’s some rational explanation, but i do not have one lol.
Sometimes it’s needed, sometimes not. Why? What’s the mechanism that makes me need and IN rule for an application, or for that specific Port?
BTW, IN/OUT, unless it’s for Any-Any, seems non functional. If i specify a port or IP, who’s who (source and destination)? If it’s In, it’s one thing, if it’s Out, it’s another, for the same rule!?
Now picture Local and Remote
Even with local and remote, the INbound rules for AppMon needs clarification (in my head it does!). Maybe better integration with NetMon’s SPI?
Thanks Toggie, i do appreciate it. But there’s no answer to my questions in those links.
When does an application need INbound AppMon rules? I know how to work with NetMon, then i just allow whatever AppMon rules are needed, because they are NOT Inbound rules. What are they? Why and when do i need IN on AppMon?
Pedro and I have been PM’ing about this earlier. Aside from loopbacks and a required opened listening port for incoming connections in P2P applications, I also need it for Yahoo Messenger. I tried it before by blocking incoming in App Mon, was still able to log on, but it won’t function (can’t chat, broadcast webcam, etc.).
A game that i occasionally play is America’s Army. For that i need some rule for UDP-IN, in AppMon, NOT NetMon. Checking the rules, it also displays as destination the IP for the corresponding server, so it either is not IN because destination is not me, or “destination” isn’t destination.
Huh?
Ok I just tried this again. I only allowed all OUT for YM and delete the IN portion. Here are the following IN and port # alerts:
TCP 5052, UDP 1851, UDP 1852, TCP 5101, UDP 1854, TCP 5057. They were sequential within 5 seconds of each other without me doing anything but merely remaining idly logged in. Then I opened webcam and it alerted TCP IN 5103. Actually, I blocked that last one and webcam still works (although I don’t know if others can see me since none of my contacts were online).
Screenshot Sample shows it’s a listening port (my loopback checks are skipped). Why would an app require so many listen ports besides it being adware?
Edit: I blocked all TCP and UDP IN and can’t log on. Also, these specific port #'s seemed to be constant in that if I log out and back in, it doesn’t alert for others. Something with these are tied to YM 8.1.0.249 (the latest ver).
Protocol: UDP
Direction: Inbound
Local Port(s): 5000, 5055
Action: Allow
Everything else seems to be OUT.
BTW I like this from the YM help site:
For most home editions of firewall software, you will need to open all outgoing TCP ports in the range of 5000 to 65535 so Yahoo! Messenger can make Yahoo! Voice calls.
I’m not as worried with it being all OUT vs all IN, but then again, there’s no Network rules to allow incoming (except the reserved one for uTorrent), so my ports are still closed with YM on. Still goes back to Pedro’s original question why only some apps.
I think that you also needs an Application IN rule to let the firewall knows that that application have permissions to listen packets on that port.
Otherwise, all the applications could listen the packets that you allowed on the Network IN rule or by SPI.
It’s a security extra…
A Network IN rule should be required only if need to receive some unsolicited packet…
The alert is also for the user notice that some application wants to acts like a server, and then decide if he/she needs to make an network rule to allow that traffic…
I guess one more question arises from the help file:
The Second Column (Destination) represents the remote IP Address of the application.
So why is it that sometimes, for an IN rule in AppMon, some have my internal IP (LAN/ 192.168.x.x), and some have the IP for the game server for instance?
If it's the remote IP adress, my IP should never appear, if it's destination, the server would never appear.
So ??? again
Maybe put 