Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002464Endian FirewallFirewall (iptables)public2009-12-01 04:532013-04-03 12:09
Reportervikash 
Assigned Topeter-endian 
PrioritynormalSeveritymajorReproducibilityalways
StatusconfirmedResolutionopen 
PlatformOSOS Version
Product Version2.3 
Target VersionfutureFixed in Version 
Summary0002464: Snort blocks smb and netbios over VPN despite FW rule
DescriptionIve got EFW 2.3 with openvpn and client is a roadwarrior. VPN works fine ie. I can ping and SSH to machines on the GREEN zone to/from the openvpn client.

PING OK : VPN client <----> GREEN zone
SSH OK : VPN client <----> GREEN zone
smb/netbios BLOCKED : VPN client <----> GREEN zone

After almost a week I figured out that snort(IPS) will block smb and netbios over the VPN despite the VPN firewall rule to allow all access, also same result if VPN firewall is disabled.

If I switch off IPS then file and print sharing WORKS. There is nothing in the logs about these packets being blocked otherwise I would have found out much earlier.

Please advise a fix to this.
Tagspurple
Attached Files

- Relationships
related to 0003021closed Endian Firewall Allow with IPS breaks usability of Terminal Services, maybe also other protocols 

-  Notes
(0003518)
vikash (reporter)
2009-12-06 05:23

If I disable the rule "ET SCAN Behavioral Unusual Port 445 traffic, Potential Scan or Infection" in the IPS rule editor then file and print sharing works fine.
(0003519)
mrkroket (reporter)
2009-12-07 16:01

Firewall rules in EFW 2.3 has two types of allowing traffic to pass: "ALLOW" (a green arrow) and "ALLOW with IPS" (green arrow with a magnifying glass). The former doesn't go thru IPS.

 Maybe you can just use "ALLOW" instead "ALLOW with IPS" on you FW VPN rules for port 445, this way your smb VPN traffic won't be IPS inspected and you don't need to disable that IPS rule.
(0003520)
vikash (reporter)
2009-12-07 16:26

Yes i understand how it is suppose to work. However even if I turn off the VPN firewall snort is still filtering the VPN traffic. I have also tried to enable the VPN firewall and create a rule to "ALLOW" all traffic but still I have the same result.

Currently VPN firewall is enabled with the following rule:
Source : GREEN + OPENVPN
Destination : GREEN + OPENVPN
Service : <ANY>
Policy : ALLOW

But still I need to disable snort rules.
(0003523)
peter-endian (administrator)
2009-12-07 19:05

can you post the output of:

iptables -vnL VPNFW


it should use ACCEPT targets instead of ALLOW, in order not to pass through snort.
(0003525)
vikash (reporter)
2009-12-08 12:37

VPN firewall enabled with the above rule, output as below:
# iptables -vnL VPNFW
Chain VPNFW (7 references)
 pkts bytes target prot opt in out source destination
39786 5732K ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0

VPN firewall disabled, output as below:
# iptables -vnL VPNFW
Chain VPNFW (7 references)
 pkts bytes target prot opt in out source destination
    0 0 ALLOW all -- * * 0.0.0.0/0 0.0.0.0/0

In both cases snort is filtering my VPN traffic.
(0003533)
peter-endian (administrator)
2009-12-09 16:10

ok, when vpn firewall is disabled, it uses ALLOW, which is wrong.. i fixed that

but, when the vpn firewall is enabled and it uses ACCEPT, it should not pass through snort. can you confirm that?

the ACCEPT rule for sure does not pass through snort. if it still passes, there must be another rule which does.
(0003537)
vikash (reporter)
2009-12-10 07:57

OK, I will update you on that in asap.

FYI, both of my outgoing and inter-zone traffic firewall is switched off and I found that the chains are using ALLOW as below:

Chain OUTGOINGFW (1 references)
 pkts bytes target prot opt in out source destination
    0 0 ALLOW all -- br1 ppp0 0.0.0.0/0 0.0.0.0/0
    0 0 ALLOW all -- br2 ppp0 0.0.0.0/0 0.0.0.0/0
 496K 37M ALLOW all -- br0 ppp0 0.0.0.0/0 0.0.0.0/0

