* Some oddities while setting up outbound filtering on a web server
@ 2014-02-21 22:36 Anthony Taylor
2014-02-22 10:37 ` Mart Frauenlob
0 siblings, 1 reply; 9+ messages in thread
From: Anthony Taylor @ 2014-02-21 22:36 UTC (permalink / raw)
To: netfilter
I'm attempting to set up outbound filtering on a server to satisfy PCI
requirements. Here is what I have so far:
iptables -L OUTPUT -n --line-numbers
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
1 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
2 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
state RELATED,ESTABLISHED
3 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0
4 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8
# DNS
5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:53
# WHOIS
7 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:43
# SMTP
8 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
# feeds.feedburner.com
9 tcp -- 0.0.0.0/0 74.125.0.0/16 tcp dpt:80
# akismet
10 ACCEPT tcp -- 0.0.0.0/0 66.135.58.62 tcp dpt:80
11 ACCEPT tcp -- 0.0.0.0/0 192.0.80.244 tcp dpt:80
12 ACCEPT tcp -- 0.0.0.0/0 66.135.58.61 tcp dpt:80
13 ACCEPT tcp -- 0.0.0.0/0 192.0.80.246 tcp dpt:80
# ubuntu updates
14 ACCEPT tcp -- 0.0.0.0/0 91.189.92.201 tcp dpt:80
15 ACCEPT tcp -- 0.0.0.0/0 91.189.88.149 tcp dpt:80
16 ACCEPT tcp -- 0.0.0.0/0 91.189.91.13 tcp dpt:80
17 ACCEPT tcp -- 0.0.0.0/0 91.189.92.200 tcp dpt:80
18 ACCEPT tcp -- 0.0.0.0/0 91.189.91.14 tcp dpt:80
19 ACCEPT tcp -- 0.0.0.0/0 91.189.91.15 tcp dpt:80
20 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG
flags 0 level 4 prefix `fw-outbound: '
My problem is I'm seeing some traffic that I'm not sure I should be
seeing. I get periodically some traffic from source port 80. It's my
understanding that rule 2 above would filter these out. When I try to
access the webserver I don't get anything to show up in logs. Yet
still I'm getting entries like these:
[12989577.380311] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
DST=201.170.158.23 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0
DF PROTO=TCP SPT=80 DPT=59799 WINDOW=0 RES=0x00 RST URGP=0
[12990368.808237] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
DST=24.153.148.198 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0
DF PROTO=TCP SPT=80 DPT=55919 WINDOW=31 RES=0x00 ACK URGP=0
These usually happen in batches with a few of them for the same
destination IP happening at once.
I am also still getting traffic going to 74.125.0.0/16 as shown:
[12990030.361878] fw-outbound: IN= OUT=venet0 SRC=205.186.153.220
DST=74.125.228.233 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=4
4707 DF PROTO=TCP SPT=42954 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
[12990390.327175] fw-outbound: IN= OUT=venet0 SRC=205.186.153.220
DST=74.125.228.78 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=20
052 DF PROTO=TCP SPT=53988 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0
I know that this traffic is my webserver contacting feedburner to grab
an rss feed, but shouldn't rule 9 keep these from logging?
I am also getting some weird traffic via ICMP. This may have been
fixed as I modified rules 3 and 4 recently, but I still would like to
know what was going on with these entries.
[12971782.466219] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
DST=85.195.104.22 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=59097 PROTO=ICMP
TYPE=3 CODE=3 [SRC=85.195.104.22 DST=205.186.153.230 LEN=44 TOS=0x00
PREC=0x00 TTL=50 ID=0 DF PROTO=TCP SPT=80 DPT=63060 WINDOW=5840
RES=0x00 ACK SYN URGP=0 ]
[12975573.759745] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
DST=148.251.3.244 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=21963 PROTO=ICMP
TYPE=3 CODE=3
[SRC=148.251.3.244 DST=205.186.153.230 LEN=40 TOS=0x00 PREC=0x00
TTL=47 ID=0 DF PROTO=TCP SPT=80 DPT=1234 WINDOW=0 RES=0x00 ACK RST
URGP=0 ]
[12979019.838420] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
DST=188.190.123.59 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=18440
PROTO=ICMP TYPE=3 CODE=
3 [SRC=188.190.123.59 DST=205.186.153.230 LEN=44 TOS=0x00 PREC=0x00
TTL=51 ID=0 DF PROTO=TCP SPT=80 DPT=9358 WINDOW=14600 RES=0x00 ACK SYN
URGP=0 ]
[12982328.005621] fw-outbound: IN= OUT=venet0 SRC=205.186.153.220
DST=69.172.201.19 LEN=72 TOS=0x00 PREC=0xC0 TTL=64 ID=50342 PROTO=ICMP
TYPE=3 CODE=3
[SRC=69.172.201.19 DST=205.186.153.220 LEN=44 TOS=0x00 PREC=0x00
TTL=117 ID=62129 PROTO=TCP SPT=80 DPT=1234 WINDOW=8192 RES=0x00 ACK
SYN URGP=0 ]
[12982917.606388] fw-outbound: IN= OUT=venet0 SRC=205.186.153.220
DST=193.0.6.135 LEN=68 TOS=0x00 PREC=0xC0 TTL=64 ID=50191 PROTO=ICMP
TYPE=3 CODE=3 [
SRC=193.0.6.135 DST=205.186.153.220 LEN=40 TOS=0x00 PREC=0x00 TTL=246
ID=43720 DF PROTO=TCP SPT=43 DPT=41980 WINDOW=0 RES=0x00 ACK RST
URGP=0 ]
Thank you in advance for any help, I'm sorry if this message is long winded.
Anthony Taylor
---------------------
http://www.fallsgeek.com
(940)228-4580
Wichita Falls, TX
Your connection for everything geek...
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-02-21 22:36 Some oddities while setting up outbound filtering on a web server Anthony Taylor
@ 2014-02-22 10:37 ` Mart Frauenlob
0 siblings, 0 replies; 9+ messages in thread
From: Mart Frauenlob @ 2014-02-22 10:37 UTC (permalink / raw)
To: Anthony Taylor; +Cc: netfilter
On 21.02.2014 23:36, Anthony Taylor wrote:
> I'm attempting to set up outbound filtering on a server to satisfy
> PCI requirements. Here is what I have so far:
>
> iptables -L OUTPUT -n --line-numbers Chain OUTPUT (policy ACCEPT)
policy of ACCEPT??? where's the filtering?
only ACCEPT rules below, you want logging only?
use output of iptables -S .... -N is bad formatting for mail. also it
needs -v to be complete like for rule #1 (guess that's for the lo iface)...
> num target prot opt source destination 1 ACCEPT
> all -- 0.0.0.0/0 0.0.0.0/0 2 ACCEPT all --
> 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 3 ACCEPT
> icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 0 4
> ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp
> type 8 # DNS 5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0
> tcp dpt:53 6 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0
> udp dpt:53 # WHOIS 7 ACCEPT tcp -- 0.0.0.0/0
> 0.0.0.0/0 tcp dpt:43 # SMTP 8 ACCEPT tcp --
> 0.0.0.0/0 0.0.0.0/0 tcp dpt:25 #
> feeds.feedburner.com 9 tcp -- 0.0.0.0/0
> 74.125.0.0/16 tcp dpt:80 # akismet 10 ACCEPT tcp --
> 0.0.0.0/0 66.135.58.62 tcp dpt:80 11 ACCEPT
> tcp -- 0.0.0.0/0 192.0.80.244 tcp dpt:80 12
> ACCEPT tcp -- 0.0.0.0/0 66.135.58.61 tcp
> dpt:80 13 ACCEPT tcp -- 0.0.0.0/0 192.0.80.246
> tcp dpt:80 # ubuntu updates 14 ACCEPT tcp -- 0.0.0.0/0
> 91.189.92.201 tcp dpt:80 15 ACCEPT tcp -- 0.0.0.0/0
> 91.189.88.149 tcp dpt:80 16 ACCEPT tcp -- 0.0.0.0/0
> 91.189.91.13 tcp dpt:80 17 ACCEPT tcp -- 0.0.0.0/0
> 91.189.92.200 tcp dpt:80 18 ACCEPT tcp -- 0.0.0.0/0
> 91.189.91.14 tcp dpt:80 19 ACCEPT tcp -- 0.0.0.0/0
> 91.189.91.15 tcp dpt:80 20 LOG all -- 0.0.0.0/0
> 0.0.0.0/0 LOG flags 0 level 4 prefix `fw-outbound: '
>
> My problem is I'm seeing some traffic that I'm not sure I should be
> seeing. I get periodically some traffic from source port 80. It's
> my understanding that rule 2 above would filter these out. When I
> try to access the webserver I don't get anything to show up in logs.
> Yet still I'm getting entries like these:
>
> [12989577.380311] fw-outbound: IN= OUT=venet0 SRC=205.186.153.230
> DST=201.170.158.23 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP
> SPT=80 DPT=59799 WINDOW=0 RES=0x00 RST URGP=0 [12990368.808237]
> fw-outbound: IN= OUT=venet0 SRC=205.186.153.230 DST=24.153.148.198
> LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=80 DPT=55919
> WINDOW=31 RES=0x00 ACK URGP=0
>
> These usually happen in batches with a few of them for the same
> destination IP happening at once.
-m state --state INVALID -j DROP
look if they still come up...
also this might have influence:
nf_conntrack_tcp_be_liberal - BOOLEAN
0 - disabled (default)
not 0 - enabled
Be conservative in what you do, be liberal in what you accept
from others.
If it's non-zero, we mark only out of window RST segments as
INVALID.
see:
Documentation/networking/nf_conntrack-sysctl.txt
[...]
I'd suggest to use ipset for all the IPs, ie:
ipset create webservers hash:ip
ipset add webservers 91.189.92.201
and so on
iptables -A OUTPUT -m set --match-set webservers dst -p tcp --dport 80
-m state --state NEW -j ACCEPT
Best regards
Mart
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-08 2:05 ` Anthony Taylor
@ 2014-03-08 5:20 ` Neal Murphy
0 siblings, 0 replies; 9+ messages in thread
From: Neal Murphy @ 2014-03-08 5:20 UTC (permalink / raw)
To: netfilter
On Friday, March 07, 2014 09:05:10 PM Anthony Taylor wrote:
> On Thu, Mar 6, 2014 at 11:01 PM, Neal Murphy <neal.p.murphy@alum.wpi.edu>
wrote:
> > On Thursday, March 06, 2014 11:46:17 PM Mart Frauenlob wrote:
> >> >> Then try to enable it???
> >> >
> >> > echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
> >> > -su: /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal: Permission
> >> > denied
> >>
> >> strange, don't know what is the problem there...
> >
> > Module nf_conntrack_ipv4 has not been INSed.
>
> I'm not sure what that means.
'insmod nf_conntrack_ipv4' and the error should go away. That particular file
(among others) doesn't exist if that particular module has not been loaded.
And, if I presume correctly, userspace (generally) cannot create files in
/proc. Thus the permission error.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-07 5:01 ` Neal Murphy
@ 2014-03-08 2:05 ` Anthony Taylor
2014-03-08 5:20 ` Neal Murphy
0 siblings, 1 reply; 9+ messages in thread
From: Anthony Taylor @ 2014-03-08 2:05 UTC (permalink / raw)
To: netfilter
On Thu, Mar 6, 2014 at 11:01 PM, Neal Murphy <neal.p.murphy@alum.wpi.edu> wrote:
> On Thursday, March 06, 2014 11:46:17 PM Mart Frauenlob wrote:
>> >> Then try to enable it???
>> >
>> > echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
>> > -su: /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal: Permission
>> > denied
>>
>> strange, don't know what is the problem there...
>
> Module nf_conntrack_ipv4 has not been INSed.
I'm not sure what that means.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-07 4:46 ` Mart Frauenlob
@ 2014-03-07 5:01 ` Neal Murphy
2014-03-08 2:05 ` Anthony Taylor
0 siblings, 1 reply; 9+ messages in thread
From: Neal Murphy @ 2014-03-07 5:01 UTC (permalink / raw)
To: netfilter
On Thursday, March 06, 2014 11:46:17 PM Mart Frauenlob wrote:
> >> Then try to enable it???
> >
> > echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
> > -su: /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal: Permission
> > denied
>
> strange, don't know what is the problem there...
Module nf_conntrack_ipv4 has not been INSed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-06 23:39 ` Anthony Taylor
@ 2014-03-07 4:46 ` Mart Frauenlob
2014-03-07 5:01 ` Neal Murphy
0 siblings, 1 reply; 9+ messages in thread
From: Mart Frauenlob @ 2014-03-07 4:46 UTC (permalink / raw)
To: Anthony Taylor; +Cc: netfilter
On 07.03.2014 00:39, Anthony Taylor wrote:
> On Thu, Mar 6, 2014 at 12:26 PM, Mart Frauenlob
> <mart.frauenlob@chello.at> wrote:
>> On 04.03.2014 17:52, Anthony Taylor wrote:
>>>
>>> On Sat, Feb 22, 2014 at 4:37 AM, Mart Frauenlob
>>> <mart.frauenlob@chello.at> wrote:
>>>>
>>>>
>>>> On 21.02.2014 23:36, Anthony Taylor wrote:
[...]
> So when I'm satisfied with my logs I should just do a:
> iptables -P OUTPUT DROP
yep
[...]
>>>
>>>>
>>>> nf_conntrack_tcp_be_liberal - BOOLEAN
>>>> 0 - disabled (default)
>>>> not 0 - enabled
>>>>
>>>> Be conservative in what you do, be liberal in what you accept
>>>> from others.
>>>> If it's non-zero, we mark only out of window RST segments as
>>>> INVALID.
>>>>
>>>> see:
>>>> Documentation/networking/nf_conntrack-sysctl.txt
>>>
>>>
>>>
>>> cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
>>> 0
>>>
>>> This appears to be disabled.
>>>
>>
>> Then try to enable it???
>
> echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
> -su: /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal: Permission denied
>
strange, don't know what is the problem there...
> I have found out something that may be helpful. I set up a rule to
> accept NEW packets with source port 80. Sure enough that seemed to
> clear up my logs.
>
> So now the question is why the heck apache is sending out new packets
> on what should be established connections?
this is what I use:
-A BAD_TCP_PACKETS -p tcp -m tcp --tcp-flags SYN,ACK SYN,ACK -m
conntrack --ctstate NEW -j REJECT --reject-with tcp-reset
-A BAD_TCP_PACKETS -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m
conntrack --ctstate NEW -j DROP
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-06 18:26 ` Mart Frauenlob
@ 2014-03-06 23:39 ` Anthony Taylor
2014-03-07 4:46 ` Mart Frauenlob
0 siblings, 1 reply; 9+ messages in thread
From: Anthony Taylor @ 2014-03-06 23:39 UTC (permalink / raw)
To: netfilter
On Thu, Mar 6, 2014 at 12:26 PM, Mart Frauenlob
<mart.frauenlob@chello.at> wrote:
> On 04.03.2014 17:52, Anthony Taylor wrote:
>>
>> On Sat, Feb 22, 2014 at 4:37 AM, Mart Frauenlob
>> <mart.frauenlob@chello.at> wrote:
>>>
>>>
>>> On 21.02.2014 23:36, Anthony Taylor wrote:
>>>>
>>>>
>>>> I'm attempting to set up outbound filtering on a server to satisfy
>>>> PCI requirements. Here is what I have so far:
>>>>
>>>> iptables -L OUTPUT -n --line-numbers Chain OUTPUT (policy ACCEPT)
>>>
>>>
>>>
>>> policy of ACCEPT??? where's the filtering?
>>> only ACCEPT rules below, you want logging only?
>>
>>
>> Sorry I didn't explain. The last rule will be a DROP all, however for
>> now in the interest of not breaking anything I'm logging results
>> instead.
>
>
> no need to put a last drop rule, that's what the policy is for.
So when I'm satisfied with my logs I should just do a:
iptables -P OUTPUT DROP
>>
>>>
>>> use output of iptables -S .... -N is bad formatting for mail. also it
>>> needs -v to be complete like for rule #1 (guess that's for the lo
>>> iface)..
>>
>>
>> Here is the output of iptables -S OUTPUT -v
>>
>> iptables -S OUTPUT -v
>> -P OUTPUT ACCEPT -c 5039 319910
>> -A OUTPUT -o lo -c 294541 22016298 -j ACCEPT
>> -A OUTPUT -m state --state RELATED,ESTABLISHED -c 11077878 13836891689 -j
>> ACCEPT
>> -A OUTPUT -p icmp -m icmp --icmp-type 0 -c 0 0 -j ACCEPT
>> -A OUTPUT -p icmp -m icmp --icmp-type 8 -c 193399 5415172 -j ACCEPT
>> -A OUTPUT -p tcp -m tcp --dport 53 -c 0 0 -j ACCEPT
>> -A OUTPUT -p udp -m udp --dport 53 -c 233937 16828408 -j ACCEPT
>> -A OUTPUT -p tcp -m tcp --dport 43 -c 50 3000 -j ACCEPT
>> -A OUTPUT -p tcp -m tcp --dport 25 -c 344 20640 -j ACCEPT
>> -A OUTPUT -d 74.125.0.0/16 -p tcp -m tcp --dport 80 -c 1319 79140 -j
>> ACCEPT
>> -A OUTPUT -d 66.135.58.62/32 -p tcp -m tcp --dport 80 -c 153 9180 -j
>> ACCEPT
>> -A OUTPUT -d 192.0.80.244/32 -p tcp -m tcp --dport 80 -c 139 8340 -j
>> ACCEPT
>> -A OUTPUT -d 66.135.58.61/32 -p tcp -m tcp --dport 80 -c 112 6720 -j
>> ACCEPT
>> -A OUTPUT -d 192.0.80.246/32 -p tcp -m tcp --dport 80 -c 109 6540 -j
>> ACCEPT
>> -A OUTPUT -d 91.189.92.201/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
>> -A OUTPUT -d 91.189.88.149/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
>> -A OUTPUT -d 91.189.91.13/32 -p tcp -m tcp --dport 80 -c 3 180 -j ACCEPT
>> -A OUTPUT -d 91.189.92.200/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
>> -A OUTPUT -d 91.189.91.14/32 -p tcp -m tcp --dport 80 -c 2 120 -j ACCEPT
>> -A OUTPUT -d 91.189.91.15/32 -p tcp -m tcp --dport 80 -c 7 420 -j ACCEPT
>> -A OUTPUT -d 66.155.40.249/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
>> -A OUTPUT -d 66.155.40.250/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
>> -A OUTPUT -m state --state INVALID -c 10200 425557 -j DROP
>> -A OUTPUT -c 5039 319910 -j LOG --log-prefix "fw-outbound: "
>>
>>
>>>>
>>>> My problem is I'm seeing some traffic that I'm not sure I should be
>>>> seeing. I get periodically some traffic from source port 80. It's
>>>> my understanding that rule 2 above would filter these out. When I
>>>> try to access the webserver I don't get anything to show up in logs.
>>>> Yet still I'm getting entries like these:
>>>> <snip>
>
>
> bad idea to snip here ;-p
> bad idea also not to allow icmp error messages (type 3).
>
>>>
>>>
>>> -m state --state INVALID -j DROP
>>> look if they still come up...
>>> also this might have influence:
>>
>>
>> I have added this rule as you can see above, and although it seems to
>> have stopped some of it, my 'phantom' traffic with source ports 80,443
>> still continues.
>
>
> do the filtering for state INVALID in INPUT/FORWARD chain!
>
>>
>>>
>>> nf_conntrack_tcp_be_liberal - BOOLEAN
>>> 0 - disabled (default)
>>> not 0 - enabled
>>>
>>> Be conservative in what you do, be liberal in what you accept
>>> from others.
>>> If it's non-zero, we mark only out of window RST segments as
>>> INVALID.
>>>
>>> see:
>>> Documentation/networking/nf_conntrack-sysctl.txt
>>
>>
>>
>> cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
>> 0
>>
>> This appears to be disabled.
>>
>
> Then try to enable it???
echo 1 > /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
-su: /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal: Permission denied
I have found out something that may be helpful. I set up a rule to
accept NEW packets with source port 80. Sure enough that seemed to
clear up my logs.
So now the question is why the heck apache is sending out new packets
on what should be established connections?
Thank you again for your help,
Anthony
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
2014-03-04 16:52 Anthony Taylor
@ 2014-03-06 18:26 ` Mart Frauenlob
2014-03-06 23:39 ` Anthony Taylor
0 siblings, 1 reply; 9+ messages in thread
From: Mart Frauenlob @ 2014-03-06 18:26 UTC (permalink / raw)
To: Anthony Taylor; +Cc: netfilter
On 04.03.2014 17:52, Anthony Taylor wrote:
> On Sat, Feb 22, 2014 at 4:37 AM, Mart Frauenlob
> <mart.frauenlob@chello.at> wrote:
>>
>> On 21.02.2014 23:36, Anthony Taylor wrote:
>>>
>>> I'm attempting to set up outbound filtering on a server to satisfy
>>> PCI requirements. Here is what I have so far:
>>>
>>> iptables -L OUTPUT -n --line-numbers Chain OUTPUT (policy ACCEPT)
>>
>>
>> policy of ACCEPT??? where's the filtering?
>> only ACCEPT rules below, you want logging only?
>
> Sorry I didn't explain. The last rule will be a DROP all, however for
> now in the interest of not breaking anything I'm logging results
> instead.
no need to put a last drop rule, that's what the policy is for.
>
>>
>> use output of iptables -S .... -N is bad formatting for mail. also it
>> needs -v to be complete like for rule #1 (guess that's for the lo iface)..
>
> Here is the output of iptables -S OUTPUT -v
>
> iptables -S OUTPUT -v
> -P OUTPUT ACCEPT -c 5039 319910
> -A OUTPUT -o lo -c 294541 22016298 -j ACCEPT
> -A OUTPUT -m state --state RELATED,ESTABLISHED -c 11077878 13836891689 -j ACCEPT
> -A OUTPUT -p icmp -m icmp --icmp-type 0 -c 0 0 -j ACCEPT
> -A OUTPUT -p icmp -m icmp --icmp-type 8 -c 193399 5415172 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 53 -c 0 0 -j ACCEPT
> -A OUTPUT -p udp -m udp --dport 53 -c 233937 16828408 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 43 -c 50 3000 -j ACCEPT
> -A OUTPUT -p tcp -m tcp --dport 25 -c 344 20640 -j ACCEPT
> -A OUTPUT -d 74.125.0.0/16 -p tcp -m tcp --dport 80 -c 1319 79140 -j ACCEPT
> -A OUTPUT -d 66.135.58.62/32 -p tcp -m tcp --dport 80 -c 153 9180 -j ACCEPT
> -A OUTPUT -d 192.0.80.244/32 -p tcp -m tcp --dport 80 -c 139 8340 -j ACCEPT
> -A OUTPUT -d 66.135.58.61/32 -p tcp -m tcp --dport 80 -c 112 6720 -j ACCEPT
> -A OUTPUT -d 192.0.80.246/32 -p tcp -m tcp --dport 80 -c 109 6540 -j ACCEPT
> -A OUTPUT -d 91.189.92.201/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
> -A OUTPUT -d 91.189.88.149/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
> -A OUTPUT -d 91.189.91.13/32 -p tcp -m tcp --dport 80 -c 3 180 -j ACCEPT
> -A OUTPUT -d 91.189.92.200/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
> -A OUTPUT -d 91.189.91.14/32 -p tcp -m tcp --dport 80 -c 2 120 -j ACCEPT
> -A OUTPUT -d 91.189.91.15/32 -p tcp -m tcp --dport 80 -c 7 420 -j ACCEPT
> -A OUTPUT -d 66.155.40.249/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
> -A OUTPUT -d 66.155.40.250/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
> -A OUTPUT -m state --state INVALID -c 10200 425557 -j DROP
> -A OUTPUT -c 5039 319910 -j LOG --log-prefix "fw-outbound: "
>
>
>>>
>>> My problem is I'm seeing some traffic that I'm not sure I should be
>>> seeing. I get periodically some traffic from source port 80. It's
>>> my understanding that rule 2 above would filter these out. When I
>>> try to access the webserver I don't get anything to show up in logs.
>>> Yet still I'm getting entries like these:
>>> <snip>
bad idea to snip here ;-p
bad idea also not to allow icmp error messages (type 3).
>>
>>
>> -m state --state INVALID -j DROP
>> look if they still come up...
>> also this might have influence:
>
> I have added this rule as you can see above, and although it seems to
> have stopped some of it, my 'phantom' traffic with source ports 80,443
> still continues.
do the filtering for state INVALID in INPUT/FORWARD chain!
>
>>
>> nf_conntrack_tcp_be_liberal - BOOLEAN
>> 0 - disabled (default)
>> not 0 - enabled
>>
>> Be conservative in what you do, be liberal in what you accept
>> from others.
>> If it's non-zero, we mark only out of window RST segments as
>> INVALID.
>>
>> see:
>> Documentation/networking/nf_conntrack-sysctl.txt
>
>
> cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
> 0
>
> This appears to be disabled.
>
Then try to enable it???
>>
>> I'd suggest to use ipset for all the IPs, ie:
>>
>> ipset create webservers hash:ip
>> ipset add webservers 91.189.92.201
>> and so on
>>
>> iptables -A OUTPUT -m set --match-set webservers dst -p tcp --dport 80 -m state --state NEW -j ACCEPT
>
>
> I have looked into ipset. I will try to implement it shortly, but
> this won't help my problems unfortunately.
Of course not, but it'll shorten your ruleset make it more readable and
will speed up everything, besides saving memory.
Best regards
Mart
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Some oddities while setting up outbound filtering on a web server
@ 2014-03-04 16:52 Anthony Taylor
2014-03-06 18:26 ` Mart Frauenlob
0 siblings, 1 reply; 9+ messages in thread
From: Anthony Taylor @ 2014-03-04 16:52 UTC (permalink / raw)
To: netfilter
On Sat, Feb 22, 2014 at 4:37 AM, Mart Frauenlob
<mart.frauenlob@chello.at> wrote:
>
> On 21.02.2014 23:36, Anthony Taylor wrote:
>>
>> I'm attempting to set up outbound filtering on a server to satisfy
>> PCI requirements. Here is what I have so far:
>>
>> iptables -L OUTPUT -n --line-numbers Chain OUTPUT (policy ACCEPT)
>
>
> policy of ACCEPT??? where's the filtering?
> only ACCEPT rules below, you want logging only?
Sorry I didn't explain. The last rule will be a DROP all, however for
now in the interest of not breaking anything I'm logging results
instead.
>
> use output of iptables -S .... -N is bad formatting for mail. also it
> needs -v to be complete like for rule #1 (guess that's for the lo iface)..
Here is the output of iptables -S OUTPUT -v
iptables -S OUTPUT -v
-P OUTPUT ACCEPT -c 5039 319910
-A OUTPUT -o lo -c 294541 22016298 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -c 11077878 13836891689 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -c 0 0 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -c 193399 5415172 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -c 0 0 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -c 233937 16828408 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 43 -c 50 3000 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 25 -c 344 20640 -j ACCEPT
-A OUTPUT -d 74.125.0.0/16 -p tcp -m tcp --dport 80 -c 1319 79140 -j ACCEPT
-A OUTPUT -d 66.135.58.62/32 -p tcp -m tcp --dport 80 -c 153 9180 -j ACCEPT
-A OUTPUT -d 192.0.80.244/32 -p tcp -m tcp --dport 80 -c 139 8340 -j ACCEPT
-A OUTPUT -d 66.135.58.61/32 -p tcp -m tcp --dport 80 -c 112 6720 -j ACCEPT
-A OUTPUT -d 192.0.80.246/32 -p tcp -m tcp --dport 80 -c 109 6540 -j ACCEPT
-A OUTPUT -d 91.189.92.201/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
-A OUTPUT -d 91.189.88.149/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
-A OUTPUT -d 91.189.91.13/32 -p tcp -m tcp --dport 80 -c 3 180 -j ACCEPT
-A OUTPUT -d 91.189.92.200/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
-A OUTPUT -d 91.189.91.14/32 -p tcp -m tcp --dport 80 -c 2 120 -j ACCEPT
-A OUTPUT -d 91.189.91.15/32 -p tcp -m tcp --dport 80 -c 7 420 -j ACCEPT
-A OUTPUT -d 66.155.40.249/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
-A OUTPUT -d 66.155.40.250/32 -p tcp -m tcp --dport 80 -c 0 0 -j ACCEPT
-A OUTPUT -m state --state INVALID -c 10200 425557 -j DROP
-A OUTPUT -c 5039 319910 -j LOG --log-prefix "fw-outbound: "
>>
>> My problem is I'm seeing some traffic that I'm not sure I should be
>> seeing. I get periodically some traffic from source port 80. It's
>> my understanding that rule 2 above would filter these out. When I
>> try to access the webserver I don't get anything to show up in logs.
>> Yet still I'm getting entries like these:
>> <snip>
>
>
> -m state --state INVALID -j DROP
> look if they still come up...
> also this might have influence:
I have added this rule as you can see above, and although it seems to
have stopped some of it, my 'phantom' traffic with source ports 80,443
still continues.
>
> nf_conntrack_tcp_be_liberal - BOOLEAN
> 0 - disabled (default)
> not 0 - enabled
>
> Be conservative in what you do, be liberal in what you accept
> from others.
> If it's non-zero, we mark only out of window RST segments as
> INVALID.
>
> see:
> Documentation/networking/nf_conntrack-sysctl.txt
cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
0
This appears to be disabled.
>
> I'd suggest to use ipset for all the IPs, ie:
>
> ipset create webservers hash:ip
> ipset add webservers 91.189.92.201
> and so on
>
> iptables -A OUTPUT -m set --match-set webservers dst -p tcp --dport 80 -m state --state NEW -j ACCEPT
I have looked into ipset. I will try to implement it shortly, but
this won't help my problems unfortunately.
>
> Best regards
>
> Mart
Thank you Mart for answering me.
Anthony Taylor
---------------------
http://www.fallsgeek.com
(940)228-4580
Wichita Falls, TX
Your connection for everything geek...
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-03-08 5:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-21 22:36 Some oddities while setting up outbound filtering on a web server Anthony Taylor
2014-02-22 10:37 ` Mart Frauenlob
2014-03-04 16:52 Anthony Taylor
2014-03-06 18:26 ` Mart Frauenlob
2014-03-06 23:39 ` Anthony Taylor
2014-03-07 4:46 ` Mart Frauenlob
2014-03-07 5:01 ` Neal Murphy
2014-03-08 2:05 ` Anthony Taylor
2014-03-08 5:20 ` Neal Murphy
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.