Seeing packets from external IP address on protected internal interface?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
If you're seeing public IPs on the internal segment, that should prove that no translation is happening...which would mean the activity is benign. Forwarded traffic would be translated, right? Check the logs on the destination system and see if you're seeing any traffic on either port. This is also another reason why I recommended using a packet sniffer.
Yesterday, I setup a filter on iptraf to capture the IP addresses of interest.
I've managed to lose the screen capture that I had however the capture indicating that 192.168.0.168 initiated a connection to 212.x.x.x.
So this suggests to me, that the logs I'm seeing are benign.
Unixfool, you say you don't have a FORWARD rule - I thought a this rule was needed when using NAT?
Looking part of the entry:
OUTPUT tells me that this is passing through your filter.
SRC=220.127.116.11, says that this did not originate on your network. The IP in question belongs to: js-pd05-eu.revsci.net.
PROTO=TCP SPT=80 DPT=2011 - says that port 80 of that system is connecting to port 2011 of your system.
Assuming you have this port blocked from inbound connections, my interpretation of this is that your machine at 192.168.0.168 made a connection to 18.104.22.168's port 80 (web site) and this was the return traffic to your machine which would be passed by the established, related packet criteria. In your initial post, you stated that you are seeing a lot of packets to inbound high number ports on your system. To me, again these look like possible responses to web browsing. Inbound connections to other ports, like 23, 53, 80, 143 suggest an attempt to access a service, which suggests your NAT setup may be port forwarding them.
Yes, that's what I seem to have learned from sniffing with iptraf.
1. You're maybe looking at return traffic. You need to verify that that is indeed the case.
2. Your NAT setup might be busted, misconfigured, or maybe you didn't take bidirectional logging into account (for web traffic, at least). IMO, you want to see both inbound and outbound web traffic. You need to check your NAT setup to ensure it is properly configured.
3. Something is NOT right with that web traffic. If IP 22.214.171.124 is a web server and your 192.168.0.168 is a client, the client's port will be ephemeral. Based on the logs you provided, the client port isn't changing, which is weird. That's why I think this isn't normal web traffic. I think it might be something other that web traffic that just happens to be using port 80 as a conduit simply because port 80 is almost always allowed by a network firewall.
Unixfool raise an excellent point about masquerading on port 80 because it normally passes through firewalls. Before we can rule this one out, we need to be sure that you can tie the traffic back to a process and that the known process is valid and proper. It looks like the destination, 126.96.36.199, DOES NOT have a functional web PAGE, but it does have a web SERVER, Apache Tomcat to be precise. If I recall, attempting to connect to it on port 80 returns a 404 error. Unless this IP is known to you and this makes sense, as in it is some sort of development site for your applications, I would be suspicious of the traffic.