A possible way to solve this problem is to modify the default filter exceptions that where added by vpncfg.nlm. Only allow access to that port from host(s) or subnets where known vpn clients or slave servers are being used. Granted it would restrict access to vpn clients that never use the same address or subnet, but it just a work around until a patch can be applied. Example of modified UDP and TCP filters for 10.2.3.0/24 subnet : ---Example for TCP execption Source Interface Type: Interface Source Interface: 3C90X_2 (Public) Destination Interface Type: Interface Destination Interface: <All Interfaces> Packet Type: VPN-AuthGW Protocol: TCP Src Port(s): <All> Dest Port(s): 353 ACK Bit Filtering: Disabled Stateful Filtering: Disabled Src Addr Type: Network(**Modified**) Src IP Address: 10.2.3.0/255.255.255.0(**Modified**) Dest Addr Type: Host Dest IP Address: 209.x.x.x(ip of the server) Logging: Disabled ---Example for UDP execption Source Interface Type: Interface Source Interface: 3C90X_2 (Public) Destination Interface Type: Interface Destination Interface: <All Interfaces> Packet Type: VPN-KeepAlive Protocol: UDP Src Port(s): <All> Dest Port(s): 353 ACK Bit Filtering: Disabled Stateful Filtering: Disabled Src Addr Type: Network(**Modified**) Src IP Address: 10.2.3.0/255.255.255.0(**Modified**) Dest Addr Type: Host Dest IP Address: 209.x.x.x(ip of the server) Logging: Disabled At 07:41 PM 4/20/2001 +0100, Richard Bartlett wrote: >Client to site VPN services can be halted by a SYN flood attack on >port 353, causing the port to close and the service to cease >functioning until the server is rebooted. > >Vulnerable Packages/Systems: > >[Confirmed] Novell BorderManager Enterprise Edition 3.5 >[Suspected] Novell BorderManager 3.0 - 3.6 -- Randy Mclean Security/Network Administrator rmcleanat_private
This archive was generated by hypermail 2b30 : Thu Apr 26 2001 - 16:27:58 PDT