Blocking Yahoo! Messenger

[Tiger Shark]

Hey hey

You've been talking to HTRegz too much.... (It's not a bad thing)....

Cool beans!

I haven't heard that in years except from me..... <LOL>

The thread is going downhill......

[AngelicKnight]

MsM is a fan of Websense, but I've never used it. I'm a bit curious about it myself.

I sound like HT? I can sound like Nihil too by ending my post with a misplaced question mark?

[Mark_Anderson]

Blocking login.yahoo.com won't help. Yahoo! has 3 protocols. YCHT, YMSG, and Chat 2 protocol (a weened YMSG protocol). Yahoo! Messenger operates on YMSG. Currently, the newest Messenger Ver 6 uses YMSG12.

Anyhow, Yahoo! Messenger usually will try and connect out to remote tcp :5050 by default.. if that fails, tcp 21, 23, 27, 37, 80, and 119 will all be tried. This is for getting around firewalls (not to mention it's support for Socks 4/5, HTTP proxies and auto-detection options). The local port chosen will be @ random (on my end it's usually allocated in the tcp 50,000 port range). It will listen locally on tcp :5101 for pm's from buddies (for direct connections).

So, to recap... when you sign into Messenger you'll have a random port established for your connection to the msg server you login to (cs1.msg.dcn.yahoo.com - cs60.msg.dcn.yahoo.com | or the socket servers will be used scs.msg.yahoo.com, scsa.msg.yahoo.com, scsb.msg.yahoo.com, scsc.msg.yahoo.com) @ their end on tcp :5050 (unless that fails). TCP :5101 isn't 'established' until you make a direct connection with a buddy on your list... until then it is always 'listening'. You can also pm through the msg server that you're connected to without making a direct connection at all.

The roomlistings are @ a local random port as well and @ remote tcp :80 at their end always.

