LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-03-2010, 04:47 AM   #1
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Rep: Reputation: 0
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
Server info:

172.16.x.x is my internal network.

iptables v1.3.5

Linux x.x.x 2.6.18-194.8.1.el5 #1 SMP Thu Jul 1 19:07:06 EDT 2010 i686 athlon i386 GNU/Linux

CentOS release 5.5 (Final)

Any suggestions gratefully accepted.

Thanks.

Last edited by TonyAR; 12-03-2010 at 04:48 AM.
 
Old 12-03-2010, 02:52 PM   #2
davide123
Member
 
Registered: Jan 2010
Location: tampa bay fl
Distribution: fedora redhat 9 10 11 12 13 &14 x86_64 & i686; Peppermint, MintOne; RHEL 4 5 6, Ubuntu, SliTaz etc,
Posts: 102

Rep: Reputation: 16
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...
 
Old 04-11-2011, 07:42 AM   #3
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
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>

Last edited by win32sux; 04-11-2011 at 03:14 PM.
 
Old 04-11-2011, 02:28 PM   #4
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 1,561

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
You don't give enough information.

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.
 
Old 04-11-2011, 03:10 PM   #5
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by TonyAR View Post
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.
 
Old 04-11-2011, 03:14 PM   #6
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Merged into the original thread.
 
Old 04-12-2011, 03:44 AM   #7
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by win32sux View Post
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?
 
Old 04-12-2011, 03:57 AM   #8
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by smallpond View Post
You don't give enough information.

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.

There are also others (from the latest logs)

74.217.240.81
74.217.240.83
212.118.226.90
212.118.226.91
212.118.226.93

In addition to your response:

I had considered "a" and the rules are now posted below (an oversight on my part - sorry)

(b) Even on days when there are maybe two devices (laptops) I see this.

(c) Nobody is doing that.

Rules below:

I have sanitized this to a certain extent:

192.168.0.2 is a VoIP box (and proven not to be the source of any of this traffic).

<EXT_IP> is the external IP of the box.

<ACCESS_IP_1> through <ACCESS_IP_6> are static addresses giving access to certain services.

<ACCESS_NET> is a static network address giving access to certain services.

Output of iptables save:

