Was I the target of a successful attack?
-
Thats a guess from here :)
-
how could I troubleshoot that further than reading from the logs in /var/log ?
-
Make your attack surface as small as possible and harden the pfsense box.
Disable SSH and predefined ports other than the outmost necessary.
Run Snort with block option enabled and released every 24hrs.
-
could it be an idea to have fail2ban as part of a pfsense installation?
fail2ban will prevent ddos attacks bringing down ssh.
-
Would be a viable option to have indeed!
-
Is it possible to add a feature request for fail2ban in pfsense? I think this is important to prevent (D)DOS attacks leading to crash of service so my hope is that it is added to pfsense core and not as a package.
-
@mir:
Is it possible to add a feature request for fail2ban in pfsense? I think this is important to prevent (D)DOS attacks leading to crash of service so my hope is that it is added to pfsense core and not as a package.
But it's already there. https://doc.pfsense.org/index.php/Sshlockout
-
Maybe not working then?? or enabled??
-
Maybe not working then?? or enabled??
Erm… read the logs posted?
Jan 4 00:51:23 pf01 sshlockout[37765]: Locking out 222.186.56.43 after 15 invalid attempts
Looks damn well working.
P.S. None of this protects against DDoS. Not possible. Won't save your WAN from crashing.
-
Yes I can see that :) Thank you.
https://doc.pfsense.org/index.php/HOWTO_enable_SSH_access
Not a way to configure it. And it seems that all though i disable it on the webgui then it doesnt get disabled in the console menu.
 -
The console is responsive ONLY when you enable and disable the sshd.
No can do via the gui.
-
No idea what are you trying to do with console. Serial console is not SSH.
-
I know…. but you can enable/disable it via the gui and via console.
It doesnt work disabling it via the GUI. Only via the console...
-
What's IT?!
-
SSH :)
-
Before disabling SSH via GUI:
# netstat -an | grep .22 tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTENAfter disabling SSH via GUI:
# netstat -an | grep .22 #Re-enabling SSH via console:
# netstat -an | grep .22 tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTENand checking back the GUI:
-
Doesnt work here…
-
P.S. None of this protects against DDoS. Not possible. Won't save your WAN from crashing.
This x 1000. I don't know why so many people incorrectly think that a simple firewall rule can mitigate a DDoS attack. I guess someone should tell the netops over at Sony and MS that they should add a firewall rule to stop their entire gaming networks from being blown offline like what happened a week or two ago…
-
It doesnt stop it or prevent it…
It handles it and doesnt interfere with normal services.
And dont let the security at Sony disturb you at night....if North Korea can get in, everyone can....
-
@KOM:
P.S. None of this protects against DDoS. Not possible. Won't save your WAN from crashing.
This x 1000. I don't know why so many people incorrectly think that a simple firewall rule can mitigate a DDoS attack. I guess someone should tell the netops over at Sony and MS that they should add a firewall rule to stop their entire gaming networks from being blown offline like what happened a week or two ago…
But depending on how your internal network is setup, the initial ddos on the wan could trigger a cascade of network activity which can slow the slower or under heavy load lans as well. With virtualisation becoming more common, the increased activity could also swap some cpu's as well.