Voice, by default, is udp 5000-5010. At both your end and their end this is ALWAYS udp 5000 for the RTP voice datastream (the actual compressed audio that's being broadcasted to the room).

RTCP is also used for voice... for voice ignores, voice user listings, etc. This is always from remote tcp port :5001. Your local end might again be in the tcp 50,000 port range (well for me it was).

You also have the option to use TCP for the actual voice rtp datastream too. As you might be able to see by now... the Yahoo! devs obviously find that getting around firewalls is important. This was done for that reason too... when you want to revert to tcp for voice instead of udp for the datastream you would block udp 5000-5010 and you will automatically be assigned a local tcp port for voice to their end's tcp :5000 for the stream.

I could cover webcam and file transfers (which yet again can be either direct or indirect!) but that stuff isn't really necessary. By now, you know more than 90% of most of programmers for Yahoo! Lmao. I happen to be one of those. Only, I don't waste my time making 'booters' all day.

*Note* Webcam and voice ports aren't opened until those features are called upon. They're not listening by default when you start up Messenger like :5101 and the randomly allocated msg server connection port (to remote :5050).

[bumperspoon]

What if we use Group Policy to not allow the program to start up in the first place. It willhave to be done for each new version...but that is the lesser of the two evils. You can have it check the hash...so even if the user changes the exe name it will not open.

[Mark_Anderson]

If you want to block access just deny cs1.msg.dcn.yahoo.com - cs60.msg.dnc.yahoo.com. Just specify that net range to block. Also deny scs.msg.yahoo.com - scsc.msg.yahoo.com (socket servers) so Messenger won't be able to fall back on those. There still is a possibilty that there are further servers that can be used to login to so check it out. If you find any record the server who-is the ip to obtain it's net range and block that range as well. I doubt that the connection attempts to Yahoo! will pursue after so many attempts but you never know... Yahoo! Messenger is totally unlike any other IM client that I've ever used or programmed around. Hell, if somebody is trying to make a PEERTOPEER connection to you @ :5101 and they're blocked Yahoo! Messenger on your end will try and establish a PEERTOPEER session to them. I find stuff like this very strange but it goes hand-in-hand with getting around limitatons. If that doesn't work it will continue the session indirectly using the msg server you're connected to (which handles indirect pms with chat-users, login, chatrooms, just about everything Messenger-related in some way shape or form).

[Tiger Shark]

Mark:

Blocking login.yahoo.com won't help. Yahoo! has 3 protocols

Of course it helps if you block the ports outbound that those protocols use, which you should.... Login.yahoo.com blocks the port 80 attempts they will try and the other ports block the rest.

[Mark_Anderson]

Tiger:

Of course it helps if you block the ports outbound that those protocols use, which you should.... Login.yahoo.com blocks the port 80 attempts they will try and the other ports block the rest.

Login.yahoo.com has absolutely nothing to do with Yahoo! Messenger.

Login.yahoo.com is only 1 of the servers that you can use to authenticate yourself onto the network within the (old) YCHT protocol. Browser page services such as http://chat.yahoo.com's Java Chat use this protocol (YCHT). Yahoo! Messenger doesn't use YCHT. It only uses YMSG as it was built around this protocol only and for this protocol only. Though it is possible to hook into ypager.exe and override the YMSG server connectivity to connect to YCHT servers instead (which are completely separate)... that's already been done but that's not by initial design.

So no, again, blocking login.yahoo.com will do nothing from preventing Messenger from connecting (including not stopping a remote port 80 connection). YCHT clients would be affected by this but they could always choose another YCHT auth server.. like a YCHT cookie server (edit.yahoo.com etc) or one of the 4 jcs java chat servers to use for auth. Since Messenger isn't YCHT-based (not even 1%) there's no relationship. YCHT uses 0 auth encryption whereas YMSG protocol does. YCHT is also on the way out the door... according to rumors.

When I gave the alternate ports that Messenger will try and attempt to connect to Yahoo! MSG servers on... I specified the servers that you could use. If I connected to remote :80 on one of their MSG servers it would be no different as it would still be a MSG server and not a YCHT auth server.

cs23.msg.dcn.yahoo.com:80 will allow Yahoo! Messenger to connect to this particular MSG server given the proper authentication.

Connect to login.yahoo.com:80 and see what you get.

By blocking login.yahoo.com all you'd really be doing is denying Yahoo!'s web-based services such as email and their chat services. As I said there's still other ways around this. It would do no good for what he's trying to do (block Messenger connectivity).

[!mitationRust]

Originally posted here by AngelicKnight
Now that's how you block access! We don't have that problem either presently, but I'm trying to act preemptively so it doesn't become one down the road.

AngelKnight have you drafted any type of policy yet about the network under your control?

http://www.sans.org/resources/policies/
Browse through the content section to
*Need an Example Policy or Template?

Just a suggestion so at least once someone breaks ones law you can say that they agreed they would'nt do what one included in ones policy.

[Tedob1]

there's no such thing as doing something and its done. you have to keep watching, going threw the logs and when you see something you dont like fix it.

personally i like to use the pstool kit to keep an eye on the network (tried for sms but they didn't like the cost). at least once a week i use a bat file and pslist to list the processes running on everyone's mach. you get to know all the process that should be running. every time i see something running that shouldn't be i use psexec to spawn a shell on that computer go to the directory the program is in, rename all the DLLs to d11, kill it and use net send to tell the user that running such and such a program on a company computer is not permitted. if i see it again i make them a restricted user on their mach put them in a group on the fw that's so tight they can't even see streaming ads. this may seem like a candy ass way of going about it but i got tired of reminding some users of the policy and being lied to. to me its just not worth the hassel and watching the running processes also helps keep spyware from gettnig out of hand.

you said before that your fw does SPI and therefore the average user should be denied the ability to d/l exe's (pifs vbs etc.). so if they bring them in and you catch them once or twice they are going to know they are being watched. if you use psexec and run net send from their own computer they're never sure just who is watching them. but you'll be surprised how few people actually break the rules and require this kind of treatment.

if you search your log files every once in awhile and do as tiger shark recomended when you find something and let them know you found it you'll keep it under control