Code:
# Generated by iptables-save v1.3.5 on Fri Nov  6 18:29:02 2009
*nat
:PREROUTING ACCEPT [257937:14040514]
:POSTROUTING ACCEPT [61415:5810821]
:OUTPUT ACCEPT [165144:14935391]
:REDNAT - [0:0]
-A PREROUTING -d <EXT_IP> -i eth1 -p udp -m udp --dport 5060 -j DNAT --to-destination 192.168.0.2:5060 
-A PREROUTING -d <EXT_IP> -i eth1 -p udp -m udp --dport 1024:65535 -j DNAT --to-destination 192.168.0.2:1024-65535
-A PREROUTING -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.2:80 
-A PREROUTING -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 22 -j DNAT --to-destination 192.168.0.2:22 
-A PREROUTING -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 20 -j DNAT --to-destination 192.168.0.2:20 
-A PREROUTING -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 21 -j DNAT --to-destination 192.168.0.2:21 
-A POSTROUTING -j REDNAT 
-A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source 192.168.0.1 
-A REDNAT -o eth1 -j MASQUERADE 
COMMIT
# Completed on Fri Nov  6 18:29:02 2009
# Generated by iptables-save v1.3.5 on Fri Nov  6 18:29:02 2009
*mangle
:PREROUTING ACCEPT [2953015:1065653345]
:INPUT ACCEPT [1607188:351569113]
:FORWARD ACCEPT [1345827:714084232]
:OUTPUT ACCEPT [1542789:316716027]
:POSTROUTING ACCEPT [2969654:1044578653]
:PORTFWMANGLE - [0:0]
-A PREROUTING -j PORTFWMANGLE 
-A PREROUTING -d 224.0.0.1 -j DROP 
COMMIT
# Completed on Fri Nov  6 18:29:02 2009
# Generated by iptables-save v1.3.5 on Fri Nov  6 18:29:02 2009
*filter
:INPUT DROP [29478:3026473]
:FORWARD DROP [1952:80688]
:OUTPUT ACCEPT [1542789:316716027]
:BADTCP - [0:0]
:LOG_DROP - [0:0]
:LOG_REJECT - [0:0]
:NEWNOTSYN - [0:0]
:PORTFWACCESS - [0:0]
:PSCAN - [0:0]
:XTACCESS - [0:0]
#:l - [0:0]
#:lv - [0:0]
-A INPUT -i eth1 -p tcp -m tcp --dport 1026:1028 -j DROP 
-A INPUT -i eth1 -p udp -m udp --dport 1026:1028 -j DROP 
-A INPUT -i eth1 -p udp -m udp --dport 67 -j DROP 
-A INPUT -i eth1 -p udp -m udp --dport 68 -j DROP 
-A INPUT -j BADTCP 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -m state --state NEW -j ACCEPT 
-A INPUT -s 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP 
-A INPUT -d 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP 
-A INPUT -i eth0 -p ! icmp -m state --state NEW -j ACCEPT 
-A INPUT -m state --state NEW -j XTACCESS 
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 5 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT 
-A INPUT -m limit --limit 10/min -j LOG --log-prefix "INPUT " 
#
# -A INPUT -s 224.0.0.0/240.0.0.0 -j DROP 
#
-A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -p udp -j ACCEPT 
-A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -p igmp -j ACCEPT 
-A INPUT -d 224.0.0.0/240.0.0.0 -i eth1 -j DROP 
-A INPUT -s 224.0.0.0/240.0.0.0 -i eth1 -j DROP 
-A INPUT -s 240.0.0.0/240.0.0.0 -i eth1 -j DROP 
#
-A FORWARD -j BADTCP 
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -i lo -m state --state NEW -j ACCEPT 
-A FORWARD -s 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP 
-A FORWARD -d 127.0.0.0/255.0.0.0 -m state --state NEW -j DROP 
-A FORWARD -i eth0 -m state --state NEW -j ACCEPT 
-A FORWARD -m state --state NEW -j PORTFWACCESS 
-A FORWARD -m limit --limit 10/min -j LOG --log-prefix "OUTPUT " 
-A FORWARD -s <ACCESS_IP_6>/255.255.255.255 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 5060 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_6>/255.255.255.255 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 1024:65535 -j ACCEPT 
-A FORWARD -s <ACCESS_NET>/255.255.255.240 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_3>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_4>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_3>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -s <ACCESS_NET>/255.255.255.240 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_4>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_4>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 20 -j ACCEPT 
-A FORWARD -s <ACCESS_IP_4>/255.255.255.255 -d 192.168.0.2 -i eth1 -p tcp -m tcp --dport 21 -j ACCEPT 
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j PSCAN 
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j PSCAN 
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j PSCAN 
-A BADTCP -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j PSCAN 
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j PSCAN 
-A BADTCP -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j NEWNOTSYN 
-A LOG_DROP -m limit --limit 10/min -j LOG 
-A LOG_DROP -j DROP 
-A LOG_REJECT -m limit --limit 10/min -j LOG 
-A LOG_REJECT -j REJECT --reject-with icmp-port-unreachable 
-A NEWNOTSYN -m limit --limit 10/min -j LOG --log-prefix "NEW not SYN? " 
-A NEWNOTSYN -j DROP 
-A PSCAN -p tcp -m limit --limit 10/min -j LOG --log-prefix "TCP Scan? " 
-A PSCAN -p udp -m limit --limit 10/min -j LOG --log-prefix "UDP Scan? " 
-A PSCAN -p icmp -m limit --limit 10/min -j LOG --log-prefix "ICMP Scan? " 
-A PSCAN -f -m limit --limit 10/min -j LOG --log-prefix "FRAG Scan? " 
-A PSCAN -j DROP 
-A XTACCESS -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 20 -m state --state NEW -j ACCEPT 
-A XTACCESS -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 21 -m state --state NEW -j ACCEPT 
-A XTACCESS -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_5> -d <EXT_IP> -i eth1 -p tcp -m tcp --dport 5000 -m state --state NEW -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_6>/255.255.255.255 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 1024:65535 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_6>/255.255.255.255 -d 192.168.0.2 -i eth1 -p udp -m udp --dport 5060 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_3> -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_4> -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_3> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 223 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d 192.168.0.2 -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 81 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 223 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_2> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_3> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 10000 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 10000 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 5901 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_3> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 5901 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_1> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT 
-A XTACCESS -s <ACCESS_IP_3> -d <EXT_IP> -i eth1 -p tcp -m state --state NEW -m tcp --dport 5900 -j ACCEPT 
COMMIT
# Completed on Fri Nov  6 18:29:02 2009
Output of "iptables -nL"

