Rikunj wrote:
I really don't want them to do this and they are blocked as soon as
discovered.
As they should be.
All the clients are from DHCP IP's of 4 subnets of /24. Blocking them one by
one will eat up IP's.
You could have a range of IPs in your DHCP scope that are for systems that are not known to the DHCP server, i.e. a smaller scope like what you have now. Then set aside part of your existing scope to systems with known MAC addresses. This way you can ensure that the computers have a known IP for a given MAC. This will also solve the problem where the source IP changes, assuming that the same system is the problem.
Moreover they change the attacking src and dst ports making it hard to
pinpoint them.
Do they change the source and / destination ports or IP addresses? Either way, you should be able to get the DHCP server to log what MAC has what IP address. As this would be an on going log you could look back and see who had what IP at what time to find the MAC. With the known MAC of the attacker at any give time you could then look in your log to see what IP is associated with that MAC at present. Thus you know what IP an attacker has presently, if it has changed from the prior IP. You could even temporarily block this IP from being able to do any thing on the internet and thus provoking a call from them thus making them stand out in the crowd.
My real problem is to identify the curlprits.
How can I diferenciate a genuine traffic and a infected attack? What should
I look for?
Genuine traffic will follow patterns and access standard services. This will depend on what your client's orginizations are and what they do. Most orginizations will access FTP, SSH, Telnet, SMTP, DNS, HTTP, POP3, IMAP, NNTP, HTTPS and maybe a few others. If all the traffic that your clients are generating is internet based there is not much else that is common on the net aside form the ports that various IM clients use. You can fairly quickly pare out the traffic that is obviously standard (as far as ports to access any way) and be left with a small(er) list of ports that are being accessed to decide if it is genuine traffic or not. Unfortunetly this is a learning process for every administrator on every network. One tip that I can give you would be to have rule like the following:
iptables -t filter -A FORWARD -p tcp --dport 143
You would want this rule, with out a jump target (-j...), to act as a counter to see if you do have any traffic like this at all with out interfering with the rest of your firewall. If you put such rules above any other rules that would effect the FORWARD chain you will get a decent counter. I would be tempted to modify the rule slightly, as such:
iptables -t filter -A FORWARD -i $Client_1 -s $Client_1_Subnet -p tcp --dport 143
This will let you know how much traffic to port 143 (IMAP) Client #1 is sending.
Grant. . . .
