Re: pf blocking active connections
On 2013-02-07, Martijn van Duren martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Correct because the state table is checked *before* packets run through the firewall ruleset.
Re: pf blocking active connections
-- patrick keshishian pkesh...@gmail.com [2013-02-07 12:16:40 -0800]: look in 'man pfctl' and search for killing active sessions. On Thu, Feb 7, 2013 at 12:13 PM, Martijn van Duren martijn...@gmail.com wrote: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn If you have block drop quick rules in an anchor, I believe you do not need to reload the rules - the rule in the anchor becomes effective immediately, is that right? I use an anchor to block incoming smtp connections that way. Would you still need to use pfctl -k ... to kill the connection when using anchors? Jamie -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Re: pf blocking active connections
On Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: On 2013-02-07, Martijn van Duren martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Correct because the state table is checked *before* packets run through the firewall ruleset. Correct me if I'm wrong, but isn't that still somewhat dangerous? Say the next situation: I have a rule in my firewall that limits ssh connections to 3 every 30 seconds, if you exceed it your ip address is added to a table that has a drop quick on it. Now at the same time that same ip-adress is brute forcing on my ftp-port without building up a new connection between retries. When this ip address is automatically added to the blocked table he is qualified as bad traffic and I'd expect that other traffic to my server is cut short by then. Of course this is only an example of how an ip address could be automatically added to a table and I don't expect that every method is capable of also (easily,) automatically destroying an active connection. Martijn
Re: pf blocking active connections
On 2013-02-08, Martijn van Duren martijn...@gmail.com wrote: On Fri, 2013-02-08 at 08:23 +, Stuart Henderson wrote: On 2013-02-07, Martijn van Duren martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Correct because the state table is checked *before* packets run through the firewall ruleset. Correct me if I'm wrong, but isn't that still somewhat dangerous? Say the next situation: I have a rule in my firewall that limits ssh connections to 3 every 30 seconds, if you exceed it your ip address is added to a table that has a drop quick on it. Now at the same time that same ip-adress is brute forcing on my ftp-port without building up a new connection between retries. When this ip address is automatically added to the blocked table he is qualified as bad traffic and I'd expect that other traffic to my server is cut short by then. Of course this is only an example of how an ip address could be automatically added to a table and I don't expect that every method is capable of also (easily,) automatically destroying an active connection. Read the part of pf.conf(5) which describes the stateful tracking options that you are using and you can see if this applies to the way you are using them.
Re: pf blocking active connections
look in 'man pfctl' and search for killing active sessions. On Thu, Feb 7, 2013 at 12:13 PM, Martijn van Duren martijn...@gmail.com wrote: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn
Re: pf blocking active connections
On 02/07/13 15:13, Martijn van Duren wrote: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn I've seen this before. The attack continued because you have an existing state entry on the firewall that is allowing packets to continue. Use 'pfctl -k (host)' to kill off existing states. -- Scott McEachern https://www.blackstaff.ca
Re: pf blocking active connections
Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Martijn On Thu, 2013-02-07 at 21:21 +0100, Peter J. Philipp wrote: Someone on this list once helped me a great deal by mentioning the following: I bet you have a pf state left after reloading your firewall rules and since they don't get reset you have to kill them. Use pfctl -ss -vv to identify the state by id and use pfctl -k id -k id to kill it. That's how I do it these days. Cheers, -peter Am 07.02.2013 um 21:13 schrieb Martijn van Duren martijn...@gmail.com: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn
Re: pf blocking active connections
On 02/07/13 15:31, Martijn van Duren wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Martijn Yes. But it's not like it's hard to type pfctl -ef /etc/pf.conf pfctl -k 192.168.1.1 either. :) -- Scott McEachern https://www.blackstaff.ca
Re: pf blocking active connections
On Feb 07 21:31:11, martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Yes; these are two distinct actions: 1. killing an active connection (pfctl -k) 2. adding a host to a table (pfctl -t) (whatever it may mean in the ruleset)
Re: pf blocking active connections
On Feb 7, 2013 11:20 PM, Jan Stary h...@stare.cz wrote: On Feb 07 21:31:11, martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Yes; these are two distinct actions: 1. killing an active connection (pfctl -k) 2. adding a host to a table (pfctl -t) (whatever it may mean in the ruleset) Swap the order.