Code:
Chain INPUT (policy DROP)
target     prot opt source               destination         
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:1026:1028 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:1026:1028 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:67 
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:68 
BADTCP     all  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW 
DROP       all  --  127.0.0.0/8          0.0.0.0/0           state NEW 
DROP       all  --  0.0.0.0/0            127.0.0.0/8         state NEW 
ACCEPT    !icmp --  0.0.0.0/0            0.0.0.0/0           state NEW 
XTACCESS   all  --  0.0.0.0/0            0.0.0.0/0           state NEW 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 0 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 3 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 5 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 11 
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           icmp type 8 limit: avg 1/sec burst 5 
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `INPUT ' 
ACCEPT     udp  --  0.0.0.0/0            224.0.0.0/4         
ACCEPT     2    --  0.0.0.0/0            224.0.0.0/4         
DROP       all  --  0.0.0.0/0            224.0.0.0/4         
DROP       all  --  224.0.0.0/4          0.0.0.0/0           
DROP       all  --  240.0.0.0/4          0.0.0.0/0           

Chain FORWARD (policy DROP)
target     prot opt source               destination         
BADTCP     all  --  0.0.0.0/0            0.0.0.0/0           
TCPMSS     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW 
DROP       all  --  127.0.0.0/8          0.0.0.0/0           state NEW 
DROP       all  --  0.0.0.0/0            127.0.0.0/8         state NEW 
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state NEW 
PORTFWACCESS  all  --  0.0.0.0/0            0.0.0.0/0           state NEW 
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `OUTPUT ' 
ACCEPT     udp  --  <ACCESS_IP_7>         192.168.0.2         udp dpt:5060 
ACCEPT     udp  --  <ACCESS_IP_7>         192.168.0.2         udp dpts:1024:65535 
ACCEPT     tcp  --  <ACCESS_NET>/28       192.168.0.2         tcp dpt:80 
ACCEPT     tcp  --  <ACCESS_IP_3>         192.168.0.2         tcp dpt:80 
ACCEPT     tcp  --  <ACCESS_IP_4>         192.168.0.2         tcp dpt:80 
ACCEPT     tcp  --  <ACCESS_IP_3>         192.168.0.2         tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_NET>/28       192.168.0.2         tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_4>         192.168.0.2         tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_4>         192.168.0.2         tcp dpt:20 
ACCEPT     tcp  --  <ACCESS_IP_4>         192.168.0.2         tcp dpt:21 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain BADTCP (2 references)
target     prot opt source               destination         
PSCAN      tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29 
PSCAN      tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00 
PSCAN      tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x01 
PSCAN      tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06 
PSCAN      tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:0x03/0x03 
NEWNOTSYN  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW 

