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
}
