SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264
| Anonymous | Login | 2020-05-29 17:31 UTC |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||||
| 0002464 | Endian Firewall | Firewall (iptables) | public | 2009-12-01 03:53 | 2013-04-03 10:09 | ||||||
| Reporter | vikash | ||||||||||
| Assigned To | peter-endian | ||||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||||
| Status | confirmed | Resolution | open | ||||||||
| Platform | OS | OS Version | |||||||||
| Product Version | 2.3 | ||||||||||
| Target Version | future | Fixed in Version | |||||||||
| Summary | 0002464: Snort blocks smb and netbios over VPN despite FW rule | ||||||||||
| Description | Ive 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. | ||||||||||
| Tags | purple | ||||||||||
| Attached Files | |||||||||||
 Relationships |
|||||||
|
|||||||
 Relationships |
|
Notes |
|
|
(0003518) vikash (reporter) 2009-12-06 04: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 15: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 15: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 18: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 11: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 15: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 06: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 12:04 |
Actually disabled means a default inter-zone firewall configuration. |
|
(0003542) vikash (reporter) 2009-12-10 13: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 00:09 |
Hi, Please let me know if you need any further information for diagnosis. |
|
(0003589) peter-endian (administrator) 2009-12-18 18: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 01: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 10: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 |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-12-01 03:53 | vikash | New Issue | |
| 2009-12-06 04:23 | vikash | Note Added: 0003518 | |
| 2009-12-07 15:01 | mrkroket | Note Added: 0003519 | |
| 2009-12-07 15:26 | vikash | Note Added: 0003520 | |
| 2009-12-07 18:05 | peter-endian | Note Added: 0003523 | |
| 2009-12-07 18:05 | peter-endian | Status | new => feedback |
| 2009-12-08 11:37 | vikash | Note Added: 0003525 | |
| 2009-12-09 00:34 | peter-endian | Assigned To | => peter-endian |
| 2009-12-09 00:34 | peter-endian | Status | feedback => confirmed |
| 2009-12-09 00:34 | peter-endian | Target Version | => 2.3.1 |
| 2009-12-09 15:10 | peter-endian | Note Added: 0003533 | |
| 2009-12-09 15:10 | peter-endian | Status | confirmed => feedback |
| 2009-12-10 06:57 | vikash | Note Added: 0003537 | |
| 2009-12-10 12:04 | luca-endian | Note Added: 0003540 | |
| 2009-12-10 13:42 | vikash | Note Added: 0003542 | |
| 2009-12-16 00:09 | vikash | Note Added: 0003563 | |
| 2009-12-18 18:44 | peter-endian | Note Added: 0003589 | |
| 2009-12-18 18:45 | peter-endian | Status | feedback => confirmed |
| 2009-12-19 01:21 | peter-endian | Note Added: 0003598 | |
| 2010-01-21 17:28 | peter-endian | Relationship added | related to 0002457 |
| 2010-03-03 15:25 | ra-endian | Target Version | 2.3.1 => future |
| 2010-05-27 19:30 | luca-endian | Tag Attached: purple | |
| 2010-07-05 08:01 | luca-endian | Relationship added | related to 0003021 |
| 2013-04-03 10:09 | peter-endian | Note Added: 0008414 | |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
 |