Chain LOG_DROP (0 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain LOG_REJECT (0 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

Chain NEWNOTSYN (1 references)
target     prot opt source               destination         
LOG        all  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? ' 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain PORTFWACCESS (1 references)
target     prot opt source               destination         

Chain PSCAN (5 references)
target     prot opt source               destination         
LOG        tcp  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `TCP Scan? ' 
LOG        udp  --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `UDP Scan? ' 
LOG        icmp --  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `ICMP Scan? ' 
LOG        all  -f  0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `FRAG Scan? ' 
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain XTACCESS (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:20 state NEW 
ACCEPT     tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:21 state NEW 
ACCEPT     tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:80 state NEW 
ACCEPT     tcp  --  <ACCESS_IP_5>       <EXT_IP>        tcp dpt:5000 state NEW 
ACCEPT     udp  --  <ACCESS_IP_7>         192.168.0.2         udp dpts:1024:65535 
ACCEPT     udp  --  <ACCESS_IP_7>         192.168.0.2         udp dpt:5060 
ACCEPT     tcp  --  <ACCESS_IP_3>         192.168.0.2         state NEW tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_4>         192.168.0.2         state NEW tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_3>         <EXT_IP>        state NEW tcp dpt:223 
ACCEPT     tcp  --  <ACCESS_IP_1>         192.168.0.2         state NEW tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_1>         <EXT_IP>        state NEW tcp dpt:81 
ACCEPT     tcp  --  <ACCESS_IP_1>         <EXT_IP>        state NEW tcp dpt:223 
ACCEPT     tcp  --  <ACCESS_IP_2>          <EXT_IP>        state NEW tcp dpt:22 
ACCEPT     tcp  --  <ACCESS_IP_3>         <EXT_IP>        state NEW tcp dpt:10000 
ACCEPT     tcp  --  <ACCESS_IP_1>         <EXT_IP>        state NEW tcp dpt:10000 
ACCEPT     tcp  --  <ACCESS_IP_1>         <EXT_IP>        state NEW tcp dpt:5901 
ACCEPT     tcp  --  <ACCESS_IP_3>         <EXT_IP>        state NEW tcp dpt:5901 
ACCEPT     tcp  --  <ACCESS_IP_1>         <EXT_IP>        state NEW tcp dpt:5900 
ACCEPT     tcp  --  <ACCESS_IP_3>         <EXT_IP>        state NEW tcp dpt:5900

Last edited by TonyAR; 04-12-2011 at 04:22 AM.
 
Old 04-14-2011, 04:42 AM   #9
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
I forgot to add the NAT rules

I forgot to add the NAT rules.

And *bump* anybody?

Code:
*** NAT rules ***

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       udp  --  0.0.0.0/0            <EXT_IP>        udp dpt:5060 to:192.168.0.2:5060
DNAT       udp  --  0.0.0.0/0            <EXT_IP>        udp dpts:1024:65535 to:192.168.0.2:1024-65535
DNAT       tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:80 to:192.168.0.2:80
DNAT       tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:22 to:192.168.0.2:22
DNAT       tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:20 to:192.168.0.2:20
DNAT       tcp  --  0.0.0.0/0            <EXT_IP>        tcp dpt:21 to:192.168.0.2:21

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
REDNAT     all  --  0.0.0.0/0            0.0.0.0/0
SNAT       all  --  0.0.0.0/0            0.0.0.0/0           MARK match 0x1 to:192.168.0.1

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain REDNAT (1 references)
target     prot opt source               destination
MASQUERADE  all  --  0.0.0.0/0            0.0.0.0/0
 
Old 04-14-2011, 10:13 AM   #10
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 1,561

Rep: Reputation: 380Reputation: 380Reputation: 380Reputation: 380
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?
 
1 members found this post helpful.
Old 04-14-2011, 10:38 AM   #11
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
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.
 
Old 04-20-2011, 06:50 AM   #12
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
Quote:
Originally Posted by smallpond View Post
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).

Code:
Apr 20 11:21:52 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=115 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0
Apr 20 11:21:59 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=116 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0
Apr 20 11:22:04 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=117 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0
Apr 20 11:22:23 statler kernel: OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=118 DF PROTO=TCP SPT=80 DPT=2011 WINDOW=0 RES=0x00 RST URGP=0
 
Old 04-20-2011, 11:01 AM   #13
TonyAR
LQ Newbie
 
Registered: Apr 2010
Posts: 15

Original Poster
Rep: Reputation: 0
Just to add to the above post.

This is the log rule:

Code:
-A FORWARD -m limit --limit 10/min -j LOG --log-prefix "OUTPUT "
I have now changed the rule to:

Code:
-A FORWARD -m limit --limit 10/min -j LOG --log-prefix "FORWARD "
Given that this is a forwarding rule.

And now the log entry is thus:

Code:
Apr 20 16:10:14 statler kernel: FORWARD IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=307 DF PROTO=TCP SPT=80 DPT=3006 WINDOW=0 RES=0x00 RST URGP=0
But yet, in the log entry, the SRC is still quoted as the external IP when I thought it should be the internal IP?
 
Old 04-20-2011, 01:57 PM   #14
unixfool
Member
 
Registered: May 2005
Location: Northern VA
Distribution: Slackware, Ubuntu, FreeBSD, OpenBSD, OS X
Posts: 781
Blog Entries: 8

Rep: Reputation: 157Reputation: 157
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.
 
Old 04-20-2011, 03:42 PM   #15
Noway2
Senior Member
 
Registered: Jul 2007
Distribution: Ubuntu 10.10, Slackware 64-current
Posts: 2,124

Rep: Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776Reputation: 776
Looking part of the entry:
Quote:
OUTPUT IN=eth0 OUT=eth0 SRC=212.118.226.91 DST=192.168.0.168 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=118 DF PROTO=TCP SPT=80 DPT=2011
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.
 
  


Reply

Tags
iptables


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to Bind External IP address to Internal IP address tdog89 Linux - Networking 2 06-28-2009 06:21 AM
which interface to graph (internal or external) ? hattori.hanzo Linux - Networking 2 04-03-2008 10:48 PM
Internal network connecting to external IP address kamafeu Linux - Networking 2 01-21-2007 01:23 PM
web hosting with an internal and external ip address mindhacker Linux - Newbie 7 11-28-2006 09:38 PM
Detecting the external IP address of an internal network: JohnLocke Linux - Newbie 17 07-22-2004 04:08 PM


All times are GMT -5. The time now is 07:40 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration