[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sheflug] ICQ and IRC




> Dear All
> 
> After several years of being broken into after using ICQ and IRC I now
> run several security apps which tell me when someone is having a go at
> me - yet again.
> 
> For some reason the ICQ people who I think are AOL are particularly
> bad when it comes to network security.  The other day I thought I'd
> have a quick look into ICQ on Linux and tried to connect to their
> server with Kicq.  Here's a small part of /var/log/messages that you
> can see below.  It may well be that this is the ICQ server trying to
> authenticate something with my machine.  However, anything of this
> sort is best discouraged or disabled over a network if it can be
> done.........
> 

[snip log dump]

The IPs you give, 205.188.153.108 and 2095.188.153.104 are two of the ICQ 
servers trying to talk to your ICQ client. Quite frankly, sating "this sort 
is best discouraged..." is probably not what you want with a client/server 
system like ICQ.

Without two way comms between the client and server...
	- You can't login
	- You can't be notified of new users
	- You can't receive messages that are sent through the server
	- The client will log you off as ICQ keep-alives fail
	- etc...
In short, you can't use ICQ.

You need to open the firewall so that UDP source port 4000 connections are 
allowed...I can't give you what IP's to allow as I don't know (I open 4000 up 
for anywhere, and I've never had an attack come in with a hole like that, 
besides - for me that's secure enough with the rest of the firewall *for me*).

Licq gives a little network window so you can see what packets are being sent 
all over the place. The comms between ICQ server and client are mostly 
limited to that list above. When you send a message to someone, your client 
will eastablish a TCP connection to the recipients client (unless you send 
message via server).

You will get a log entry for every UDP packet received - unlike TCP, UDP is 
connectionless and there is no concept of "connection opened" and "connection 
closed". This is why you see all the packets in the dump - the protocol 
doesn't anything like TCP's ACK's and SYN's to work out what the connection 
is doing and which way its going. For every packet your client sends to the 
server, the server will respond with an ack...here's Licq's network dump, for 
instance:

	14:29:11: [UDP] Requesting logon (#9061)...
	14:29:11: [UDP] Resolving icq.mirabilis.com...
	14:29:12: [UDP] ICQ server found at 205.188.153.111:4000.
	14:29:12: [UDP] Creating local server.
	14:29:12: [UDP] Opening socket to server.
	14:29:12: [UDP] Ack (#9061).
	14:29:14: [UDP] Server says hello, we are at 212.56.112.253.
	14:29:14: [UDP] Updating contact list (#9062)...
	14:29:14: [UDP] Sending invisible list (#9063)...
	14:29:14: [UDP] Sending visible list (#9064)...
	14:29:14: [UDP] Ack (#9062).

then later on ...

	14:33:07: [UDP] Pinging Mirabilis (#9067)...
	14:33:08: [UDP] Ack (#9067).
	14:35:07: [UDP] Pinging Mirabilis (#9068)...
	14:35:08: [UDP] Ack (#9068).
	14:37:07: [UDP] Pinging Mirabilis (#9069)...
	14:37:08: [UDP] Ack (#9069).

It's fully UDP. If I block (as you have done) UDP source port 4000 I couldn't 
log in as the server couldn't send the Ack's or the Hello's. Or my client 
would think my connection to the server's died and log me off as the Ping's 
the client sends wouldn't be Ack'd by the server.

Know thy protocols :)

Chris...

-- 
Chris Johnson            \  "If not for me then, do it for yourself. If not
sixie@nccnet.co.uk        \  for then do it for the world." -- Stevie Nicks
www.nccnet.co.uk/~sixie/   ~---------------------------------------+
Redclaw chat - http://redclaw.org.uk - telnet redclaw.org.uk 2000   \______


---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.