Blocking messengers

I know there's different options to achive the same goal. Thats not what I was asking. Either way, best bet is to block their logon servers I guess. Simplest anyway, and doesn't give me a headache.

Thanks for all the replies though!

If you use a NIDS you can also create rules to look for the SYN's on the default port. This will catch the initial SYN against the, (blocked), default port. The you can take a womble down to the offending users desk and slap the little ******* for contravening policy.

Works for me...... :D

If you use a NIDS you can also create rules to look for the SYN's on the default port. This will catch the initial SYN against the, (blocked), default port. The you can take a womble down to the offending users desk and slap the little ******* for contravening policy.

Works for me...... :D

Hey Nebulus,

I didn't know IDS's could block traffic as well. What IDS were you referring to? I might check out that option....then supplement that with Tiger Shark's idea. :D

Thanks everyone!

Hey Nebulus,

I didn't know IDS's could block traffic as well. What IDS were you referring to? I might check out that option....then supplement that with Tiger Shark's idea. :D

Thanks everyone!

I am wanting to say snort can do this (not 100% sure, haven't really tried to do this very often). When I stated this, I had ISS RealSecure in mind, but really I think that most modern NIDS have this capability. It isn't anything special really, it just sends a spoofed packet to the source and destination (pretending to be one or the other) and sends a reset. Both sides will think there was a communication or some other kind of error and drop the connection. If it is something you are not seeing very often it would be safe to do this, but if you were not careful and you set it up to do that on an event that is frequently triggered, you will wind up amplifing the amount of traffic (for every packet it triggers off of, it generates 2 packets to kill the connection) which could do more harm than just letting the event go without resetting the connection.

Hope this helps,

/nebulus

I am wanting to say snort can do this (not 100% sure, haven't really tried to do this very often). When I stated this, I had ISS RealSecure in mind, but really I think that most modern NIDS have this capability. It isn't anything special really, it just sends a spoofed packet to the source and destination (pretending to be one or the other) and sends a reset. Both sides will think there was a communication or some other kind of error and drop the connection. If it is something you are not seeing very often it would be safe to do this, but if you were not careful and you set it up to do that on an event that is frequently triggered, you will wind up amplifing the amount of traffic (for every packet it triggers off of, it generates 2 packets to kill the connection) which could do more harm than just letting the event go without resetting the connection.

Hope this helps,

/nebulus

Just an FYI for those that didn't know: AIM does, in fact, allow you to search and connect on other ports. The other day, I tried connecting with the default port, and it would not allow me to contact the login server. Next, I went into the configuration - where you can change to go through a proxy and so on... Here, I found an option to scan for a port to connect through, and low and behold, it connected over port 21! UGH!

Just an FYI for those that didn't know: AIM does, in fact, allow you to search and connect on other ports. The other day, I tried connecting with the default port, and it would not allow me to contact the login server. Next, I went into the configuration - where you can change to go through a proxy and so on... Here, I found an option to scan for a port to connect through, and low and behold, it connected over port 21! UGH!

Nebulus: No point in using the IDS to drop both sides of the connection, (Yes Snort will do this if the rule is written to do it and there is also a test facility that allows a message to be sent to the two machines I believe - I gotta look into that in a minute..... ;) ), since the client will assume it is dropped at the firewall and allow the alternative connection to take place.

I'm gonna take a look at the message thingy, test it and see what it does. The I might add the message part to a rule for these chat proggies that will be received by the offending user telling them to quit or die...... :D . I'll see if it works and get back to you all.

Pooh..... :(

I use a custom version of snort that does not include flexresp therefore it doesn't recognize the react keyword and fails out on the rule....... Also, this used to send a message to the browser rather than a windows messaging message, (which would be real nice), so it is designed to limit web access more than anything else - shame really... I coulda had a lot of fun with my (L)users...... :D