I have noticed the my MT is dropping a lot of TCP (ACK,PSH) traffic.
specific traffic:
input->DROP, in :LAN-WAN, out:(local), src-mac 00:09:f3:06:9f2a, prot TCP (ACK,PSH), 62.150.188.210:5101->192.168.0.254:1075,len 633
where:
192.168.0.254 is my MT etherport connected to the router
I have also noticed the same source mac address with TCP (SYN) / (RST) traffic but from a different ip address (84.58.35.244) and dst-port 21 (My MT’s FTP port)
I have tried to check the source mac to see if it was originating from my internal network but theres nothing with the same mac add. So, I am assuming it is comming from the same source but spoofing the ip address
How should I protect my system from such an attack if ever?
HELP!!!
Robert S.
Question is, am I being targeted by an attack? or is this traffic normal?
I just noticed yesterday that the source mac address belongs to my router/network gateway (192.168.0.1). although the traffic indicates different IP addresses in every dropped log the scr-mac is the same.
i wonder if anybody can explain to me what is this traffic that is being dropped by my MT.
Im guessing they are packets coming back from an outbound natted connection that the router no longer knows about. You could confirm this by sending all natted / masq traffic out on a different port range, ie 50000-65000. Port 5101, i think, is used for IM traffic and sometimes those gateways reply very late.
the firewall rule thats dropping the packet is the last entry (log and drop everything else) on my input rule set which is the standard hotspot ruleset from the MT docs/manuals. I am assuming that the packet has passed all the filtering (including p2p and virus) that I have implemented and just doesnt fit thus being dropped. As I have mentioned, I have the basic firewall ruleset from the MT docs and if this is not enough (no idea about source-filtering) may the good Lord help me!
I am not familliar with an attack “signature” so I dont have the slightest idea how to track them.
What I am sure of is that the only terminal that has access to my MT FTP is my personal unit inside my router network (router-192.168.0.1 / my pc - 192.16.0.100 / MT - 192.168.0.254) and my home pc with its WAN ip filtered (accept) on my MT input ruleset. So again, im asuming that the ftp traffic with an IP address from Timbuktu is an attempt to hack the MT!
Just this morning a new flood of TCP (ACK,FIN) from 63.150.131.25:80->192.168.0.254:1119 is being dropped on the log.
If this is an attempted attack, IM GLAD MY MT IS DOING IT’S JOB!!
If the port source and destinations doesnt make sense, the source ip addresses sure makes it look somebody halfway around the world is taking interest on my MT.
If what sam is saying is true, my local network (192.168.0.xx) has terminals always logged on with IM, then it just might be a prolonged reply going nuts! But why target the MT on 192.168.0.254!
Well, i’ll keep monitoring the system for any wierd traffic being dropped.
If you guys know of any helpfull firewall rules I need to implement, feel free to post for everybody to appreciate!
This is because the packet was natted back in but the connection isn’t in the tables anymore. The internal ip on the router is probably .254 right? The packet comes in and must have a rule in the forward chain but its hitting the input chain because there is no established connection anymore. OUT is local because it doesnt have the info on where to send it back to. I was wondering if your tcp timeout is too low or possibly a broken IM client somewhere in your network. Basically - if you sniff that source IP with packet sniffer you will see whats happening. Your seeing port 1119 and 1075 and those low numbers because masq typically starts at 1025 and works upwards ( I think ) .
We see this happen occasionally but typically on DNS replies that take more than 10 seconds (since thats our udp timeout).
I think this is making sense. Let me see if I got it right.
Incomming “natted packets” from my external router/gw (192.168.0.1 -NAT enabled) intended for a hotspot client are being dropped by my MT because the connection might have been disconnected (for any of the ff: reasons - logged-out / timed-out either by keep-alive/session/uptime). Ofcourse the target destination is the MT (masq packets) since it is intended for a hotspot client, but since connections cannot be established anymore the packets drops dead.
You are right about the time-outs, I have set idle-timeout to 10 mins. for most of my clients to conserve pre-paid time and eliminate useless traffic on the network.
Ofcourse this can only be confirmed by further scrutiny, meantime, I am assuming that my theory is correct unless someone proves otherwise.
Let me see if I got it right.