Getthings Posted September 17, 2006 Report Share Posted September 17, 2006 Hi allfirstly many thanks to the writers of uTorrent, its superb!Secondly, apologies if this has been posted before, I did a search for fragmented packets and found 1 thread where someone had to allow fragmented packets on their firewall to get a green light on uTorrent. I have been using Comodo firewall for a few days and am very impressed with how much it can do and the information it gives on my connection.Under the settings for Advanced Attack Prevention and Detection I have ticked the following (amongst others):Block fragmented IP datagramsDo Protocol AnalysisThe Logs now report that many many packets are blocked as they are either fragmented IP packets (portless but it says using UDP) or fake/malformed UDP packets.These packets are trying to leave my PC, the source IP is always my PC's IP.The port in use by the UDP packets is my uTorrent port.uTorrent is beavering away happily while this happens and I am suffering no issues at all using uTorrent, so...Is this expected behaviour?If you know why it will be much appreciated.thanksps the log shows these packets have a "High" severity. Link to comment Share on other sites More sharing options...
Ultima Posted September 17, 2006 Report Share Posted September 17, 2006 Are you using DHT or resolving peer IPs? Link to comment Share on other sites More sharing options...
Getthings Posted September 17, 2006 Author Report Share Posted September 17, 2006 DHT is enabled.The torrents I am downloading now dont use DHT, they display "not allowed" for DHT. They work great.I just grabbed a torrent to test DHT and it is immediately responsive, finding lots of DHT clients and downloading very fast. Link to comment Share on other sites More sharing options...
Ultima Posted September 17, 2006 Report Share Posted September 17, 2006 Probably Comodo being overly verbose with its logs. DHT and resolving peer IPs generate a lot of UDP packets, but I'm not sure why it'd say "fake," "malformed," or "fragmented." Link to comment Share on other sites More sharing options...
Getthings Posted September 17, 2006 Author Report Share Posted September 17, 2006 just spotted at the end of the UDP log entries (viewed in a little window), it saysReason: UDP packet length and the size on the wire (1486 bytes) do not matchMaybe the IP (using UDP) log entries are due to the same issue, they sayReason: Fragmented IP packets are not allowed.Every IP error is followed by a UDP error.I get about 20 of these pairs of errors every minute.edit: all are from my PC's IP to numerous other IP's that are repeated. Link to comment Share on other sites More sharing options...
Switeck Posted September 17, 2006 Report Share Posted September 17, 2006 What modem, router, and network card brands/models are you using?The corruption may be caused by them...or their firmware/software. Link to comment Share on other sites More sharing options...
Ultima Posted September 17, 2006 Report Share Posted September 17, 2006 I doubt it'd be those, though, as the packet gets to them after it gets past the firewall, I believe, and he said they're outgoing packets (source IP = computer's IP). Link to comment Share on other sites More sharing options...
Switeck Posted September 17, 2006 Report Share Posted September 17, 2006 Ok, then strange as it may seem...it could be the software firewall creating the very malformed packets it's detecting. Link to comment Share on other sites More sharing options...
Getthings Posted September 17, 2006 Author Report Share Posted September 17, 2006 Just in case it helps My Router is a Netgear DG814, using the onboard NVidia LAN card from my Asus A8N-E motherbard. Latest NForce drivers (6.86).Whats strange is this guy complained of the same thing with the M0n0wall Router but on inbound traffic only. It limited his uTorrent experience unless he allowed the packets.http://forum.utorrent.com/viewtopic.php?id=8625He states that when fragmented packets were allowed through, his download speed went up 30%.I wonder if he did have an outbound fragmented issue as well ?Why dont I detect inbound fragmented packets?I am connected to 42 uTorrent clients (with one torrent), 34 of whic are latest version.Edit 2: I do indeed receive incoming fragmented packets. I missed them purely by accident as I have to click on each entry to see what the reason is. The log appears to only be in memory, I cannot find it on the disk so I'm stuck with this method of viewing log entries.For kicks, I just tried to allow the packets through. I had 186 active IP connections (70K/Sec on 8MBit) so wasnt maxed out for downloading but the uplink was saturated.Allowing the packets didnt change anything, download speeds remained almost the same.After 10 mins I have 185 connections.for clarity, here is the error message again:Reason: UDP packet length and the size on the wire (1486 bytes) do not matchthanksedit:A strange thing occured when I turned off the 2 filters to allow fragmented/malformed packets!My log started to fill with blocked outbound connections (non local) from my port 137 (netbios).Those filters could be preventing a netbios hole being exploited.Re-enabling the filters saw an almost immediate stop to the log entries for port 137.Luckily the outbound packets were blocked anyway!As the packets stop when I increase the filtering, it looks like they are provoked from the outside.WoooIn case it matters:To my knowledge I dont have any nasties in the system. I regularly use/update Avast!, Protowall, Adaware, Spybot (with teatimer enabled), Spycatcher, Spyware blaster and Spyware Guard.Merged double post(s):I'd better clarify my latest findings!I turned on another firewall setting to verify the checksums of all packets.Since then I only get fragmented incoming IP (no UDP) packets and NONE outgoing, IP or UDP like before.Before enabling that setting, I was only getting outgoing fragmented IP+UDP packet pairs, NONE incoming.I now only see incoming bad TCP checksum and incoming Fragmented IP packet errors in the log.Perhaps I am under attack, these bad checksum/fragmented packets could be being altered on the way to me or are generated in the same way mine are.These new logged packets are not using uTorrents port for incoming.Perhaps they are processed and then hijack the uTorrent port to get out and spread whatever nastiness they bring when they arent blocked by the Checksum Filter?The incoming packets could be responsible for the port 137 (netbios) packets trying to leave my network too?after more thought, this looks like a nasty inside my PC.If anyone spots errors and can correct what I am saying please do.All ports are blocked incoming except my uTorrent port, verified this with many online tests.The new incoming connections being blocked are using other ports.The only way I can see those ports connecting through my hardware firewall is if my PC initiated the connection.That sound slike something is in my PC.Would you agree?pls ignore the last post, the outgoing TCP/UDP fragmented packets etc have started again.So with all the security filters active I now have the firewall detecting Incoming:Blocked fragmented IP packets, no port associated.very few of these now.Outgoing:Blocked fragmented IP packets, no port associatedBlocked Fake or Malformed UDP packets, source is my uTorrent portThis looks like uTorrent really is the source of the bad packets.I'm about to stop utorrent and see if the log traffic halts over the next half hour.Its been over half an hour and I have between 1 and 3 outgoing packets per second average which are blocked with the message:Access Denied, ICMP = Port UnreachableNo port is specified.Undoubtedly this is due to my uTorrent port being closed now.In the half hour that has passed, there has been a constant stream of attempted connections to a whole load of different IP'sie:71.98.87.213203.198.91.28218.175.36.54218.166.105.10361.220.148.2060.165.48.10860.52.21.15080.213.81.36 .....uTorrent was definitely closed down over 1/2hr ago (confirmed with task manager and the last 4 remaining utorrent connections were closed manually by me using Comodo firewall).there are no other connections (netstat confirms this) so these packets are being generated by something on my PC that wants to use the uTorrent port.So again I am back to thinking there is something else trying to get out from my PC.Any thoughts please?EDIT by silverfire: Not one but FOUR posts in a row? You clearly knew how to use the edit function, so someone needs to smack you upside the head with a book on forum etiquette before one of the admins decides to ban you for bad behavior.Edit by Getthings:Sorry I didnt realise that was an etiquette issue. Link to comment Share on other sites More sharing options...
Switeck Posted September 18, 2006 Report Share Posted September 18, 2006 Get HijackThis, have it create a startup log, and do research using GOOGLE on what it finds....You'll be lucky if it only finds ONE nasty. Link to comment Share on other sites More sharing options...
Getthings Posted September 18, 2006 Author Report Share Posted September 18, 2006 hehok, I'll do that.I last ran Hijack this about a week ago and it was clean.This firewall (Comodo) is pretty cool, it also blocks TCP packets that use SYN ACK FIN (Invalid flag combination) which are a known way to get packets authenticated by many firewalls now a bit later....Hijackthis didnt report anything of interest.(I deleted the log to make this more readable).11:14am (UK)I've observed some interesting behaviour.1) after rebooting, without running uTorrent, many outgoing connection attempts are blocked (as before after stopping uTorrent).I believe these are only acknowlegment packets for received packets.It looks like the firewall blocks outgoing but not incoming packets when uTorrent isnt running.So the last issue with continuous outgoing connections after closing uTorrent isnt a problem.2) The fake/fragmented/malformed packets only start after I have started uTorrent.I would say they are possibly... a) uTorrent sending packets that are too big to be transmitted as a single packet (ie bigger than the MTU) so they get split into 2 packets somewhere but the size data becomes incorrect. uTorrent labelling the size of some UDP packets wrongc) uTorrent getting some UDP packet contents wrongd) a vulnerability in uTorrent is being exploited and malcrafted packets are being sente) Torrent users or bots getting my IP by using bittorrent and proceeding to get info/hack.This last one doesnt seem as likely as I am also sending fake/fragmented or malformed packets. This points the finger more at uTorrent.3) To trap what is happening with the netbios connections I created a rule to block outbound netbios ports 136,137,138 My PC tried to send UDP packets out to numerous IPs on port 138, they were blocked and logged.I changed the rule to block in/out ports 136,137,138Torrent clients tried to connect to port 137 but are now blocked and logged.Previously they did connect and up to 96k of traffic went!Even with no netbios packets coming in, my PC still tries to send some netbios packets on port 138 to torrent clients IPs (while all incoming netbios packets are blocked).Could this be caused by an exploited vulnerability in uTorrent?Could these clients be modified clients designed to collect data?Netbios requests shouldnt be able to get past my router so there would need to be a exploit in use to start the connection.I decided to try and find out as much as I can.These are actual clients I found trying to connect via netbios, blocked in the firewall log.I cross checked the IPs with uTorrent and found the clients in use.84.13.225.245 connecting via port 137 - Bitcomet 0101650.53.74.72 connecting via port 137 - Bitcomet 005784.13.36.145 connecting via port 137 - Bitcomet 0101203.106.251.168 connecting via port 137 - Bitcomet 0070They all are looking to be Bitcomet clients.So either they are all modified clients, Bitcomet does use a netbios hack or I am being probed by a torrent user/bot.I havent found any evidence to support that Bitcomet does use netbios so for the moment that leaves a modded client/probe of some form or an exploited vulnerability in uTorrent. Link to comment Share on other sites More sharing options...
Switeck Posted September 18, 2006 Report Share Posted September 18, 2006 I can say that if µTorrent is generating traffic on ports 136-139 that it's just because someone is using that as an incoming port for their bittorrent client. Link to comment Share on other sites More sharing options...
Getthings Posted September 18, 2006 Author Report Share Posted September 18, 2006 its my ports I'm referring to, not theirs. Link to comment Share on other sites More sharing options...
Switeck Posted September 18, 2006 Report Share Posted September 18, 2006 Is it like this:your ip:137 -> bitcomet ip:whatever #or:your ip:1000-5000 -> bitcomet ip:137?I don't know why you're not sending out on ephemeral ports 1000-5000.Only thing I can figure is your firewall is doing crazy things to prevent that...sometimes. Link to comment Share on other sites More sharing options...
Getthings Posted September 18, 2006 Author Report Share Posted September 18, 2006 Its like the first onemy ip:138 -> bitcomet ip:whatever Port 138 is used for outgoing, 137 for incoming netbios connections.edit:Let me try and make this a little clearer.Something is making my machine talk via netbios.My machine does use all other ports for uTorrent as it needs to, theres no restriction in that.The communication via netbios only occurs when I use uTorrent and has been found to be coming from/to the same IP's as certain Bitcomet clients. Link to comment Share on other sites More sharing options...
Valharick Posted November 15, 2006 Report Share Posted November 15, 2006 I'm having a similar problem to this, except in addition, my router also resets every 20-30 minutes. If I turn uTorrent off, the disconnects stop. The router firewall shows both SYN Floods and & Fragmented Packets (both of which stop when uTorrent is off). I've read up on the SYN Floods but haven't come across much in the way of preventing them.Thoughts? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.