Information Security & US & Life & Love & Fashion & Hacking & Passion

IM Server
The IM server maintains the directory of user accounts, keeps track of who is
online, and, in most cases, routes messages among users. The IM server operates in
real time, sending messages back and forth between two users as they finish typing
each line of text. The servers also pass real-time information about the availability
of various users in the directory, such as when they come online and change their
status message.
Each IM server communicates with its clients over an assigned port number across
the Internet. But IM clients however, can login using other ports when the default
port is blocked by a deny policy. Typical port numbers include those shown in the
following table:
IM Application Service Port Numbers Proxies
AIM 5190 SOCKS 4, SOCKS 5,
HTTP, HTTPS
ICQ 5190
YMSG 50501 (443 and 80)
1.In addition to port 5050, make sure traffic is permitted on
ports 443 (HTTPS) and 80 (HTTP).
SOCKS 4, SOCKS 5,
HTTP
MSN Messenger 1863 SOCKS 4, SOCKS 5,
HTTP

SYN Cookie is a stateless SYN Proxy mechanism you can use in conjunction with
the defenses against a SYN Flood attack described in “SYN Flood” on page 40. Like
traditional SYN proxying, SYN Cookie is activated when the SYN Flood attack
threshold is exceeded, but because SYN Cookie is stateless, it does not set up a
session or do policy and route lookups upon receipt of a SYN segment, and
maintains no connection request queues. This dramatically reduces CPU and
memory usage and is the primary advantage of using SYN Cookie over the
traditional SYN proxying mechanism.
When SYN Cookie is enabled on the security device and becomes the
TCP-negotiating proxy for the destination server, it replies to each incoming SYN
segment with a SYN/ACK containing an encrypted cookie as its Initial Sequence
Number (ISN). The cookie is a MD5 hash of the original source address and port
number, destination address and port number, and ISN from the original SYN
packet. After sending the cookie, the device drops the original SYN packet and
deletes the calculated cookie from memory. If there is no response to the packet
containing the cookie, the attack is noted as an active SYN attack and is effectively
stopped.
If the initiating host responds with a TCP packet containing the cookie +1 in the
TCP ACK field, the device extracts the cookie, subtracts 1 from the value, and
recomputes the cookie to validate that it is a legitimate ACK. If it is legitimate, the
device starts the TCP proxy process by setting up a session and sending a SYN to
the server containing the source information from the original SYN. When the
device receives a SYN/ACK from the server, it sends ACKs to the sever and to the
initiation host. At this point the connection is established and the host and server
are able to communicate directly.

In addition to limiting the number of concurrent sessions from the same source IP
address, you can also limit the number of concurrent sessions to the same
destination IP address. One benefit of setting a source-based session limit is that it
can stem an attack such as the Nimda virus (which is actually both a virus and a
worm) that infects a server and then begins generating massive amounts of traffic
from that server. Because all the virus-generated traffic originates from the same IP
address, a source-based session limit ensures that the firewall can curb such
excessive amounts of traffic.