Great!
I have used:
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
On Vyatta 3.0 and it did the trick.
Normal connections appear to work normally.
The nmap scans are blocked now.
Your comments over the "New" state explain it very well and show the reason why those packets were getting through Vyatta.
Thanks!
Adrian
-------- Original Message --------
Subject: Re: [Vyatta-users] Vyatta Stateful Firewall Issue
From: Robyn Orosz <[EMAIL PROTECTED]>
Date: Wed, November 14, 2007 10:57 pm
To: "Adrian F. Dimcev" <[EMAIL PROTECTED]>
Cc: vyatta-users@mailman.vyatta.com
Hi Adrian,
First off, I apologize for the long delay in getting back to you but, I
think I have an answer for you. On the Vyatta router, try the following:
echo 0 > /proc/sys/net/netfilter/nf_conntrack_tcp_loose
Then try running the nmap ACK scan again. The RST packet, which is what
nmap is expecting in return, should not even get sent by the host since
the ACK packet should be blocked by the firewall this time.
What was happening is that a state of "NEW" in iptables means exactly
that--any new TCP packet. It does not mean a new TCP packet with the
SYN flag set. The 'nf_conntrack_tcp_loose' option can be modified
however, to enforce a more stringent set of checks on incoming TCP
packets. With this option set to 0, the firewall will compare the
packet against the existing conntrack entries and drop it because it is
not a valid packet for establishing a new connection and it is not part
of an existing established connection.
The benefit of having this value set to 3 (the default) is that it will
try and pick up any existing connections that were terminated as a
result of a system reload or other unexpected failure. So, it assumes
that the new ACK packet was part of a previous connection that got
dropped and cleared from the conntrack table when the system went down.
If this is not a concern of yours, then I'd say setting it to 0 would
not cause any other problems.
An enhancement request has actually already been open to allow the
nf_conntrack_tcp_loose value to be modified via the CLI:
https://bugzilla.vyatta.com/show_bug.cgi?id=2122
Another option is to add a rule directly in iptables that drops any NEW
packets that don't have the SYN flag set. EX:
iptables -I FORWARD 1 -p tcp ! --syn -m state --state NEW -j DROP
This rule gets added to the beginning of the iptables FORWARD chain and
drops any new packets that don't have the SYN flag set. The problem
with this workaround is that you have to be careful when running
firewall rules in the CLI and in iptables as their order of entry is
very important and can cause problems or confusion if it gets out of
sync. You'll also have to script any rules that you add directly into
iptables and also the echo into the nf_conntrack_tcp_loose so that your
changes will still exist after a reboot.
I also opened an enhancement request to add TCP flag match criteria into
the Vyatta firewall. So, in the future, the rule above should be
configurable via the CLI:
https://bugzilla.vyatta.com/show_bug.cgi?id=2474
Thank you and let me know if this works for you.
-Robyn
Adrian F. Dimcev wrote:
> Hi Robyn,
> Currently I'm doing the tests in VMware because my physical test machine
> has only one working NIC.
> Since I'm limited testing in VMware I'm cautios with conclusions.
> But bellow is what I have observed.
> VMware Server 1.0.4 build-56528.
> The machine behind Vyatta is a Windows 2003 Server SE R2
> SP2(192.168.40.2).
> The host machine is using Windows XP SP2.
> Vyatta persistent install.
> Win2003---Vyatta---Real Net 192.168.22.0/24
> My gateway is 192.168.22.1 on which I enabled the WebGUI(http) and it's
> playing "by the rules" on its internal interface for easy port scanning.
> As I understand and my tests shown the "state" parameter enables
> stateful TCP inspection on Vyatta(without it I'm able to pass any TCP
> segments):
> -with "new enable" implicitly other states are disabled so only TCP SYN
> packets are allowed through Vyatta.
> Other segments like: RST, SYN+ACK and so on are denied(that's what I
> have seen).
> So the full three-way handshake will never be establised, since the ACK
> segment sent back by the host behind Vyatta is denied.
> -with "established enable" connections established through Vyatta are
> permitted.
> Thus: "new+established enable" a host behind Vyatta can establish TCP
> connections as specified by the firewall rules.
> The other states without being explicitly defined are implicitly
> "disabled".
>
> On Vyatta VC2.2 basic stuff, NAT plus a firewall rule allowing http
> traffic(with or without specifying a destination port number for TCP
> thus limiting, same results):
> Internal Network: 192.169.40.0/24
> External Network: 192.168.22.0/24
> NAT:
> [EMAIL PROTECTED] show service nat
> rule 1 {
> type: "masquerade"
> outbound-interface: "eth0"
> source {
> network: "192.168.40.0/24"
> }
> }
> Firewall:
> [EMAIL PROTECTED] show firewall
> name blah {
> rule 1 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "192.168.22.0/24"
> port-number 80
> }
> }
> }
> [EMAIL PROTECTED] show interfaces ethernet eth1
> hw_id: 00:0c:29:85:e8:86
> address 192.168.40.1 {
> prefix-length: 24
> }
> firewall {
> in {
> name: "blah"
> }
> }
> [EMAIL PROTECTED] show interfaces ethernet eth0
> hw_id: 00:0c:29:85:e8:7c
> address 192.168.22.55 {
> prefix-length: 24
> }
> firewall {
> }
>
> Playing with nmap 4.20 + WinCap4.0.1 + Wireshark0.99.6a:
> "Working"(get a RST segment back + Wireshark traces showing the TCP
> segment passing through Vyatta):
> nmap --scanflags PSHACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags ACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags URGACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHURGACK 192.168.22.1 -p80 -n -P0
> nmap -sA 192.168.22.1 -p80 -n -P0
> nmap -sW 192.168.22.1 -p80 -n -P0 (the ACK story)
>
> "Not working"(these ones don't pass through Vyatta, examples):
> nmap --scanflags SYNACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags RSTACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHURGFINRSTSYNACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHURGFINRSTACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHURGFINACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHURGFIN 192.168.22.1 -p80 -n -P0
> nmap --scanflags FINACK 192.168.22.1 -p80 -n -P0
> nmap --scanflags FIN 192.168.22.1 -p80 -n -P0
> nmap --scanflags RST 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHFIN 192.168.22.1 -p80 -n -P0
> nmap --scanflags PSHFINACK 192.168.22.1 -p80 -n -P0
> nmap -sF 192.168.22.1 -p80 -n -P0
> nmap -sX 192.168.22.1 -p80 -n -P0
> nmap -sN 192.168.22.1 -p80 -n -P0
>
> Interesting facts:
> ***nmap -sT 192.168.22.1 -p80 -n -P0
> When state established disable and new enable:
> ->SYN
> <-SYNACK
> ->ACK never passes through Vyatta
> ->RST
> So 192.168.22.1 continues to send SYN+ACK since it never gets back the
> expected ACK.
> However all above labeled "Working" are "OK". So the "lonely" ACK for
> example is able to pass but the ACK from the TCP three-way handshake is
> denied.
>
> ***nmap -sA 192.168.22.1 -p80 -n -P0
> When state established enable and new disabled:
> This scan does not work anymore so the "lonely" ACK is denied.
>
>
> Vyatta VC3 config(webgui + ssh v2 enabled):
> Firewall:
> [EMAIL PROTECTED] show firewall
> name dog {
> rule 1 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "192.168.10.0/24"
> }
> }
> rule 2 {
> protocol: "udp"
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "192.168.10.0/24"
> }
> }
> rule 3 {
> protocol: "icmp"
> icmp {
> type: "8"
> code: "0"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "0.0.0.0/0"
> }
> }
> rule 4 {
> protocol: "icmp"
> icmp {
> type: "0"
> code: "0"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "0.0.0.0/0"
> }
> }
> rule 5 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> }
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "!192.168.10.0/24"
> port-number 80
> port-number 443
> }
> }
> rule 6 {
> protocol: "udp"
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "!192.168.10.0/24"
> port-number 53
> }
> }
> }
> name ext {
> rule 1 {
> protocol: "udp"
> action: "accept"
> source {
> address: "192.168.22.234"
> }
> destination {
> port-number 500
> }
> }
> rule 2 {
> protocol: "esp"
> action: "accept"
> source {
> address: "192.168.22.234"
> }
> destination {
> }
> }
> rule 3 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> }
> action: "accept"
> destination {
> port-number 22
> }
> }
> }
> name int {
> rule 1 {
> protocol: "tcp"
> state {
> established: "enable"
> new: "enable"
> invalid: "disable"
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> port-number 22
> port-number 443
> }
> }
> }
>
>
> [EMAIL PROTECTED] show interfaces
> loopback lo {
> }
> ethernet eth0 {
> hw-id: 00:0c:29:3c:4c:79
> address 192.168.22.225 {
> prefix-length: 24
> }
> firewall {
> local {
> name: "ext"
> }
> }
> }
> ethernet eth1 {
> hw-id: 00:0c:29:3c:4c:83
> address 192.168.40.1 {
> prefix-length: 24
> }
> firewall {
> in {
> name: "dog"
> }
> local {
> name: "int"
> }
> }
> }
>
> NAT:
> [EMAIL PROTECTED] show service nat
> rule 1 {
> type: "source"
> outbound-interface: "eth0"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "!192.168.10.0/24"
> }
> outside-address {
> address: 192.168.22.225
> }
> }
>
> A weird thing:
> When I specify a firewall rule like bellow for TCP without any "state"
> and with nmap send
> TCP segments like the ones from "Not Working", these packets seem "to
> escape" from the NAT proccess.
> The outside Wireshark trace shows the source IP address(192.168.40.2)
> preserved.
> [EMAIL PROTECTED] show firewall
> name blah {
> rule 1 {
> protocol: "tcp"
> action: "accept"
> source {
> network: "192.168.40.0/24"
> }
> destination {
> network: "192.168.22.0/24"
> port-number 80
> }
> }
> }
> Since it was a long post I hope I did not type anything wrong.
> Thanks,
> Adrian
> -------- Original Message --------
> Subject: Re: [Vyatta-users] Vyatta Stateful Firewall Issue
> From: Robyn Orosz <rorosz@vyatta.com>
> Date: Wed, November 07, 2007 3:39 pm
> To: "Adrian F. Dimcev" <adimcev@carbonwind.net>
> Cc: vyatta-users@mailman.vyatta.com
>
> Hi Adrian,
>
> What rules have you placed in your firewall and what options are you
> using to send ACK segments with nmap (specific ports etc?)
>
> Thank you,
>
> Robyn
>
> Adrian F. Dimcev wrote:
>
>> I've been testing with vc2.2 too.
>> Same problem regarding the ACK segment.
>> Everything else seems to work just fine(is blocking other TCP segments
>> with different flag combinations).
>> However the "lonely" ACK segment is passing free through Vyatta.
>> Looks like a bug to me.
>>
>>
>> _______________________________________________
>> Vyatta-users mailing list
>> Vyatta-users@mailman.vyatta.com
>> http://mailman.vyatta.com/mailman/listinfo/vyatta-users
>>
>>
>
>
>
_______________________________________________ Vyatta-users mailing list Vyatta-users@mailman.vyatta.com http://mailman.vyatta.com/mailman/listinfo/vyatta-users
