My pfsense failed an audit by securitymetrics.com



  • TCP 443 https Risk Level:5
    Synopsis : The remote service supports the use of medium strength SSL ciphers. Description :
    The remote host supports the use of SSL ciphers that offer medium strength encryption, which
    we currently regard as those with key lengths at least 56 bits and less than 112 bits. Solution:
    Reconfigure the affected application if possible to avoid use of medium strength ciphers. Risk
    Factor: Medium / CVSS Base Score : 5.0 (CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)

    Is this easily resolved?  And I mean not by disabling https access.


  • Rebel Alliance Developer Netgate

    You chose to leave your WebGUI (or an internal web server?) exposed to the world, it will always be a risk, regardless of cypher strength.

    The real solution is to not do that – require a VPN connection of some sort (OpenVPN, IPsec, etc) which can then grant you access to the WebGUI.

    If it's an internal web server with a forwarded port, then, it's not a pfSense issue, this is a problem with your web server.



  • This was for the pfsense web gui.  Is there a way to make the https server on pfsense use a stronger cipher say minimum 256?  That would actually be considered acceptable.


  • Rebel Alliance Developer Netgate

    You might be able to generate a stronger key, but I cannot emphasize enough how bad an idea it is to leave your router's web interface exposed to the world.

    Regardless of cipher, I would flag that as a failure on an audit myself.



  • I agree. Never expose your firewall to the world. That's a big mistake and defeats the purpose of the firewall. Like suggested, if you need to make changes to the firewall from a remote location… always use SSH.



  • I would also suggest you use ssh with password login disabled. Only pub-key auth…

    The you can tunnel port 443 into ssh and get your WI with https://localhost from your computer initiating the ssh session.


  • Rebel Alliance Developer Netgate

    I wouldn't recommend leaving ssh open to the world on the default port, either.

    Pub key auth is a must, as well as using non-standard ports. Something unlikely to be guessed or scanned, but in reality anything but port 22 is probably safer.



  • But with pubkey enabled it is quite safe to use port 22…


  • Rebel Alliance Developer Netgate

    No reason to tempt fate there. :-)



  • Thanks for all the feedback.  As a bandaid I locked it down to only me remote network for HTTPS.  I will also look into the other suggestions.  Thanks again.

    Mark



  • Instead of just allowing everyone to access the WebGui, restrict it to cretin IP ranges that you often use. This has proven good to me so far with SSH and WebGUI. I do this in case the VPN tunnel breaks, i still have a way in.

    The best way for normal access should be through a VPN.



  • Assuming pfsense is still using lighttpd as the webserver,  you can configure what ciphers it speaks.  http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:SSL

    If you look at the PCI DSS Compliance section that shows some higher security ciphers.  You can configure lighttpd to only use those.  This is of course besides the sensible advice above about restricting access to the web interface.  But should you ever see this issue on another lighttpd server you can see how to correct it :).



  • Tried setting up SSH Authorized Key but it does not seem to work.

    I pasted the following from the Public Key File created using puttygen:

    –-- BEGIN SSH2 PUBLIC KEY ----
    Comment: "rsa-key-20100303"
    AAAAB3NzaC1yc2EAAAABJQAAAIEAiNNMQ8KAZQhyRdek5p/anBZpBiBCsiF3BzGb
    vDhGtCC+oFj7/jJsmLcPmUcxQp/L5Gz0fBzQUEcd1AZK3gTG/pEHzE8x2PU5iqSX
    +LBbHIDQZuz461iiMwnL9Xu8I9T2+B7i3KX/t34SvubWYPvP6ZO/Q/+Rdmbwmmsb
    GZ2FC1U=
    ---- END SSH2 PUBLIC KEY ----

    I was still able to connect via SSH without the need of any private key.  Also disable passord login for secure shell.  Still getting prompt for username password and able to login.


  • Rebel Alliance Developer Netgate

    Try omitting the begin, end, and comment lines.



  • Like this:

    AAAAB3NzaC1yc2EAAAABJQAAAIEAiNNMQ8KAZQhyRdek5p/anBZpBiBCsiF3BzGb
    vDhGtCC+oFj7/jJsmLcPmUcxQp/L5Gz0fBzQUEcd1AZK3gTG/pEHzE8x2PU5iqSX
    +LBbHIDQZuz461iiMwnL9Xu8I9T2+B7i3KX/t34SvubWYPvP6ZO/Q/+Rdmbwmmsb
    GZ2FC1U=

    or

    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAiNNMQ8KAZQhyRdek5p/anBZpBiBCsiF3BzGb
    vDhGtCC+oFj7/jJsmLcPmUcxQp/L5Gz0fBzQUEcd1AZK3gTG/pEHzE8x2PU5iqSX
    +LBbHIDQZuz461iiMwnL9Xu8I9T2+B7i3KX/t34SvubWYPvP6ZO/Q/+Rdmbwmmsb
    GZ2FC1U=



  • Like the second one. That's what I do…



  • When I use the one with ssh-rsa I get connection refused.  When I go to auth in putty and select the private.pkk file and try to open the connection I get connection error.



  • Did you get your key by opening puttygen and loading your private key there?



  • I generate public key and copy then export private key. Right?



  • You can use puttygen to generate a pair and then copy the key from the top of the window which says "Public key for pasting into OpenSSH authorized_keys file:"…



  • Here is a new example:

    ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIBb5HVQf5Nbdu6+bC2dE2bM1ZNC/7USV/jJRcRNtBSu9plZCEAz4BRwCkMiuHlFNHT+FO6fjcdg9Jzb/csZ8SyVP9wY0iSDYeDd9eY5N04LceCGb2AxqrL24a09BftVSlQnXvbsPaume+fKgVVMo6NCDoUhPI917PUyIlNZ8YBD9w== rsa-key-20100303

    I pasted this into System:Advanced:Secure Shell:Authorized Keys.  Saved.

    Then open Putty and loaded session with internal pfsense IP.  Clicked on Auth in Putty and browsed to the Private.pkk file which I downloaded from puttygen.

    Fail.  ???



  • Yep. That sounds about right. Are you running 1.2.3 also?



  • 1.2.3-RELEASE
    built on Mon Dec 7 20:21:30 EST 2009



  • Should I remove:  rsa-key-20100303 from the end of the key?



  • Nope. I have that, too….

    Please check when logged in that the key is really there....

    cat .ssh/authorized_keys



  • you mean check via winscp?



  • No. Login via putty and ssh. And then do that command in /root



  • Seems to be going from Bad to worse.

    I deleted the key and unchecked the box disabling password for SSH.  No when I connect I get:

    Disconnected:  No Supported authentication methods available.



  • Use your console to connect to the box…



  • ok.  Disables SSH and enabled and now I am back in.

    cat: .ssh/authorized_keys: No such file or directory



  • Ok.  So I repasted info and connected with private ket and got the following:

    login as: root
    Server refused our key
    Using keyboard-interactive authentication.
    Password:

    Though I was able to get through….



  • Also when you login as 'admin'?



  • I am able to get in no matter what…



  • Log in again and then do:

    • cd /root
    • cd .ssh
    • ls -la (post output, there should be a authorized_keys files after you pasted your key via GUI)

    Are you running on embedded?



  • Yes Embedded….

    [1.2.3-RELEASE]                                                                [root@wall.test.local]/root(1): cd /root
    [1.2.3-RELEASE]                                                                [root@wall.test.local]/root(2): cd .ssh
    [1.2.3-RELEASE]                                                                [root@wall.test.local]/root/.ssh(3): ls -la
    total 1
    drwx–----  2 root  wheel  512 Mar  4 07:49 .
    drwxr-xr-x  4 root  wheel  512 Mar  4 05:08 ..
    [1.2.3-RELEASE]                                                                [root@wall.test.local]/root/.ssh(4):



  • So there is something wrong with your install. The authorized_keys file does not get created.

    Try this:

    • /etc/rc.conf_mount_rw
    • then create the file manually with e.g. vi /root/.ssh/authorized_keys and paste in your key
    • /etc/rc.conf_mount_ro

    Then check again…



  • vi/root/.ssh/authorized_keys: Command not found.



  • here is a screen shot via winscp….




  • vi and a [space] after that…



  • @kapara:

    here is a screen shot via winscp….

    So? That is /etc/ssh and on your box…
    You generated the key on your windows system, didn't you?
    The keys need to be in /root/.ssh/


Log in to reply