LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (http://www.linuxquestions.org/questions/linux-security-4/)
-   -   Seeing packets from external IP address on protected internal interface? (http://www.linuxquestions.org/questions/linux-security-4/seeing-packets-from-external-ip-address-on-protected-internal-interface-848116/)

TonyAR 12-03-2010 05:47 AM

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.

davide123 12-03-2010 03:52 PM

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...

TonyAR 04-11-2011 08:42 AM

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>


smallpond 04-11-2011 03:28 PM

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.

win32sux 04-11-2011 04:10 PM

Quote:

Originally Posted by TonyAR (Post 4320926)
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.

win32sux 04-11-2011 04:14 PM

Merged into the original thread.

TonyAR 04-12-2011 04:44 AM

Quote:

Originally Posted by win32sux (Post 4321355)
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?

TonyAR 04-12-2011 04:57 AM

Quote:

Originally Posted by smallpond (Post 4321305)
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


TonyAR 04-14-2011 05:42 AM

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


smallpond 04-14-2011 11:13 AM

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?

unixfool 04-14-2011 11:38 AM

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.

TonyAR 04-20-2011 07:50 AM

Quote:

Originally Posted by smallpond (Post 4324580)
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


TonyAR 04-20-2011 12:01 PM

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?

unixfool 04-20-2011 02:57 PM

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.

Noway2 04-20-2011 04:42 PM

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.


All times are GMT -5. The time now is 01:25 PM.