Chain ZONEFW (1 references)
 pkts bytes target prot opt in out source destination
    0 0 ALLOW all -- br0 br0 0.0.0.0/0 0.0.0.0/0
    0 0 ALLOW all -- br0 br2 0.0.0.0/0 0.0.0.0/0
    0 0 ALLOW all -- br0 br1 0.0.0.0/0 0.0.0.0/0
    0 0 ALLOW all -- br2 br2 0.0.0.0/0 0.0.0.0/0
    0 0 ALLOW all -- br1 br1 0.0.0.0/0 0.0.0.0/0
(0003540)
luca-endian (developer)
2009-12-10 13:04

Actually disabled means a default inter-zone firewall configuration.
(0003542)
vikash (reporter)
2009-12-10 14:42

peter: I have tested again and even when the rule is ACCEPT snort will still filter the traffic.

# iptables -vnL VPNFW
Chain VPNFW (7 references)
 pkts bytes target prot opt in out source destination
 2199 295K ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

Please check what else is wrong.
(0003563)
vikash (reporter)
2009-12-16 01:09

Hi, Please let me know if you need any further information for diagnosis.
(0003589)
peter-endian (administrator)
2009-12-18 19:44

if the rule is ALLOW and snort is disabled, that's fine. the ALLOW chain does not pass to snort if snort is disabled. if you enable it it will pass it.

ACCEPT definitively does not pass to snort.
so there must be another ALLOW rule which passes

wow.. well it is indeed:

  26M 23G ALLOW all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED

uhm.. did not think about this. not so easy to solve this however.
i must rethink it :/
(0003598)
peter-endian (administrator)
2009-12-19 02:21

2 possible solutions (however no chance to solve quickly)
probably (hopefully) there's a 3rd (the easier one)

solution 1:
- mark connections whose syn packet goes to the QUEUE
- ALLOW only related/established packets which are marked
- ACCEPT not marked packets
X problem: we exhaused the mark bandwith. using 1 bit of another bitmask is
  currently bad option.. maybe after kernel-upgrade
x big mess with all those markings

solution 2:
- move the accept all established/related rule to the LOGDROP chains in
  order that every firewall subsystem accepts its own established/related
  connections
- always create also an established/related rules before each ALLOW rule
X each established packet need to pass a lot of unnecessary rules
X much more rules than before

would be nice if connection tracking table would know if packets of the connections passed QUEUE.
(0008414)
peter-endian (administrator)
2013-04-03 12:09

well. the assumption that CONNMARK is working only in the mangle table was simply wrong.

solution 3:
- before passing to the QUEUE target, CONNMARK
- established/related rule should only ALLOW if it is CONNMARKed otherwise ACCEPT

- Issue History
Date Modified Username Field Change
2009-12-01 04:53 vikash New Issue
2009-12-06 05:23 vikash Note Added: 0003518
2009-12-07 16:01 mrkroket Note Added: 0003519
2009-12-07 16:26 vikash Note Added: 0003520
2009-12-07 19:05 peter-endian Note Added: 0003523
2009-12-07 19:05 peter-endian Status new => feedback
2009-12-08 12:37 vikash Note Added: 0003525
2009-12-09 01:34 peter-endian Assigned To => peter-endian
2009-12-09 01:34 peter-endian Status feedback => confirmed
2009-12-09 01:34 peter-endian Target Version => 2.3.1
2009-12-09 16:10 peter-endian Note Added: 0003533
2009-12-09 16:10 peter-endian Status confirmed => feedback
2009-12-10 07:57 vikash Note Added: 0003537
2009-12-10 13:04 luca-endian Note Added: 0003540
2009-12-10 14:42 vikash Note Added: 0003542
2009-12-16 01:09 vikash Note Added: 0003563
2009-12-18 19:44 peter-endian Note Added: 0003589
2009-12-18 19:45 peter-endian Status feedback => confirmed
2009-12-19 02:21 peter-endian Note Added: 0003598
2010-01-21 18:28 peter-endian Relationship added related to 0002457
2010-03-03 16:25 ra-endian Target Version 2.3.1 => future
2010-05-27 21:30 luca-endian Tag Attached: purple
2010-07-05 10:01 luca-endian Relationship added related to 0003021
2013-04-03 12:09 peter-endian Note Added: 0008414

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker