# Flood protecction



## wolffnx (Mar 13, 2020)

Hi, in my opinion is a hardware saturate resource,but please any help....
the scenario:
one FreeBSD box that is a proxy server and firewall , the attack dont work from outside..no effect , but in my LAN yes, saturate the network and the conections to the server
are refused ( i'tested accesing from my cel phone in 4g from ssh,from outside) , and in the LAN the coneccions are refused, the existing ones like ssh become very slow.
And when i'stop the attack the coneccions are acepted and the server immediately starts to respond
note, change the real IP of mi server/LAN and  resume the firewall for this post
my server will be 192.168.1.1 and my LAN 192.168.1.0/24

the comand is `hping3 --syn --flood --rand-source --destport 443 192.168.1.1`

In the server have the usual :


sysctl.conf


```
kern.msgbuf_show_timestamp=1       # display timestamp in msgbuf (default 0)
net.inet.icmp.drop_redirect=1      # no redirected ICMP packets (default 0)
net.inet.ip.check_interface=1      # verify packet arrives on correct interface (default 0)
net.inet.sctp.blackhole=2          # drop stcp packets destined for closed ports (default 0)
net.inet.tcp.blackhole=2           # drop tcp packets destined for closed ports (default 0)
net.inet.tcp.fast_finwait2_recycle=1 # recycle FIN/WAIT states quickly, helps against DoS, but may cause false RST (default 0)
net.inet.tcp.finwait2_timeout=1000 # TCP FIN_WAIT_2 timeout waiting for client FIN packet before state close (default 60000, 60 sec)
net.inet.udp.blackhole=1           # drop udp packets destined for closed sockets (default 0)
```

mi PF config:


```
ext_if="em0"
int_if="em1"

#outside-in
in_External="{22}"
###########


############forward int_if
forward_ports="{53,80,22}"
forward_ports_udp="{53}"

#################################
set limit { states 40000, frags 20000, src-nodes 20000 }

set skip on lo0


set optimization aggressive
set block-policy drop
ext_if="em0"
int_if="em1"

#outside-in
in_External="{22}"
###########


############forward int_if
forward_ports="{53,80,22}"
forward_ports_udp="{53}"

#################################
set limit { states 40000, frags 20000, src-nodes 20000 }

set skip on lo0


set optimization aggressive
set block-policy drop

scrub in on $ext_if all fragment reassemble
scrub in on $int_if all fragment reassemble

nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)

block  all

antispoof  for $ext_if inet
antispoof  for $int_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $int_if from any to 255.255.255.255
block in  quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any
block in log on $int_if from !192.168.1.0/24 to any




####outside to inside
pass in on  $ext_if inet proto tcp from any to any port $in_External flags S/SA  keep  state (max-src-conn 15, max-src-conn-rate 15/5)

##################################################


####pass out on ext_if all permited
pass out on $ext_if inet proto tcp from any to any  keep state
pass out on $ext_if inet proto udp from any to any
#########################################

scrub in on $ext_if all fragment reassemble
scrub in on $int_if all fragment reassemble

nat on $ext_if inet from ! ($ext_if) to any -> ($ext_if)

block  all

antispoof  for $ext_if inet
antispoof  for $int_if inet
block in from no-route to any
block in from urpf-failed to any
block in quick on $int_if from any to 255.255.255.255
block in  quick on $ext_if from { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 255.255.255.255/32 } to any
block in log on $int_if from !192.168.1.0/24 to any



pass in  on $int_if inet proto tcp from 192.168.1.0/24 to any  port $forward_ports flags S/SA keep state
pass in   on $int_if inet proto udp from 192.168.1.0/24 to any port $forward_ports_udp 
pass out on $int_if inet proto tcp from any to any port $forward_ports flags S/SA keep state



####outside to inside
pass in on  $ext_if inet proto tcp from any to any port $in_External flags S/SA  keep  state (max-src-conn 15, max-src-conn-rate 15/5)

##################################################


####pass out on ext_if all permited
pass out on $ext_if inet proto tcp from any to any  keep state
pass out on $ext_if inet proto udp from any to any
#########################################
```



and `pftop -i em1` outpup:


```
pfTop: Up State 1-20/37459, View: default, Order: source port, Cache: 10000 PAUSED                                                            08:53:52

PR        DIR SRC                                   DEST                                          STATE                AGE       EXP     PKTS    BYTES
tcp       In  157.193.44.79:1                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  59.76.255.158:2                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  71.111.58.195:3                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  87.12.21.100:4                        192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  198.117.244.170:5                    192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  159.68.114.98:6                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  154.143.12.29:7                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  117.117.145.48:8                      192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  144.213.16.193:9                      192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  98.76.210.10:10                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  117.40.179.95:11                      192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  230.124.111.240:12                    192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  55.247.74.154:13                      192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  155.55.29.27:14                       192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  253.132.210.33:15                     192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
tcp       In  177.48.10.240:16                      192.168.1.1:443                           CLOSED:SYN_SENT     00:00:19  00:00:00        1       40
```


the conections for closed ports are in STATE CLOSED, so PF is working well
but the line in sysctl.conf

```
net.inet.tcp.blackhole=2
```
 should not discard/drop the connection before PF?

my network cards are Intel 82574L Gigabit Network Connection , there is any workaround for not saturate like this?

thanks!


----------



## rootbert (Mar 13, 2020)

the default state limit is 10000 ... see https://www.openbsd.org/faq/pf/options.html ... so change that with "set limit states XXX"


----------



## wolffnx (Mar 14, 2020)

rootbert said:


> the default state limit is 10000 ... see https://www.openbsd.org/faq/pf/options.html ... so change that with "set limit states XXX"



yes, i'will change it and probe it,but there is a problem, the new conections(the good ones) they will not be rejected?


----------



## rootbert (Mar 14, 2020)

they will be rejected. when the state table is full then the system cannot open new connections, however, you candecrease the time when a state gets removed after the last packet. tipp from my side: allow stateless ssh from your infrastructure so you can always login, even when under attack.
added: when a good connection is already established then it will not be dropped. However, if you are under attack then chances are low that your system will accept one of the few good new connections (how should it know)


----------



## wolffnx (Mar 14, 2020)

rootbert said:


> they will be rejected. when the state table is full then the system cannot open new connections, however, you candecrease the time when a state gets removed after the last packet. tipp from my side: allow stateless ssh from your infrastructure so you can always login, even when under attack.
> added: when a good connection is already established then it will not be dropped. However, if you are under attack then chances are low that your system will accept one of the few good new connections (how should it know)



i'never heard about stateles,how is it?


----------



## rootbert (Mar 14, 2020)

never did any performance tests since none of my systems have > 1GBit, but it's a nice rescue anchor for my stateless ssh connections because they always work no matter how many states the firewall holds. However, if one beliefs various sources on the net, ipfw manages quite some more packets per second compared to pf.


----------



## wolffnx (Mar 14, 2020)

*i'never heard about stateles,how is it?*

my mistake  , so i'have to create a rule like this for ssh incoming traffic for outside:


```
pass in on  $ext_if inet proto tcp from any to any port 22
```


----------



## rootbert (Mar 14, 2020)

With stateless you also have to think about the packets that answer a request. With stateful your "pass in" is enough, because a state is created internally and the packets belonging to that connection are matched and sent. A stateless firewall accepts packets on a port, but it does not spend any resources on trying to match a packet to a connection, thus you explicitely have to allow also the outgoing packets. Thus, stateless packet filters usually are much faster in handling packets.
a stateless rule in pf would be:

```
pass in quick on any proto tcp from any to { $self_intern $self_extern } port {22} no state flags any 
pass out quick on any proto tcp from { $self_intern $self_extern } port {22} to any no state flags any
```


----------



## wolffnx (Mar 14, 2020)

rootbert said:


> With stateless you also have to think about the packets that answer a request. With stateful your "pass in" is enough, because a state is created internally and the packets belonging to that connection are matched and sent. A stateless firewall accepts packets on a port, but it does not spend any resources on trying to match a packet to a connection, thus you explicitely have to allow also the outgoing packets. Thus, stateless packet filters usually are much faster in handling packets.
> a stateless rule in pf would be:
> 
> ```
> ...



excelent explication,and thanks for
the example code
always learn something new about PF features


----------



## wolffnx (Mar 14, 2020)

il forgot,i'made a test in my server, while launching the flood from my LAN,   in the server execute:

`sleep 3 && pfctl -F all`
this in a loop for 6/7 times
sometimes i'got response from the server to a new ssh connection but
one attack like this from the LAN is very dificult to control
but a pair of stateless rules sounds good,i' will try it


----------

