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.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Seeing packets from external IP address on protected internal interface?
I'm using iptables, and have a box with two interfaces sat on the web.
eth0 is the internal interface.
eth1 is the external interface.
I'm seeing packets from an external IP address, on the protected internal interface.
How could this be happening? Are my rules incorrect perhaps?
Logwatch reports the following for eth0:
Code:
Logged 1722 packets on interface eth0
From 172.16.x.x - 145 packets to tcp(80,143,443)
From 172.16.x.x - 205 packets to tcp(80,443)
From 172.16.x.x - 589 packets to tcp(80,143,443)
From 172.16.x.x - 13 packets to tcp(80)
From 172.16.x.x - 693 packets to tcp(80,143,443,8443)
From 178.96.x.x - 32 packets to tcp(80,143,443,5228)
From 178.106.x.x - 37 packets to tcp(80,143,5228)
From 178.107.x.x - 3 packets to tcp(5228)
From 178.107.x.x - 5 packets to tcp(5228)
^^^^^^^^^^^
It's those 178.x.x.x addresses that concern me?
And for eth1:
Code:
Logged 117 packets on interface eth1
From 24.x.x.x - 1 packet to udp(25923)
From 41.x.x.x - 7 packets to tcp(25)
From 41.x.x.x - 2 packets to tcp(22,23)
From 41.x.x.x - 2 packets to tcp(22,23)
From 41.x.x.x - 1 packet to tcp(23)
From 41.x.x.x - 1 packet to tcp(23)
From 41.x.x.x - 2 packets to tcp(22,23)
From 41.x.x.x - 1 packet to tcp(23)
From 58.x.x.x - 4 packets to tcp(63036)
<snip>
iptables -nL |grep 5228
Shows nothing open on port 5228
Code:
iptables -nL |grep 143
ACCEPT tcp -- 0.0.0.0/0 ext.ip.addr tcp dpt:143 state NEW
iptables -nL |grep 80
ACCEPT tcp -- 0.0.0.0/0 ext.ip.addr tcp dpt:80 state NEW
have you done an ip to domain look up? I would see where the IP's are located before I start sweating. It could be something to do with NAT translation and your router...
I have a question for the iptables experts out there.
I previously asked this question on this forum here.
But no satisfactory answer was given.
I have an iptables firewall, where eth0 is the internal interface, and eth1 is the external interface. eth1 is connected directly to the internet, and this box is also a NAT router.
I am seeing traffic sourced from external IP addresses on eth0 (internal interface) - how can this be? (see logs below)
Is there a rule I can add to prevent this?
Code:
Logged 663 packets on interface eth0
From 74.217.240.81 - 181 packets to tcp(2666,2674,2683,2685,2689,2694,2700,2704,2796,2799,2801,2806,2811,2852,2860,2863,2868,2876,2877,2882,2886,2887,2892,2920,2926,2930,2942,2948,3251,3253,3261,3268,3274,3286,3290,3293,3295,3300,3380,3425,3461,3559,3621,3659,3686,3711)
From 74.217.240.83 - 14 packets to tcp(1572)
From 212.118.226.90 - 174 packets to tcp(2365,2382,2462,2467,2479,2485,2522,2539,2550,2570,2599,2604,2610,2627,2637,2642,2668,2684,2686,2690,2696,2701,2743,2751,2763,2783,2802,2807,2813,2861,2875,2884,2893,2921,2941,2957,2969,2986,3015,3041,3045,3051,3195,3240,3241,3252,3254,3269,3287,3301)
From 212.118.226.91 - 271 packets to tcp(1408,1444,1484,1506,1521,1528,2300,2356,2364,2384,2460,2466,2470,2484,2523,2538,2544,2569,2575,2598,2601,2626,2643,2647,2742,2744,2753,2757,2762,2766,2773,2781,2784,2789,2950,2954,2956,3005,3013,3017,3027,3032,3040,3044,3050,3194,3202,3211,3228,3235,3239,3305,3467,3494,3506,3526,3536,3719,3727,3813)
From 212.118.226.93 - 23 packets to tcp(1419,1495,4362,4385,4416)
Logged 632 packets on interface eth1
From 1.112.169.252 - 2 packets to tcp(445)
From 2.201.14.207 - 3 packets to tcp(445)
From 14.96.161.61 - 2 packets to tcp(445)
From 17.172.237.52 - 2 packets to tcp(49641)
<snip>
Why does 178.107.x.x concern you? (It's T-Mobile UK, by the way)
You asked if your iptables rules were wrong, but you didn't post them. Were you expecting telepathic answers? Maybe that's how those packets arrived.
In answer to your basic question: If you are seeing packets that should not be on your internal network, then either:
a) your iptables rules are wrong
b) something on the internal network has its IP address configured incorrectly
c) someone has added a connection (maybe bluetooth from T-Mobile phone to laptop, for example)
You might be able to close in on the culprit using your ethernet switch's routing tables.
I previously asked this question on this forum here.
But no satisfactory answer was given.
Don't forget to mention that you also failed to answer the question which one member included in his reply to you. Perhaps if you would have treated your thread as a two-way conversation things would have played out differently.
In any case, please don't open multiple threads for the same issue.
Don't forget to mention that you also failed to answer the question which one member included in his reply to you. Perhaps if you would have treated your thread as a two-way conversation things would have played out differently.
In any case, please don't open multiple threads for the same issue.
The question asked was:
"have you done an ip to domain look up? I would see where the IP's are located before I start sweating. It could be something to do with NAT translation and your router..."
And yes, I had checked out the owners of the IPs concerned in that original post - and hence considered the question to be irrelevant.
And in fact I couldn't (and still can't!) see how this is anything to do with NAT?
Why does 178.107.x.x concern you? (It's T-Mobile UK, by the way)
You asked if your iptables rules were wrong, but you didn't post them. Were you expecting telepathic answers? Maybe that's how those packets arrived.
In answer to your basic question: If you are seeing packets that should not be on your internal network, then either:
a) your iptables rules are wrong
b) something on the internal network has its IP address configured incorrectly
c) someone has added a connection (maybe bluetooth from T-Mobile phone to laptop, for example)
You might be able to close in on the culprit using your ethernet switch's routing tables.
The 178.107.x.x is of little concern. What does cause concern, is the fact that I'm seeing external IPs appearing to source route through my internal interface.
Which LOG rule are they hitting?
Are they all to port 5228?
I note that port 5228 is used by Android to connect to Google. You sure this isn't a rogue access point?
That's a good point. Look at the logs...the logs should give some evidence as to what's happening. And maybe break out a sniffer. I'd not rely on LogWatch logs alone.
Which LOG rule are they hitting?
Are they all to port 5228?
I note that port 5228 is used by Android to connect to Google. You sure this isn't a rogue access point?
I'm not sure which log rule they're hitting - however, here is the 'raw' log entry for another IP of concern.
If I'm interpreting this correctly:
212.118.226.91 is trying to connect to 192.168.0.168 ?
Or is this some kind of reverse logic, and 192.168.0.168 is actually connecting to 212.118.226.91 on port 80? If so, why would the log entry be reversed?
However, there is no rule that permits inbound connections of this nature.
And (more worryingly) the connection appears to be sourced from eth0 (internal interface).
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. If this was bad traffic that indicated a compromised machine and you were sniffing on the internal interface, you'd see the bi-directional traffic (ie, you'd see your internal host responding and going outbound (or attempting to, if your FW is tight and is blocking the outbound comms attempt)). It would be very apparent in the sniffer, especially if you filter all traffic but the source and destination on that particular interface. Or sniff on the destination host itself (to take any FW misconfigs out of the equation).
As a note, inbound traffic with a source port of 80 is anomalous. I've even seen this traffic stump the isc.sans.org guys. I see it all the time, but it is always dropped at my FW. It helps that I don't have a forward chain.
OUTPUT tells me that this is passing through your filter.
SRC=212.118.226.91, 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 212.118.226.91'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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
