internal ip's showing up in firewall logs - Page 3

IHateShuttle · 07-27-2011, 04:35 PM

It is also possible that the source IP has been spoofed. This could be external traffic trying to get in by masquerading as internal traffic. The standard ingress filter in the firewall should not allow any traffic to come in the external interface with a private IP. I would think that Untangle comes with such a rule, correct me if I am wrong.

The port numbers are above 1024 on both sides which also suggests this is not normal traffic.

I'm not aware of a method for uncovering the real IP of spoofed traffic. If this is the case, all you can do is block it.

It looks like the connection was indeed blocked.

sky-knight · 07-27-2011, 04:37 PM

If it is spoofed traffic, it would have to source from somewhere, and it's destined to the internal address. So without a port forward on that port, it can't be external traffic.

I've seen spoofed traffic hit a web server, that stuff is rather obvious. Untangle's firewall doesn't block anything by default. So unless you create a rule that drops stuff sourced from a private IP range, it will pass right through the NAT engine and land on the server. That is, assuming the destination addressing is all correct.

*Edit* I keep forgetting that this is an untangle bridge and the devices in question have public addresses. I'd inspect the destination machine for a service running on port 7408. If there isn't anything there, then yeah that seems like spoofed traffic.

I'd make a new firewall rule, source interface External, source address (CIDR range for public ranges behind Untangle), destination address (same CIDR range), block and log.

That will flag if this traffic is indeed coming in from the outside.

crazylegs · 07-27-2011, 07:10 PM

The destination machine is listening on 7408 and 8016. I'll make the rule and head home. Seems like the blips only occur later at night, so hopefully I'll have added the rule in time. Thanks again, both of you!

IHateShuttle · 07-28-2011, 08:52 AM

In the name of curiosity could you tell us what process is listening on those ports? It's like a soap opera and I want to know how it ends.

crazylegs · 07-28-2011, 11:13 AM

Fair enough, fair enough. It's WebOPAC. So now I guess I'll track down what the machine that's initiating the connection thinks it's doing.

07-27-2011, 04:35 PM	#21 (permalink)
IHateShuttle Untangler Join Date: Jul 2009 Location: Left Coast Posts: 70	Spoofing It is also possible that the source IP has been spoofed. This could be external traffic trying to get in by masquerading as internal traffic. The standard ingress filter in the firewall should not allow any traffic to come in the external interface with a private IP. I would think that Untangle comes with such a rule, correct me if I am wrong. The port numbers are above 1024 on both sides which also suggests this is not normal traffic. I'm not aware of a method for uncovering the real IP of spoofed traffic. If this is the case, all you can do is block it. It looks like the connection was indeed blocked.

07-27-2011, 04:37 PM	#22 (permalink)
sky-knight Join Date: Apr 2008 Location: Phoenix, AZ URLs submitted: 8 Posts: 15,460	If it is spoofed traffic, it would have to source from somewhere, and it's destined to the internal address. So without a port forward on that port, it can't be external traffic. I've seen spoofed traffic hit a web server, that stuff is rather obvious. Untangle's firewall doesn't block anything by default. So unless you create a rule that drops stuff sourced from a private IP range, it will pass right through the NAT engine and land on the server. That is, assuming the destination addressing is all correct. Edit I keep forgetting that this is an untangle bridge and the devices in question have public addresses. I'd inspect the destination machine for a service running on port 7408. If there isn't anything there, then yeah that seems like spoofed traffic. I'd make a new firewall rule, source interface External, source address (CIDR range for public ranges behind Untangle), destination address (same CIDR range), block and log. That will flag if this traffic is indeed coming in from the outside. __________________ Rob Sandling, BS:SWE, MCP Intouch Technology Phone: 480-272-9889 rob@intouchtechllc.com UntangleAppliances.com Phone: 866-794-8879 Last edited by sky-knight; 07-27-2011 at 04:41 PM..

Protect

Filter

Perform

Connect

Manage

Add-Ons

07-27-2011, 07:10 PM	#23 (permalink)
crazylegs Master Untangler Join Date: Mar 2009 Posts: 194	The destination machine is listening on 7408 and 8016. I'll make the rule and head home. Seems like the blips only occur later at night, so hopefully I'll have added the rule in time. Thanks again, both of you!

07-28-2011, 08:52 AM	#24 (permalink)
IHateShuttle Untangler Join Date: Jul 2009 Location: Left Coast Posts: 70	In the name of curiosity could you tell us what process is listening on those ports? It's like a soap opera and I want to know how it ends.

07-28-2011, 11:13 AM	#25 (permalink)
crazylegs Master Untangler Join Date: Mar 2009 Posts: 194	Fair enough, fair enough. It's WebOPAC. So now I guess I'll track down what the machine that's initiating the connection thinks it's doing.