PFSense blocking SSH access
-
But I have not been changing any permissions. I never changed anything from ssh since I never used it. I only have NAT and Firewall rules, DHCP, DNS and recently installed Squid. All was managed from the web interface.
Solution, clean install? Will config backup/restore all settings on the new pfinstall ?
-
What's the output of this in Diagnostics > Command Prompt
Command: ls -l /etc
Could this be another by-product of the /etc corruption crap? Is this a nano install?
-
Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.
-
This is the system log:
Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root[snip]
Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed
Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failedWhat do you have installed package wise and have you made any changes of your own at the command line?
You might want to look at this thread https://forum.pfsense.org/index.php?topic=92620.0
Where the "/etc/login.conf is not owned by root" message pops up, its related to the Jail which controls the permissions.
Now a possible quick and simple solution would be to use "chown root /etc/login*" but as you dont know what caused this problem, I'd investigate it first.
One thing I will say, if you have had your pfsense fw compromised and its not an unreported bug, all your devices that can be updated have the potential for being compromised, ie your bios, if using windows on a spin disk, where windows does a quick format, that can leave malware on the sectors of little used parts of the spin disk waiting to be reactivated even though windows follows an algo to split programs and files across the spin disk to speed up the user experience, printers, scanners etc where the firmware can also be updated. Its very easy decompiling code in an automated fashion and its quite easy auditing a network and systems for HW as the NSA would like to testify but cant due to their inherent requirement for operational secrecy, but they do use Linux alot. ;)
Dont under estimate the ingenuity of hackers.
What I'd be curious to know at this stage is if your pfsense machine has been compromised/hacked and if its being used in much the same way Lizard Squad have pwn'ed routers making them part of a botnet as you can read here.
http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-hacked-home-routers/If you just re-apply the 2.2.4 patch, you will be none the wiser to finding out if your pfsense fw has been hacked or not and if it has been hacked, then you still wont be able to stop the hack until you find how they hacked your pfsense fw. Do you see the problem?
So if you want to find out, which will help all the pfsense users, you could start by making an image, make a backup of your pfsense fw before reinstalling 2.2.4 or the 2.2.2 version thats got permission issues and then start comparing your dodgy image against the newly installed image.
If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure. It takes about 10mins to do a fresh install, restore a backup and about another 10mins to upgrade and restore the backup for that version. It also pays to keep copies of old backups before you upgraded in case you ever have to do some sort of forensic analysis like this.
dd or dcfldd will help you do images on a linux box, then to compare cmp using a command like "cmp /dev/hda /dev/hdb" will report the differences. This will report differences as your logs will be different, but if pfsense stores logs on a seperate partition (havent looked) then it will help reduce the number of errors reported as file date time stamps will be different and will get reported the most, but its the differences file sizes you want to look for as well as additional files that will help you find out if you have you any additional code added to your fw. If that shows nothing up, the other possibility is a zero day in some code used by pfsense which may not have been reported to FreeBSD amongst a few other possibilitys.
Of course what makes this exercise even harder is the packages you may have been running, might have been updated after you original installed them. One way around this problem is to make your own offline copy of the package repository to keep copies of what you installed at the time for such a forensic exercise. This link will help you with that problem. https://doc.pfsense.org/index.php/Creating_a_Custom_Package_Repository
Anyway just a bit of food for thought if you are so inclined to find out a little more about whether your pfsense box has been hacked or not. :)
fwiw.
-
I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2.
Leaving the loads of OT crap aside, why on earth would you be restoring known buggy versions that caused the huge /etc corruption issues? WTF really.
-
Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.
I'm gonna run the upgrade and see if that helps. If not I'll do a clean install.
-
What's the output of this in Diagnostics > Command Prompt
Command: ls -l /etc
Could this be another by-product of the /etc corruption crap? Is this a nano install?
Sorry I ran the upgrade and did not check that command. It's a regular install to a hdd.
-
This is the system log:
Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root
Sep 6 01:59:03 init: _secure_path: /etc/login.conf is not owned by root[snip]
Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
Sep 6 01:59:07 sshd[28230]: login_getclass: unknown class 'root'
Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
Sep 6 01:59:07 sshd[28230]: in openpam_check_desc_owner_perms(): /etc/pam.d/sshd: insecure ownership or permissions
Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failed
Sep 6 01:59:07 sshd[28230]: fatal: PAM: initialisation failedWhat do you have installed package wise and have you made any changes of your own at the command line?
You might want to look at this thread https://forum.pfsense.org/index.php?topic=92620.0
Where the "/etc/login.conf is not owned by root" message pops up, its related to the Jail which controls the permissions.
Now a possible quick and simple solution would be to use "chown root /etc/login*" but as you dont know what caused this problem, I'd investigate it first.
One thing I will say, if you have had your pfsense fw compromised and its not an unreported bug, all your devices that can be updated have the potential for being compromised, ie your bios, if using windows on a spin disk, where windows does a quick format, that can leave malware on the sectors of little used parts of the spin disk waiting to be reactivated even though windows follows an algo to split programs and files across the spin disk to speed up the user experience, printers, scanners etc where the firmware can also be updated. Its very easy decompiling code in an automated fashion and its quite easy auditing a network and systems for HW as the NSA would like to testify but cant due to their inherent requirement for operational secrecy, but they do use Linux alot. ;)
Dont under estimate the ingenuity of hackers.
What I'd be curious to know at this stage is if your pfsense machine has been compromised/hacked and if its being used in much the same way Lizard Squad have pwn'ed routers making them part of a botnet as you can read here.
http://krebsonsecurity.com/2015/01/lizard-stresser-runs-on-hacked-home-routers/If you just re-apply the 2.2.4 patch, you will be none the wiser to finding out if your pfsense fw has been hacked or not and if it has been hacked, then you still wont be able to stop the hack until you find how they hacked your pfsense fw. Do you see the problem?
So if you want to find out, which will help all the pfsense users, you could start by making an image, make a backup of your pfsense fw before reinstalling 2.2.4 or the 2.2.2 version thats got permission issues and then start comparing your dodgy image against the newly installed image.
If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure. It takes about 10mins to do a fresh install, restore a backup and about another 10mins to upgrade and restore the backup for that version. It also pays to keep copies of old backups before you upgraded in case you ever have to do some sort of forensic analysis like this.
dd or dcfldd will help you do images on a linux box, then to compare cmp using a command like "cmp /dev/hda /dev/hdb" will report the differences. This will report differences as your logs will be different, but if pfsense stores logs on a seperate partition (havent looked) then it will help reduce the number of errors reported as file date time stamps will be different and will get reported the most, but its the differences file sizes you want to look for as well as additional files that will help you find out if you have you any additional code added to your fw. If that shows nothing up, the other possibility is a zero day in some code used by pfsense which may not have been reported to FreeBSD amongst a few other possibilitys.
Of course what makes this exercise even harder is the packages you may have been running, might have been updated after you original installed them. One way around this problem is to make your own offline copy of the package repository to keep copies of what you installed at the time for such a forensic exercise. This link will help you with that problem. https://doc.pfsense.org/index.php/Creating_a_Custom_Package_Repository
Anyway just a bit of food for thought if you are so inclined to find out a little more about whether your pfsense box has been hacked or not. :)
fwiw.
I dont know if the pfsense has been compromised. I have not noticed any weird network or bandwith issues. As a precaution I will be changing the password and lock the box from the outside.
-
I dont know if the pfsense has been compromised. I have not noticed any weird network or bandwith issues. As a precaution I will be changing the password and lock the box from the outside.
You wont or shouldnt notice anything unusual by getting at the first node in a network, ie the router or firewall, thats the point of going for these targets.
-
I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2.
Leaving the loads of OT crap aside, why on earth would you be restoring known buggy versions that caused the huge /etc corruption issues? WTF really.
WTF Really?
If you upgraded to 2.2.2 from 2.2.1 and 2.2.1 was a fresh install, I'd reinstall 2.2.1, restore that backup before upgrading to 2.2.2. This way any upgrade errors/anomalies will likely be reproduced which might also have contributed to you permissions failure.
All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.
So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed. :D
-
Well, whatever it is, I'd re-apply latest 2.2.4 upgrade to get same permissions everywhere.
Upgrading to 2.2.4 fixed the problem. I can ssh as root now. :)
-
All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.
So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed. :D
OP should be using 2.2.4. Chances are his /etc got corrupted by the 2.2 sync mistakes that were corrected in 2.2.3 and enhanced in 2.2.4. The nano problem is slow writes. As I understand it the /etc corruption is not nano-specific but due to the slow writes and the misguided speedup method in 2.2.2 and older, nano was more susceptible.
I know I experienced it testing failover by removing power on APUs with full-install mSATA on good intel drives from netgate.
-
All releases have bugs, including the current version 2.2.4 which you are recommending people to upgrade to, these bugs are currently unknown bugs or zero days, until reported and are patched in 2.2.5 or later versions.
So get over the fact thats the name of the game, its a moving target. Its what makes or breaks sloppy firewalls and internet security practices leaving users exposed. :D
OP should be using 2.2.4. Chances are his /etc got corrupted by the 2.2 sync mistakes that were corrected in 2.2.3 and enhanced in 2.2.4. The nano problem is slow writes. As I understand it the /etc corruption is not nano-specific but due to the slow writes and the misguided speedup method in 2.2.2 and older, nano was more susceptible.
I know I experienced it testing failover by removing power on APUs with full-install mSATA on good intel drives from netgate.
Lesson learned. I will be updating to the latest releases as soon as they come out now.
-
It's just that telling someone to not update to the latest version because there might be a zero day is nonsense.
-
It's just that telling someone to not update to the latest version because there might be a zero day is nonsense.
But you'll note if you read carefully what I put, I have not told someone to NOT update to the latest version, but I have provided a way to find out what the problem might be if so inclined to do so for piece of mind not to mention it being an educational exercise as its assumed at this stage to be the /etc bug.
However on the laws of probability would you like to wager there are no zero days in 2.2.4? ;D
-
I agree the odds that the OP issue was because of a compromise what what?? More likely hit by lightning hit the power ball, and the mega millions while you bought 10 winning scratch offs in a row??
Its great and all that your tinfoil hat is 2 sizes too small for you and the NSA has a detail just to trail you.. But the rest of us live in the real world ;)
-
I agree the odds that the OP issue was because of a compromise what what?? More likely hit by lightning hit the power ball, and the mega millions while you bought 10 winning scratch offs in a row??
Its great and all that your tinfoil hat is 2 sizes too small for you and the NSA has a detail just to trail you.. But the rest of us live in the real world ;)
Why do you attack your users for suggesting a way for other users to educate themselves and have piece of mind over the what they use? Do you like keeping your users dumb?
I mentioned the NSA as its a good level to aim for, because they have only had a few major leaks in recent times, the most notable being Snowden.
So if you can lock your systems down to a level beyond their capabilities including the legals ones, then I'd say you have reasonably secure system because who wants to let their IT equipment becomes involved in hacking attacks on things like this? https://cryptome.org/2015/09/nnsa-iranian-target.htm
The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds. ;D
-
Yeah, sure like hell NSA is so lame to cut themselves off SSH by screwing up permissions in retarded way.
-
The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds. ;D
Please stop bringing NSA into every thread. Keep the roll of tinfoil all to yourself. Thanks.
-
The NSA are a finite resource and there are certainly less of them than the rest of the world so a little bit of education can go a long long way. You do the odds. ;D
Please stop bringing NSA into every thread. Keep the roll of tinfoil all to yourself. Thanks.
So when all other arguments have been lost, all you can revert to is the suggestion of tinfoil hats et al?
If people dont value privacy, they must be exhibitionists.
Yeah, sure like hell NSA is so lame to cut themselves off SSH by screwing up permissions in retarded way.
So pfsense screwed up permissions in a retarded way then? Doesnt inspire pfsense users with confidence does it?
