Wanz hello,
The first message means a public IP address (could be from any one of various registries) is trying to send a packet to a private IP address in your organization, in port 25 (SMTP). This does not necessarily indicate a DOS attack, and if the firewall is blocking the packet then it's OK.
The second message means a public IP address is trying to send a packet to another public IP address, in port 135. Microsoft's DCOM (Distributed, i.e. networked, COM) Service Control Manager (also known as the RPC Endpoint Mapper) uses this port in a manner similar to SUN's UNIX use of port 111. The SCM server running on the user's computer opens port 135 and listens for incoming requests from clients wishing to locate the ports where DCOM services can be found on that machine. Port 135 is certainly not a port that needs to be, or should be, exposed to the Internet. Hacker tools such as "epdump" (Endpoint Dump) are able to immediately identify every DCOM-related server/service running on the user's hosting computer and match them up with known exploits against those services.
The third message means a private IP address in your organization is trying to send a packet to a public IP address, in port 53 (DNS). This does not necessarily indicate a DOS attack, and can indicate a simple DNS query. I can recommend opening port 53 UDP (for DNS queries) ONLY to the DNS servers you use (internal or external) in your organization.
Hope I helped...
The Destination:192.168.1.1 is for Netgear Routers. Not sure of the significance in this instance
You obviously need to locate the device with the ip address of the source/target private address, and find out what the user was doing at the time stated in the report.
Easy to do if the ip addresses are all static, harder to do if they are dynamic addresses. If they are dynamic, then providing the time they are valid is more than a few days, you could interigate the dhcp router for their mac addresses, and watch the traffic for a few days to see if there is a pattern.
I have to agree with celtic, it doesn’t necessarily mean a dos attack, it could simple be an acl rule that is blocking the traffic as celtic suggested.
If it is bothering you, you should investigate further. The time spent won’t be wasted as it will give you a more in-depth view of you internal network.
Dave
Hi,
I’d be mostly worried about the first hit:
TCP Packet – Source:144.120.8.89,39341 Destination:192.168.1.1,25 – [DOS]
You should never get on your outer interface packets to private destination 192.168.1.1, unless there is misconfigured router in your nearest proximity, that means yours or your ISP router… Considering the second and third hits, I will agree with Celtic – they are probably not a problem at all.
Good luck,
Petko
Doesn’t the line TCP Packet – Source:144.120.8.89,39341 Destination:192.168.1.1,25 – [DOS] indicate that the
Source:144.120.8.89,39341 has an address translation (39341) session originated from the private address?
Hi, Dave
I don’t see why using port 39341 means that an address-translation session is initiated. I’d rather suppose an address translation in the second line:
TCP Packet – Source:210.7.0.36,3473 Destination:210.7.12.23,135 – [DOS]
where some private IP from one subnet is routed through a NATting device to a second subnet in the same organization, and because port 135 is a “well-known hacking port”, whatever it means, the firewall is stopping the packet.
Well, if these records are caught on the internal interface of the firewall, then there is a second explanation – somebody took a laptop with a static primary network configuration (144.120.8.89) into the LAN with private range IPs – but then nameserver and gateway settings should not work. Or the third one (really a more probable variant of the 2nd) – they have a “mixture” of private and public IPs on the same LAN, private using NAT and public using routing – pretty bad idea, but happens. In this case they should re-configure the firewall to allow these connections and not to complain about them.
BR,
Petko
i didn’t get a word of whatever you all have discussed though i am facing the same problem.
Hi, Creative…
The bottom line, as I see it, is that probably no one is attacking Wanz’ firewall. Just some “false-positives”, you have lot of them on any firewall / IDS, however low sensitivity you set. At least all the time you will have some late responce packets, which will miss the period during which a firewall is keeping there connection open and waiting…
BR,
Petko