[CentOS-docs] CentOS as a Guest OS in VirtualBox
New DRAFT page - comments are invited. http://wiki.centos.org/HowTos/Virtualization/VirtualBox/CentOSguest Phil ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
Hi all, I'm happy to announce a new tutorial! https://alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial This tutorial walks a user through the entire process of building a 2-Node cluster for making KVM virtual machines highly available. It uses Red Hat Cluster services v3 and DRBD 8.3.12. It is written such that you can use entirely free or fully Red Hat supported environments. Highlights; * Full network and power redundancy; no single-points of failure. * All off-the-shelf hardware; Storage via DRBD. * Starts with base OS install, no clustering experience required. * All software components explained. * Includes all testing steps covered. * Configuration is used in production environments! This tutorial is totally free (no ads, no registration) and released under the Creative Common 3.0 Share-Alike Non-Commercial license. Feedback is always appreciated! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
This is sweet, I am in need for doing something for a SMB and nothing is out there that is affordable for small busineesses, will look into this. On Tue, Jan 3, 2012 at 8:29 AM, Digimer li...@alteeve.com wrote: Hi all, I'm happy to announce a new tutorial! https://alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial This tutorial walks a user through the entire process of building a 2-Node cluster for making KVM virtual machines highly available. It uses Red Hat Cluster services v3 and DRBD 8.3.12. It is written such that you can use entirely free or fully Red Hat supported environments. Highlights; * Full network and power redundancy; no single-points of failure. * All off-the-shelf hardware; Storage via DRBD. * Starts with base OS install, no clustering experience required. * All software components explained. * Includes all testing steps covered. * Configuration is used in production environments! This tutorial is totally free (no ads, no registration) and released under the Creative Common 3.0 Share-Alike Non-Commercial license. Feedback is always appreciated! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
On 01/03/2012 09:43 AM, Tom Bishop wrote: This is sweet, I am in need for doing something for a SMB and nothing is out there that is affordable for small busineesses, will look into this. Feel free to ask if you have any questions. :) -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
Thanks! This is great - I've been planning and am half-way though creating such a cluster, but I've been using Fedora15/16 as Centos6 wasn't out when I started. Any idea if this will work with Fedora as a host OS, or does it have to be RHEL/Centos? -Original message- To: CentOS mailing list cen...@centos.org; CentOS virtualization centos-virt@centos.org; From: Digimer li...@alteeve.com Sent: Tue 03-01-2012 14:29 Subject: [CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6 Hi all, I'm happy to announce a new tutorial! https://alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial This tutorial walks a user through the entire process of building a 2-Node cluster for making KVM virtual machines highly available. It uses Red Hat Cluster services v3 and DRBD 8.3.12. It is written such that you can use entirely free or fully Red Hat supported environments. Highlights; * Full network and power redundancy; no single-points of failure. * All off-the-shelf hardware; Storage via DRBD. * Starts with base OS install, no clustering experience required. * All software components explained. * Includes all testing steps covered. * Configuration is used in production environments! This tutorial is totally free (no ads, no registration) and released under the Creative Common 3.0 Share-Alike Non-Commercial license. Feedback is always appreciated! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
On 01/03/2012 10:20 AM, Clint Redwood wrote: Thanks! This is great - I've been planning and am half-way though creating such a cluster, but I've been using Fedora15/16 as Centos6 wasn't out when I started. Any idea if this will work with Fedora as a host OS, or does it have to be RHEL/Centos? It should work, more or less, as-is on Fedora. Do note though that things are changing rapidly and that Fedora is already at the end of the 3.1 version, about to go 3.2, where EL6 is (and will remain) on 3.0. Also, I can not recommend ever using Fedora in production as a server. The support cycle is far too short and the testing not nearly as extensive as EL6 proper. I've tested several times on Fedora, and inevitably run into gotchas. So in short; I *strongly* recommend using an EL6 distro. Cheers! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS-virt] turning off udev for eth0
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration. Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] turning off udev for eth0
Greetings, - Original Message - I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration. Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. That's how it is on physical machines (I image lab computers and have to clean up the udev rules file among other things) and would expect the same behavior from virtual machines. The limitations of virt-clone are known and are being addressed in virt-sysprep... which hasn't made it to RHEL yet I don't think... but you can find out about it here: http://rwmj.wordpress.com/2011/10/08/new-tool-virt-sysprep/ TYL, -- Scott Dowdle 704 Church Street Belgrade, MT 59714 (406)388-0827 [home] (406)994-3931 [work] ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS-es] (sin asunto)
buenas tardes my nombre es henry estoy iniciandome en servidores proxy, ya tengo construido un servidor pero me gustaria administrar el ancho de banda para un cierto numero de usuarios me podrias ayudar por favor. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] (sin asunto)
Te recomendaría investigar un poco sobre squid + delay pools. Y los usuarios puedes distinguirlos por host (lo mas sencillo), o por usuario / grupo (ldap / winbind) El 2 de enero de 2012 17:39, Henry Cussi henryc...@hotmail.com escribió: buenas tardes my nombre es henry estoy iniciandome en servidores proxy, ya tengo construido un servidor pero me gustaria administrar el ancho de banda para un cierto numero de usuarios me podrias ayudar por favor. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- --- Sebastian Juárez Mail: ssebb...@gmail.com ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS-es] (sin asunto)
On 01/02/2012 03:39 PM, Henry Cussi wrote: buenas tardes my nombre es henry estoy iniciandome en servidores proxy, ya tengo construido un servidor pero me gustaria administrar el ancho de banda para un cierto numero de usuarios me podrias ayudar por favor. claro, revisa el htb.init o el cbq.init saludos epe ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 11:04 PM, Les Mikesell wrote: On Tue, Jan 3, 2012 at 12:41 AM, Bennett Haseltonbenn...@peacefire.org wrote: Standard/non-standard isn't the point. The point is to control what an app can do even if some unexpected flaw lets it execute arbitrary code. What's the scenario where this port restriction would make a difference? Suppose an attacker does find a way to make squid execute arbitrary code. Then if part of their plan is to make squid start listening on a second port in addition the one it's already using (3128, the default), they could just make it listen on another port like 8080 which is permitted by SELinux. You are thinking the wrong direction. No one can anticipate every possibility that someone might do to take advantage of vulnerabilities. Instead think in terms of the minimum the application should be allowed to do under any circumstance. Then you'll also have firewalls blocking every port except where you know your own application is listening anyway. I agree about minimum permissions, but my argument here is that permitting squid to listen on any arbitrary port it wants is just as minimum, in terms of security implications, as permitting it to listen on port 3128. Either way, once the attacker has connected to it, the scenarios are identical from that point on (either the attacker knows an exploit to take control of squid, or they don't; either the squid process runs with sufficiently high privileges that the exploit can be used to do damage, or it can't). In other words, when SELinux causes a problem, it can take hours or days to find out that SELinux is the cause Errr, no - all you have to do is disable SELinux and see if the behavior changes. On your test machine where you should be testing changes, this shouldn't be a big risk. Well I meant, if you didn't happen to know enough about SELinux to realize that it was the cause of many non-standard system behaviors. If you knew about SELinux as one of those things that frequently gets in the way, then you'd probably think of it a lot faster :) Well, the other security rules for linux/unix are trivial, so SELinux should pop to mind immediately for surprising behavior, especially if you have changed configurations from the expected defaults. One could easily say, Hey, you should just know about SELinux, but the problem is that there can be dozens of things on a machine that could potentially cause failures (without giving a useful error message), and each additional thing that you should just know about, decreases the chances that any one person would actually know to check them all, if they're not a professional admin. OK, the point here is that you have some unknown vulnerability that the stock linux security mechanisms aren't handling. I'm more inclined to think it is a software bug rather than brute-forcing a password, but that's speculation. So, which do you think will be more difficult - tracking down some unknown bug in millions of lines of code with no real evidence, or adding another layer of security that is mostly pre-configured in the distro anyway? Well I'm trying to weigh the costs of using it -- with all of the silent failures for operations that have no security implications -- against the reduced risks. If many exploits against httpd, for example, could have been prevented by SELinux, that may make it worth it. (And of course the suggestions about how to diagnose problems caused by SELinux are helpful.) Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 01/02/2012 10:48 PM, Bennett Haselton wrote: True but I travel a lot and sometimes need to connect to the machines from subnets that I don't know about in advance. You could secure another system somewhere on the internet (could be a $20/month virtual host), leave no pointers to your production systems on that system, and allow remote logins on your production systems from that other host. It's called a back door. You could also take a look at something like fwknop. That in combination with some type of back door for the situation where you don't have your keys available should cover any situation where you need to get to your system. But access using the key authentication should be preferred and only use the back door for emergencies. If I used openvpn to connect, and then connected via ssh over openvpn, this seems like essentially security through obscurity :) by just replacing the public ssh daemon with a different public daemon (with a different connection protocol) which an attacker could try to brute-force the same way they could try to brute-force sshd. Pretty much all security is based on something that you know/have that the attacker doesn't know/have. This is true for computer access, the locks on your front door and the safe at the bank. What your getting from the people on this list is their experience, comments based on what they did that worked and what they did that didn't. Check the past 10 years of cert advisories and count the number of security advisories for sshd and then count the number for openvpn. However it still seems that this would only matter if the attacker got in by brute-forcing the login. If they obtained the ability to run privileged commands any other way, then (1) they could continue to run privileged commands that way anyway, or (2) as their first action they could just remove all the IP address restrictions on ssh connections at which point they could connect normally via ssh from anywhere. The more security mechanisms you have in place, the greater is the probability that even if they made a partial compromise of your system, they might fail when they try to get through to the next level and if you have warning systems, such as daily reports or even alerts sent to your cell phone, you might be able to stop them first. So if this only matters when the attacker is trying to brute-force the login, and I still think that a 12-character random password is un-bruteforceable which makes the IP restrictions moot. Experience has shown that passwords can be cracked much more easily then private/public keys. Your the one telling us that your system has been compromised. Others sharing this fact may not have their systems compromised, or if they did, they learned from it. If I'm wrong, then why? What do you think -- if my password is already a 12-character random string, do think it adds additional security to restrict ssh logins to only subnets that I'm logging in from? If so, then what's a specific scenario where the attacker would be able to break in (or would have a larger chance of breaking in) if I'm not restricting ssh logins by IP, but would not be able to break in if I were restricting ssh logins? That's a straight probability calculation. How many billion systems are on the Internet? If I allow logins from even 100,000 systems versus several billion, I've substantially reduced the probability of a sucessful brute force attack. I have had problems with password guessing attacks on my pop and ftp servers (my ssh port is totally closed). Since I'm providing services to users, I can't just close those ports. I've been running fail2ban now for some time and it has helped, but I wanted to further reduce having even a handful of guesses. I discovered that the majority of attacks are coming from Asia, Russia, eastern Europe, South America and the middle east. Well I don't have any ftp users in those areas, so I blocked access to these countries and in fact now only allow access from regions where I have users. Things have been pretty darn quiet since I did that. By allowing access from only a handful of systems that you might be familiar with, you probably won't have bot attacks. Nataraj ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Hello Craig, On Mon, 2012-01-02 at 01:04 -0700, Craig White wrote: Very often, a single user with a weak password has his account cracked and then a hacker can get a copy of /etc/shadow and brute force the root password. This is incorrect. The whole reasoning behind /etc/shadow is to hide the actual hashes from normal system users. /etc/shadow is chown root.root and chmod 0400. Without root access /etc/shadow is not accessible. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 11:08 AM, Leonard den Ottolander leon...@den.ottolander.nl wrote: Hello Craig, On Mon, 2012-01-02 at 01:04 -0700, Craig White wrote: Very often, a single user with a weak password has his account cracked and then a hacker can get a copy of /etc/shadow and brute force the root password. This is incorrect. The whole reasoning behind /etc/shadow is to hide the actual hashes from normal system users. /etc/shadow is chown root.root and chmod 0400. Without root access /etc/shadow is not accessible. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research So, explain this then: How does something like c99shell allow a local user (not root) to read the /etc/shadow file? -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 3 January 2012 02:30, Bennett Haselton benn...@peacefire.org wrote: In other words, when SELinux causes a problem, it can take hours or days to find out that SELinux is the cause -- and even then you're not done, because you have to figure out a workaround if you want to fix the problem while keeping SELinux turned on. Unfortunately, good security is hard. I didn't understand SELinux a few years back and turned it off but didn't realise that a php application on my webserver left me vulnerable. Sure enough, one day I was attacked but luckily I had set the permissions up very tightly and they were unable to cause any damage. These days, I wouldn't leave it to chance and would keep SELinux as an additional layer of security; yes it's annoying at times, yes it can be difficult to get right but investing a few hours now is better than taking your critical systems down for days in the future. There are lots of resources out there to help you understand it - ones I have used in the past include: http://www.amazon.co.uk/SELinux-Source-Security-Enhanced-Linux/dp/0596007167/ref=sr_1_2?ie=UTF8qid=1325582583sr=8-2 http://www.ibm.com/developerworks/linux/library/l-selinux/ http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/ SELinux isn't a panacea and should be combined with other security precautions, but it will help you when the attackers come knocking on your server if you take the time to configure it properly. Ben ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 01/03/12 1:14 AM, Rudi Ahlers wrote: How does something like c99shell allow a local user (not root) to read the /etc/shadow file? presumably it uses a suid utility? i'm not familiar with c99shell, but thats classically how you elevate privileges. -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/2/2012 11:01 PM, John R. Dennison wrote: On Mon, Jan 02, 2012 at 10:41:15PM -0800, Bennett Haselton wrote: Again, you don't have to take my word for it -- in the first 10 Google hits of pages with people posting about the problem I ran into, none of the people helping them, thought to suggest SELinux as the cause of the problem. (By contrast, when iptables causes a problem, people usually figure out that's what's going on.) There's a lot of FUD going around in this thread. If people would bother to spend some time _reading_ _documentation_ on the systems they are attempting to admin they might find that subsystems such as selinux aren't quite as complex as they make them out to be. Well for one thing, much of the documentation for Linux tools is missing, unclear, or sometimes just wrong. Here's a message I posted two years ago: http://forums.mysql.com/read.php?11,280886,280886#msg-280886 about how when you first install MySQL, it tells you -- shouting in all caps, no less -- to set a password by running a pair of commands, where the second command is always guaranteed to fail (for reasons explained in the post). I verified this on every dedicated server I had access to. But the message never got answered, and for all I know MySQL still shouts the wrong information at every new user who installs it. However, completely wrong documentation is actually rare; the problem with most documentation is that it's unclear or ambiguous, because it's written or judged with the mindset that users should know enough to resolve the ambiguities and the errors, and if the user doesn't know enough to figure out the errors, it's a failing on the user's part. Or the documentation is extremely long-winded and doesn't contain a short version that is good enough for 99% of users' purposes, because it's assumed that if users don't want to read the 50-page version, that's also a failing on the user's part. I think most unclear documentation could easily be made better. I'd be happy to volunteer for a project where someone writing documentation wanted to check to see if it made sense to people who didn't already know what the author was trying to say. But the authors have to want to do that. The main obstacle is the mindset that problems with documentation are presumed to be the user's fault. (To be fair, this isn't a problem specific to Linux documentation; many instructions out there are pretty bad, because it's notoriously difficult to judge the quality of instructions in a field in which you're an expert, since your brain automatically fixes errors and ambiguities if you know what the author was trying to say. Recipes written by cooking experts are pretty bad.) Oh, and like all other aspects of the internet, google is just as susceptible to indexing idiots as it is to indexing pertinent and accurate results. selinux is fully integrated into the system auditing facilities and even provides multiple tools to aid an administrator in problem isolation and remediation. These tools are, of course, fully documented. There is _ample_ documentation on the web, starting with the CentOS wiki site, that covers selinux in great detail. I would urge you and anyone else not familiar with the facilities that selinux offers, both from an enforcement standpoint and also from a management standpoint, to spend some quality time reading up on it. Blaming selinux itself for creating what you perceive as a problem because you won't make a rudimentary attempt at learning to properly manage it is ludicrous. Anyone that has an internet facing box that does not take advantage of each and every security technology at their disposal should be in a different line of work. And taking advantage of such technologies requires one to read associated documentation. And while this response seems to single you out I mean to point a finger at anyone out there that doesn't bother to take time to learn about systems / data that they are responsible for. John ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] phpmyadmin issue
Greetings, I have installed phpmyadmin on a Centos 6.2 box. When I try to access it through http://localhost/phpmyadmin it is giving me a 403 forbidden error any clues? TIA. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Hello Rudi, On Tue, 2012-01-03 at 11:14 +0200, Rudi Ahlers wrote: How does something like c99shell allow a local user (not root) to read the /etc/shadow file? I do not vouch for every app that is written to break good security practices. Try $ ls -l /etc/shadow If the tool you are using allows normal users access to /etc/shadow it is using some sort of root privileges, either it's a suid tool (ouch) or it needs entries in /etc/sudoers (visudo). In either case, I cannot think of a valid reason to allow normal users access to this file. http://tldp.org/HOWTO/Shadow-Password-HOWTO.html for more information on shadow passwords. Regards, Leonard. -- mount -t life -o ro /dev/dna /genetic/research ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Antwort: phpmyadmin issue
centos-boun...@centos.org schrieb am 03.01.2012 10:55:43: Rajagopal Swaminathan raju.rajs...@gmail.com Gesendet von: centos-boun...@centos.org 03.01.2012 10:55 Bitte antworten an CentOS mailing list centos@centos.org An CentOS mailing list centos@centos.org Kopie Thema [CentOS] phpmyadmin issue Greetings, I have installed phpmyadmin on a Centos 6.2 box. When I try to access it through http://localhost/phpmyadmin it is giving me a 403 forbidden error any clues? TIA. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Hi, have you modified /etc/httpd/conf.d/phpMyAdmin.conf ? # # Web application to manage MySQL # Directory /usr/share/phpMyAdmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Alias /phpmyadmin /usr/share/phpMyAdmin Alias /phpMyAdmin /usr/share/phpMyAdmin Alias /mysqladmin /usr/share/phpMyAdmin Gruß Andreas Reschke Unix/Linux-Administration andreas.resc...@behrgroup.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Antwort: phpmyadmin issue
Greetings On Tue, Jan 3, 2012 at 3:32 PM, Andreas Reschke andreas.resc...@behrgroup.com wrote: centos-boun...@centos.org schrieb am 03.01.2012 10:55:43: Rajagopal Swaminathan raju.rajs...@gmail.com Gesendet von: centos-boun...@centos.org 03.01.2012 10:55 Bitte antworten an CentOS mailing list centos@centos.org have you modified /etc/httpd/conf.d/phpMyAdmin.conf ? # # Web application to manage MySQL # Directory /usr/share/phpMyAdmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Alias /phpmyadmin /usr/share/phpMyAdmin Alias /phpMyAdmin /usr/share/phpMyAdmin Alias /mysqladmin /usr/share/phpMyAdmin my phpmyadmin.conf file reads: [root@centos phpmyadmin]# cat /etc/httpd/conf.d/phpmyadmin.conf # # Web application to manage MySQL # Directory /usr/share/phpmyadmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Alias /phpmyadmin /usr/share/phpmyadmin Alias /phpMyAdmin /usr/share/phpmyadmin Alias /mysqladmin /usr/share/phpmyadmin -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:50 AM, Nataraj wrote: On 01/02/2012 10:48 PM, Bennett Haselton wrote: True but I travel a lot and sometimes need to connect to the machines from subnets that I don't know about in advance. You could secure another system somewhere on the internet (could be a $20/month virtual host), leave no pointers to your production systems on that system, and allow remote logins on your production systems from that other host. It's called a back door. But assuming the attacker is targeting my production system, suppose they find a vulnerability and obtain the ability to run commands as root on the system. Then wouldn't their first action be to remove restrictions on where you can log in from? (Or, they could just continue to run root commands using whatever trick they'd discovered?) You could also take a look at something like fwknop. That in combination with some type of back door for the situation where you don't have your keys available should cover any situation where you need to get to your system. But access using the key authentication should be preferred and only use the back door for emergencies. If I used openvpn to connect, and then connected via ssh over openvpn, this seems like essentially security through obscurity :) by just replacing the public ssh daemon with a different public daemon (with a different connection protocol) which an attacker could try to brute-force the same way they could try to brute-force sshd. Pretty much all security is based on something that you know/have that the attacker doesn't know/have. This is true for computer access, the locks on your front door and the safe at the bank. Yes, but the argument for security over obscurity is that the secret should reside in something that cannot be obtained even in trillions of trillions of guesses (i.e. a strong password), not in something that could be obtained in a few dozen or a few thousand guesses (i.e. finding OpenVPN listening on a given port). The reason being is that if something is obtainable in a few thousand guesses, then it will create the illusion of being unguessable, but an attacker could still get it. What your getting from the people on this list is their experience, comments based on what they did that worked and what they did that didn't. Unfortunately it may not be possible to tell that a particular safeguard ever actually worked or made a difference. How could you ever know, for example, that an attacker was stopped because you used an ssh key instead of a 12-character truly random password? One way you can know is if you have two barriers one behind the other, and attackers get through the first barrier but not the second one, then you know the second barrier mattered. That's why the argument for SELinux sounds persuasive, because of identified instances where attackers circumvented the first barrier (finding a way to make Apache create executables in /tmp/) but were stopped by the second (SELinux prevented those executables from being run). Check the past 10 years of cert advisories and count the number of security advisories for sshd and then count the number for openvpn. OK, that's different from the obscurity factor (since the difference in exploit frequency, would still be a reason to use openvpn instead of sshd, even if the attacker knew that you were using it). However that also has to be weighed against the side effects of using a non-standard setup. I assume, for example, that most security audit tools would look at IP addresses that attempted to log in via ssh. That wouldn't work if your gateway is OpenVPN instead of sshd. (In my experience, everything you're doing differently from everyone else, makes it harder to get help when things go wrong.) However it still seems that this would only matter if the attacker got in by brute-forcing the login. If they obtained the ability to run privileged commands any other way, then (1) they could continue to run privileged commands that way anyway, or (2) as their first action they could just remove all the IP address restrictions on ssh connections at which point they could connect normally via ssh from anywhere. The more security mechanisms you have in place, the greater is the probability that even if they made a partial compromise of your system, they might fail when they try to get through to the next level and if you have warning systems, such as daily reports or even alerts sent to your cell phone, you might be able to stop them first. For partial compromises that makes sense. However for total compromises (i.e. if attacker is running root commands on your system), then presumably this would only work if your tripwire warning system was obscure enough that the attacker didn't know to look for it. Otherwise their first action would be to disable the tripwire before it warned you. So if this only matters when the attacker is trying to brute-force the
Re: [CentOS] phpmyadmin issue
From: Rajagopal Swaminathan raju.rajs...@gmail.com I have installed phpmyadmin on a Centos 6.2 box. When I try to access it through http://localhost/phpmyadmin it is giving me a 403 forbidden error any clues? It says you don't have access rights... How did you setup the access rights? JD ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] phpmyadmin issue
On 01/03/12 1:55 AM, Rajagopal Swaminathan wrote:
When I try to access it throughhttp://localhost/phpmyadmin it is
giving me a 403 forbidden error
I'd look in /var/log/httpd/{access,error}_log
maybe `tail -f /var/log/httpd/*_log` in a shell window, then hit the
webpage and see what new errors are barfed out a few seconds later...
--
john r pierceN 37, W 122
santa cruz ca mid-left coast
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] sa-update error with perl
From: email builder emailbuilde...@yahoo.com The only hints I can find seem to suggest to remove perl-IO-Socket-INET6, but trying to do so using yum (I don't want to start using another method of package management) tells me that spamassassin is a dependency and will also be removed - obviously undesirable. If you really want to remove it, use rpm instead. rpm -e --nodeps perl-IO-Socket-INET6 But it will annoy you at every update... On my Zimbra server (CentOS 5.7), sa works fine. I have spamassassin-3.3.1-2.el5 and perl-IO-Socket-INET6-2.51-2.fc6 installed. Did you disable IPV6? JD ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Antwort: phpmyadmin issue
On Jan 3, 2012, at 5:12, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Greetings On Tue, Jan 3, 2012 at 3:32 PM, Andreas Reschke andreas.resc...@behrgroup.com wrote: centos-boun...@centos.org schrieb am 03.01.2012 10:55:43: Rajagopal Swaminathan raju.rajs...@gmail.com Gesendet von: centos-boun...@centos.org 03.01.2012 10:55 Bitte antworten an CentOS mailing list centos@centos.org have you modified /etc/httpd/conf.d/phpMyAdmin.conf ? # # Web application to manage MySQL # Directory /usr/share/phpMyAdmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Alias /phpmyadmin /usr/share/phpMyAdmin Alias /phpMyAdmin /usr/share/phpMyAdmin Alias /mysqladmin /usr/share/phpMyAdmin my phpmyadmin.conf file reads: [root@centos phpmyadmin]# cat /etc/httpd/conf.d/phpmyadmin.conf # # Web application to manage MySQL # Directory /usr/share/phpmyadmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Unless you're going to access this through a ssh tunnel to this machine fix this stanza of the config. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Request for suggestion of a SCM package for Centos 6
On 01/03/2012 03:46 AM, Rajagopal Swaminathan wrote: 1. Can somebody suggest a way to select all packages while installing from DVD? you cant install everything from the DVD, since packages overlap and conflict with each other. a %post of yum --skip-broken install \*; might be your best bet. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219| Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton benn...@peacefire.org wrote: But assuming the attacker is targeting my production system, suppose they find a vulnerability and obtain the ability to run commands as root on the system. Then wouldn't their first action be to remove restrictions on where you can log in from? (Or, they could just continue to run root commands using whatever trick they'd discovered?) No, they'd probably replace your ssh binary with one that makes a hidden outbound connection to their own control center. And replace netstat with one that doesn't show that connection. If anyone has ever gotten root access, all other bets are off - those tools are a dime a dozen. Yes, but the argument for security over obscurity is that the secret should reside in something that cannot be obtained even in trillions of trillions of guesses (i.e. a strong password), not in something that could be obtained in a few dozen or a few thousand guesses (i.e. finding OpenVPN listening on a given port). The reason being is that if something is obtainable in a few thousand guesses, then it will create the illusion of being unguessable, but an attacker could still get it. Openvpn runs over UDP. With the tls-auth option it won't respond to an unsigned packet. So without the key you can't tell the difference between a listening openvpn or a firewall that drops packets silently. That is, you can't 'find' it. Unfortunately it may not be possible to tell that a particular safeguard ever actually worked or made a difference. How could you ever know, for example, that an attacker was stopped because you used an ssh key instead of a 12-character truly random password? If you look at your logs under normal conditions, you'll know if someone has tried and failed a password login. After someone has gotten in, it may be too late because they can destroy the evidence. Logging remotely to a more protected machine can help a bit. OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] New Tutorial - RHCS + DRBD + KVM; 2-Node HA on EL6
Hi all, I'm happy to announce a new tutorial! https://alteeve.com/w/2-Node_Red_Hat_KVM_Cluster_Tutorial This tutorial walks a user through the entire process of building a 2-Node cluster for making KVM virtual machines highly available. It uses Red Hat Cluster services v3 and DRBD 8.3.12. It is written such that you can use entirely free or fully Red Hat supported environments. Highlights; * Full network and power redundancy; no single-points of failure. * All off-the-shelf hardware; Storage via DRBD. * Starts with base OS install, no clustering experience required. * All software components explained. * Includes all testing steps covered. * Configuration is used in production environments! This tutorial is totally free (no ads, no registration) and released under the Creative Common 3.0 Share-Alike Non-Commercial license. Feedback is always appreciated! -- Digimer E-Mail: digi...@alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org omg my singularity battery is dead again. stupid hawking radiation. - epitron ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Passwords apparently stopped working.
I encountered a couple of strange events with respect to password authentication this morning. Two of our staff were unable to login onto several systems using their usual passwords. Both users had last logged in on these hosts using their accounts and passwords on Friday past. The two accounts could not log on to any of the servers for which they had access and the message log on each showed that access was denied for a failed password. The systems involved were running either CentOS-4.9 or CentOS-5.7. So, the effect was uniform across multiple hardware and software platforms. I also checked these accounts against our warm backup machine and encountered the same problems for both. I verified that the passwords being used were correct for the accounts. I also verified that neither of passwords had been reset in some months and there were no expiry dates set for the accounts. I would accept the coincidence of both forgetting their passwords except for the fact that each had kept a record of their password in their wallets and I was able to confirm those values against our records as well. Resetting both the passwords to their current values using the passwd utility on each system corrected the problem insofar as the users were concerned. However, I am somewhat perplexed as to the reason for their passwords to stop working in the first place. Is anyone here aware of any reason why this might happen? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tuesday 03 January 2012 07:57:47 Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton benn...@peacefire.org wrote: But assuming the attacker is targeting my production system, suppose they find a vulnerability and obtain the ability to run commands as root on the system. Then wouldn't their first action be to remove restrictions on where you can log in from? (Or, they could just continue to run root commands using whatever trick they'd discovered?) No, they'd probably replace your ssh binary with one that makes a hidden outbound connection to their own control center. And replace netstat with one that doesn't show that connection. If anyone has ever gotten root access, all other bets are off - those tools are a dime a dozen. Those kind of things can be detected with SHA512 (for example) Yes, but the argument for security over obscurity is that the secret should reside in something that cannot be obtained even in trillions of trillions of guesses (i.e. a strong password), not in something that could be obtained in a few dozen or a few thousand guesses (i.e. finding OpenVPN listening on a given port). The reason being is that if something is obtainable in a few thousand guesses, then it will create the illusion of being unguessable, but an attacker could still get it. Openvpn runs over UDP. With the tls-auth option it won't respond to an unsigned packet. So without the key you can't tell the difference between a listening openvpn or a firewall that drops packets silently. That is, you can't 'find' it. We are not going to argue drop vs reject, are we? :P Unfortunately it may not be possible to tell that a particular safeguard ever actually worked or made a difference. How could you ever know, for example, that an attacker was stopped because you used an ssh key instead of a 12-character truly random password? If you look at your logs under normal conditions, you'll know if someone has tried and failed a password login. After someone has gotten in, it may be too late because they can destroy the evidence. Logging remotely to a more protected machine can help a bit. Remote syslog? that way they'll have to hack into two different machines... Regards ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haselton benn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? mark 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 9:31 AM, Marc Deop damnsh...@gmail.com wrote: Openvpn runs over UDP. With the tls-auth option it won't respond to an unsigned packet. So without the key you can't tell the difference between a listening openvpn or a firewall that drops packets silently. That is, you can't 'find' it. We are not going to argue drop vs reject, are we? :P It follows the usual pattern: dropping is more secure in that you can't tell if anything is there at all where rejecting is more convenient because attempts to open a connection don't have to wait for timeouts. Pick the one that meets your specific need. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords apparently stopped working.
James B. Byrne wrote: I encountered a couple of strange events with respect to password authentication this morning. Two of our staff were unable to login onto several systems using their usual passwords. Both users had last logged in on these hosts using their accounts and passwords on Friday past. snip Resetting both the passwords to their current values using the passwd utility on each system corrected the problem insofar as the users were concerned. However, I am somewhat perplexed as to the reason for their passwords to stop working in the first place. Is anyone here aware of any reason why this might happen? Is it possible that they'd logged into something else first, and had multiple credentials, and the systems were trying to get those first? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 12:48 AM, Bennett Haselton benn...@peacefire.org wrote: You can also set up openvpn on the server and control ports like ssh to only be open to you if you are using an openvpn client to connect to the machine. True but I travel a lot and sometimes need to connect to the machines from subnets that I don't know about in advance. Have you ever typed your password on a machine you didn't control? Or even one that was not completely secure (i.e. could have had a hardware keylogger attached, or a software key logger installed by a trojan, virus, or wifi hack)? If so, you might be missing the most likely possibility for someone having your password: simply grabbing it as you type before ssh gets a chance to encrypt it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 3:14 AM, Rudi Ahlers r...@softdux.com wrote: Very often, a single user with a weak password has his account cracked and then a hacker can get a copy of /etc/shadow and brute force the root password. This is incorrect. The whole reasoning behind /etc/shadow is to hide the actual hashes from normal system users. /etc/shadow is chown root.root and chmod 0400. Without root access /etc/shadow is not accessible. So, explain this then: How does something like c99shell allow a local user (not root) to read the /etc/shadow file? The description from here: http://jigneshdhameliya.blogspot.com/2010/03/backdoorphpc99shellw.html and other places says 16. exploit a range of Linux kernel and bash command interpreter vulnerabilies In other words, all those things that get listed as 'local' vulnerabilities become remote vulnerabilities as soon as any app or service allows running an arbitrary command. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords apparently stopped working.
On Tue, Jan 03, 2012 at 10:30:38AM -0500, James B. Byrne wrote: I encountered a couple of strange events with respect to password authentication this morning. Two of our staff were unable to login onto several systems using their usual passwords. Both users had last logged in on these hosts using their accounts and passwords on Friday past. The two accounts could not log on to any of the servers for which they had access and the message log on each showed that access was denied for a failed password. The systems involved were running either CentOS-4.9 or CentOS-5.7. So, the effect was uniform across multiple hardware and software platforms. I also checked these accounts against our warm backup machine and encountered the same problems for both. I verified that the passwords being used were correct for the accounts. I also verified that neither of passwords had been reset in some months and there were no expiry dates set for the accounts. I would accept the coincidence of both forgetting their passwords except for the fact that each had kept a record of their password in their wallets and I was able to confirm those values against our records as well. Resetting both the passwords to their current values using the passwd utility on each system corrected the problem insofar as the users were concerned. However, I am somewhat perplexed as to the reason for their passwords to stop working in the first place. Is anyone here aware of any reason why this might happen? Any chance it is something as basic as the caps lock key getting hit unbeknownst to the users? It has happened to me a number of times - especially on my current keyboard which does not have an indicator light. jerry -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] turning off udev for eth0
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration. Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] turning off udev for eth0
James B. Byrne wrote: I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. snip On the physical box, how many NICs are there? Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Have you edited /etc/udev/rules.d in the prototype setup? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. Unfortunately, no, you need it: on boot, /dev, and everything in it, is created on the fly by udev. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS-announce Digest, Vol 83, Issue 1
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of CentOS-announce digest...
Today's Topics:
1. CEBA-2012:0001 CentOS 6 vsftpd Update (Johnny Hughes)
--
Message: 1
Date: Tue, 3 Jan 2012 01:53:55 +
From: Johnny Hughes joh...@centos.org
Subject: [CentOS-announce] CEBA-2012:0001 CentOS 6 vsftpd Update
To: centos-annou...@centos.org
Message-ID: 20120103015355.ga18...@chakra.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2012:0001
Upstream details at : https://rhn.redhat.com/errata/RHBA-2012-0001.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
de412bb59ce6fcb08bcbb745aaa73429a18aadba12e5d71e85fa672701d6f677
vsftpd-2.2.2-6.el6_2.1.i686.rpm
x86_64:
38f46bd3a896ef31ce879764cb9cd27c878e5070e1f6d4a016c9b9e54853a143
vsftpd-2.2.2-6.el6_2.1.x86_64.rpm
Source:
62c140cbd2d670a8010f490dfc3a7c69d09030d913ddcc01328f637bfd19db4e
vsftpd-2.2.2-6.el6_2.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
___
CentOS-announce mailing list
centos-annou...@centos.org
http://lists.centos.org/mailman/listinfo/centos-announce
End of CentOS-announce Digest, Vol 83, Issue 1
**
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] turning off udev for eth0
I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. we experience this problem with VMware too. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. i'm no expert, but i thought the problem was that the cloning mechanism changes the mac address of the eth0 device (to make it unique), but it does not update the udev rules accordingly. udev notices a new device and treats it as eth1. so the correct fix would be either 1) a virtual machine cloning mechanism that updates udev rules to use the new mac address or 2) udev rules that somehow don't need to use the mac address but i really know next to nothing about udev other than what i've discovered by poking around the 70-persistent-net.rules same as you Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration. not exactly... the clone does have a new mac address still, so it isn't identical to the prototype. Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. ahh, the life of a sysadmin. since i do not know enough about udev to answer the first 2 questions, and i do not have time (or interest really) to learn this detail, i just absorb the busy work. -- Jonathan.Nilsson at uci dot edu Social Sciences Computing Services SSPB 1265 | 949.824.1536 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? mark 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That is why we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] turning off udev for eth0
On Tue, January 3, 2012 11:58, m.r...@5-cent.us wrote: On the physical box, how many NICs are there? There are two physical NICs. Eth0 is the WAN, Eth1 is the LAN. The vm guests are supposed to only be accessible via the WAN. The prototype is configured with only one NIC connected to the bridge device (vnet0 - bridge Br0). Do physical attributes of the host override the configured virtual attributes of a guest? Have you edited /etc/udev/rules.d in the prototype setup? I had previously removed the contents of the 70-persistent-net.rules file on the prototype. However, I did not pay enough attention to the fact that this file is rewritten upon startup. So I was getting the eth0 i/f added back into it every time I started the prototype to perform updates. If I remove the contents of this file just before shutting down the prototype then the interface problem with cloning disappears. Thanks for the hint. Regards, -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Ljubomir, Ljubomir Ljubojevic wrote: On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No O additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That is why So he's not only not wanting to accept that he blew it, but wants validation for that wrongheadedness. we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. As long as no one's giving him support in his ideas, he's now got someone outside himself (and the intruder) to be against. Just like the US right wing I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. Thanks for the offlist email. Happy new year to you. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] turning off udev for eth0
James B. Byrne wrote: On Tue, January 3, 2012 11:58, m.r...@5-cent.us wrote: On the physical box, how many NICs are there? There are two physical NICs. Eth0 is the WAN, Eth1 is the LAN. The vm guests are supposed to only be accessible via the WAN. The prototype is configured with only one NIC connected to the bridge device (vnet0 - bridge Br0). Do physical attributes of the host override the configured virtual attributes of a guest? Dunno 'bout guests - I haven't worked with them, much, except VMware. man udev: DESCRIPTION udev provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces. Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added or removed from the system. If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling. So it's good, in some ways, but... Have you edited /etc/udev/rules.d in the prototype setup? I had previously removed the contents of the 70-persistent-net.rules file on the prototype. However, I did not pay enough attention to the fact that this file is rewritten upon startup. So I was getting the eth0 i/f added back into it every time I started the prototype to perform updates. If I remove the contents of this file just before shutting down the prototype then the interface problem with cloning disappears. Thanks for the hint. Sure. Those persistant-net-rules can really getcha. I've done a lot of upgrades (to 6.x) via rsync from servers I'd built directly, and that caught me a number of times, till I Got It. mark and got rid of eth0,1,2,3,4,5 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Whoops, sorry, thought this was offlist. mark, not reading closely enough. m.r...@5-cent.us wrote: Ljubomir, Ljubomir Ljubojevic wrote: On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No O additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That is why So he's not only not wanting to accept that he blew it, but wants validation for that wrongheadedness. we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. As long as no one's giving him support in his ideas, he's now got someone outside himself (and the intruder) to be against. Just like the US right wing I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. Thanks for the offlist email. Happy new year to you. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 11:36 AM, Ljubomir Ljubojevic wrote: On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? mark 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That there are 10^21 possible random 12-character alphanumeric passwords -- making it secure against brute-forcing -- is a fact, not an opinion. To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Almost every time I said this, I added, If you think this is incorrect, why do you think it's incorrect?, because I did genuinely want to know. When people didn't reply, I thought maybe they hadn't realized before that I was using actually long, actually random passwords, and maybe they no longer thought that was insecure after all. Again: Do you think I'm wrong that if you use a 12-character mixed-case alphanumeric password, then switching to sshkeys or using fail2ban will not make the system any more secure? If you think I'm wrong, why? What is the exact scenario that you think those would prevent? That is why we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. The thread grew so long partly because few people were offering suggestions on *preventive* measures (mostly on what to do differently next time to diagnose after the fact -- which was fine and useful, but I kept trying to steer the discussion back to preventive measures), and the two preventive measures that did come up the most, were using ssh keys and using fail2ban to stop people brute-forcing the login, and I kept explaining why I did not think that would make me any safer the next time around. Note that after over 100 messages had been posted on the subject, someone did mention SELinux and the specific scenario (which has come up in the real world) in which SELinux can stop a break-in (exploit is found where attacker takes control of Apache, Apache writes to /tmp dir and tries to execute a program there). If I had accepted the advice offered at the beginning to use keys instead of passwords, the discussion might have never gotten past that. It was because I stood my ground that brute-forcing a 12-character random password was not logically possible, that the discussion eventually turned to something which *might* at least reduce the chance of a future break-in. I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Jan 3, 2012 12:36 PM, Ljubomir Ljubojevic off...@plnet.rs wrote: On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? mark 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That is why we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I'm subscribed to this list just because of threads like this. I want to thank you all for exposing me to knowledge and discussion that reveals far more than manpages or readmes - it helps a lot to know where to start reading, and about what. I am not a statistician, but I feel an observation should be made on the idea of an 'unguessable password.' A 12 character string may have 12^42 possible permutations, but you are assuming that the correct guess will be the last possible guess. Simplistic probability puts the odds of success at 50% - either the attacker gets it right, or they don't. An intelligent brute forcing tool could be making some assumptions about the minimum length and complexity of your password, and ruling out the dictionary words and strings based on them happens quickly. The next guess has the same rough odds of being correct as the 100563674th guess. Of course, no amount of guessing will succeed on a system that doesn't accept passwords. System security, in terms of probability, seems to be an 'every little bit helps' sort of endeavour. Thanks again for the insights, Pete ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Bennett Haselton wrote: mark wrote: snip 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. snip That there are 10^21 possible random 12-character alphanumeric passwords -- making it secure against brute-forcing -- is a fact, not an opinion. To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Almost every time I said Ok, I'll answer, here and now: YOU IGNORED MY QUESTION: HOW WILL YOU RANDOMLY GENERATE THE PASSWORDS? All algorithmic ones are pseudo-random. If someone has any idea what the o/s is, they can guess which pseudo-random generator you're using, and can try different salts. Someone here posted a link to the Rainbow tables, and precomputed partial lists. snip Again: Do you think I'm wrong that if you use a 12-character mixed-case alphanumeric password, then switching to sshkeys or using fail2ban will not make the system any more secure? If you think I'm wrong, why? What is the exact scenario that you think those would prevent? Without fail2ban, or something like it, they'll hit your system thousands of times an hour, at least. Sooner or later, they'll get lucky. But I suppose you'll ignore this, as well. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:31 PM, Pete Travis wrote: On Jan 3, 2012 12:36 PM, Ljubomir Ljubojevicoff...@plnet.rs wrote: On 01/03/2012 04:47 PM, m.r...@5-cent.us wrote: Having been on vacation, I'm coming in very late in this Les Mikesell wrote: On Tue, Jan 3, 2012 at 4:28 AM, Bennett Haseltonbenn...@peacefire.org wrote: snip OK but those are *users* who have their own passwords that they have chosen, presumably. User-chosen passwords cannot be assumed to be secure against a brute-force attack. What I'm saying is that if you're the only user, by my reasoning you don't need fail2ban if you just use a 12-character truly random password. But you aren't exactly an authority when you are still guessing about the cause of your problem, are you? (And haven't mentioned what your logs said about failed attempts leading up to the break in...). Further, that's a ridiculous assumption. Without fail2ban, or something like it, they'll keep trying. You, instead, Bennett, are presumably generating that truly random password[1] and assigning it to all your users[2], and not allowing them to change their passwords, and you will be changing it occasionally and informing them of the change.[3] Right? mark 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. 2. Which, being truly random, they will write down somewhere, or store it on a key, labelling the file mypassword or some such. 3. How will you notify them of their new password - in plain text? Bennet was/is the only one using those systems, and only as root. No additional users existed prior to breach. And he is very persisting in placing his own opinion/belief above those he asks for help. That is why we have such a long long long thread. It came to the point where I am starting to believe him being a troll. Not sure yet, but it is getting there. I am writing this for your sake, not his. I decided to just watch from no on. This thread WAS very informative, I did lear A LOT, but enough is enough, and I spent far to much time reading this thread. -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe Google is the Mother, Google is the Father, and traceroute is your trusty Spiderman... StarOS, Mikrotik and CentOS/RHEL/Linux consultant ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I'm subscribed to this list just because of threads like this. I want to thank you all for exposing me to knowledge and discussion that reveals far more than manpages or readmes - it helps a lot to know where to start reading, and about what. I am not a statistician, but I feel an observation should be made on the idea of an 'unguessable password.' A 12 character string may have 12^42 possible permutations, I'm not sure where you got the 12^42 figure from. My assumption was that each character has about 64 = 2^6 possible values, so there are 2^72 possible passwords, which is on the order of 10^24. but you are assuming that the correct guess will be the last possible guess. Actually I was using the fact that the average time to break the password would be the time required to check half of the possible passwords, not that they won't find it until the last possible one. That's still on the order of 10^24. Simplistic probability puts the odds of success at 50% - either the attacker gets it right, or they don't. I can't make sense of this statement at all. Just because there are two possible outcomes doesn't mean that each possibility is equally likely -- you might as well that either the sun comes up tomorrow, or it doesn't, so the odds of success are 50% :) The only time the 50% figure comes up is that the average time to guess a password is the time taken to check half of all possible passwords, and hence is 50% of the worst-case time to guess a password (which would be the time taken to check all of them). An intelligent brute forcing tool could be making some assumptions about the minimum length and complexity of your password, and ruling out the dictionary words and strings based on them happens quickly. The next guess has the same rough odds of being correct as the 100563674th guess. Actually, each time you make a guess and it's wrong, the probability of success goes up slightly for your next guess. Imagine having 10 cups with a ball under one of them. The probability of turning over the right cup on the first try is 1/10. If you're wrong, though, then the probability of getting it right on the next cup goes up to 1/9, and so on. But it's all a moot point if there are 10^24 possible passwords and the odds of finding the right one in any conceivable length of time are essentially zero. Of course, no amount of guessing will succeed on a system that doesn't accept passwords. System security, in terms of
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 12:32 PM, m.r...@5-cent.us wrote: Bennett Haselton wrote: mark wrote: snip 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. snip That there are 10^21 possible random 12-character alphanumeric passwords -- making it secure against brute-forcing -- is a fact, not an opinion. To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Almost every time I said Ok, I'll answer, here and now: YOU IGNORED MY QUESTION: HOW WILL YOU RANDOMLY GENERATE THE PASSWORDS? All algorithmic ones are pseudo-random. If someone has any idea what the o/s is, they can guess which pseudo-random generator you're using, and can try different salts. I generally change them from the values assigned by the hosting company, and just bang my fingers around on the keyboard, with the shift key randomly on and off for good measure :) This also removes the possibility that an incompetent hosting company will store their own copy of the password somewhere that it can be compromised. Even when that possibility is very unlikely, it's still astronomically more likely than the attacker guessing the password by brute force. But even if someone did not do that, don't most Linux distros a good crypto-random number generator for generating new passwords, when they're picked by the machine and not the user? You can use salts that depend on the low bits of high-precision performance counters, and other values that are impossible for an attacker to predict. If any Linux implementation is using anything less than a cryptographically strong generator for creating passwords, like I said it's not my problem, but I would take that up with the developers. Someone here posted a link to the Rainbow tables, and precomputed partial lists. snip Again: Do you think I'm wrong that if you use a 12-character mixed-case alphanumeric password, then switching to sshkeys or using fail2ban will not make the system any more secure? If you think I'm wrong, why? What is the exact scenario that you think those would prevent? Without fail2ban, or something like it, they'll hit your system thousands of times an hour, at least. Sooner or later, they'll get lucky. OK do you *literally mean that* -- that with 10^21 possible passwords that an attacker has to search, I have to worry about the attacker getting lucky if they're trying thousands of times per hour? But I suppose you'll ignore this, as well. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] probleme with my wifi card on centos 6
Le 2012-01-03 03:35, fakessh a écrit : Le 2012-01-03 02:44, Ljubomir Ljubojevic a écrit : On 01/03/2012 02:33 AM, fakessh wrote: Le 2012-01-03 02:21, Ljubomir Ljubojevic a écrit : On 01/03/2012 02:15 AM, fakessh @ wrote: Le mardi 03 janvier 2012 à 02:02 +0100, fakessh a écrit : Le 2012-01-03 00:15, Ljubomir Ljubojevic a écrit : On 01/02/2012 09:58 PM, fakessh wrote: I am writing to report a problem I encounter with my wireless card realtek 8150 the installer does not detect the device so the /etc/sysconfig/network-script/ifcfg-wlan0 is absent Realtek 8150 is USB LAN NIC, not the wireless one. Drivers for it are already inside the Kernel: http://www.realtek.com/products/productsView.aspx?Langid=1PNid=14PFid=8Level=5Conn=4ProdID=21 Please post output of the 'lspci -v command, mainly those device without anything in Kernel driver in use: (or do not have that line at all). this my output root@localhost ~]# lspci -v | egrep Ethernet 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) So it is not RTL-8150, but RTL-8185 I connect with the ethernet port but I can not turn on the wireless card all testimonials are welcome the card appears sold as a wireless trendnet TEW 423PI The chip is all we should need. Next we is DeviceID so we can match it. run: lspci -n | grep '01:06.0' output of this command root@localhost ~]# lspci -n | grep '01:06.0' 01:06.0 0200: 10ec:8185 (rev 20) I feared so. ElRepo does not have it, nor any other repository. But there is Realtek's source you can compile: http://www.realtek.com/downloads/downloadsView.aspx?Langid=1PNid=1PFid=1Level=6Conn=5DownTypeID=3GetDown=falseDownloads=true#RTL8185L Also look at http://rtl8180-sa2400.sourceforge.net/ You can also ask ElRepo developers that they build an kmod-package from that source. I was not able to set up the wireless interface despite the driver. I'll open an issue on the bugtracker of elrepo So I think do a post on the bugtracker of elrepo to ask the creation of a new kmod-* So I tried to compile the driver provided in [1] module appears to load properly Still I have failed to create the wireless interface despite my attempts with the file ifcfg-wlan0 tape provided I to try to load ifup the interface without success I do not know how I do [1] http://www.realtek.com/products/productsView.aspx?Langid=1PNid=14PFid=8Level=5Conn=4ProdID=21 -- http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] probleme with my wifi card on centos 6
Le 2012-01-03 22:14, fakessh a écrit : Le 2012-01-03 03:35, fakessh a écrit : Le 2012-01-03 02:44, Ljubomir Ljubojevic a écrit : On 01/03/2012 02:33 AM, fakessh wrote: Le 2012-01-03 02:21, Ljubomir Ljubojevic a écrit : On 01/03/2012 02:15 AM, fakessh @ wrote: Le mardi 03 janvier 2012 à 02:02 +0100, fakessh a écrit : Le 2012-01-03 00:15, Ljubomir Ljubojevic a écrit : On 01/02/2012 09:58 PM, fakessh wrote: I am writing to report a problem I encounter with my wireless card realtek 8150 the installer does not detect the device so the /etc/sysconfig/network-script/ifcfg-wlan0 is absent Realtek 8150 is USB LAN NIC, not the wireless one. Drivers for it are already inside the Kernel: http://www.realtek.com/products/productsView.aspx?Langid=1PNid=14PFid=8Level=5Conn=4ProdID=21 Please post output of the 'lspci -v command, mainly those device without anything in Kernel driver in use: (or do not have that line at all). this my output root@localhost ~]# lspci -v | egrep Ethernet 00:07.0 Bridge: nVidia Corporation MCP61 Ethernet (rev a2) 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) So it is not RTL-8150, but RTL-8185 I connect with the ethernet port but I can not turn on the wireless card all testimonials are welcome the card appears sold as a wireless trendnet TEW 423PI The chip is all we should need. Next we is DeviceID so we can match it. run: lspci -n | grep '01:06.0' output of this command root@localhost ~]# lspci -n | grep '01:06.0' 01:06.0 0200: 10ec:8185 (rev 20) I feared so. ElRepo does not have it, nor any other repository. But there is Realtek's source you can compile: http://www.realtek.com/downloads/downloadsView.aspx?Langid=1PNid=1PFid=1Level=6Conn=5DownTypeID=3GetDown=falseDownloads=true#RTL8185L Also look at http://rtl8180-sa2400.sourceforge.net/ You can also ask ElRepo developers that they build an kmod-package from that source. I was not able to set up the wireless interface despite the driver. I'll open an issue on the bugtracker of elrepo So I think do a post on the bugtracker of elrepo to ask the creation of a new kmod-* So I tried to compile the driver provided in [1] module appears to load properly Still I have failed to create the wireless interface despite my attempts with the file ifcfg-wlan0 tape provided I to try to load ifup the interface without success I do not know how I do [1] http://www.realtek.com/products/productsView.aspx?Langid=1PNid=14PFid=8Level=5Conn=4ProdID=21 link driver error [1] http://www.realtek.com/downloads/downloadsView.aspx?Langid=1PNid=1PFid=1Level=6Conn=5DownTypeID=3GetDown=falseDownloads=true#RTL8185L -- http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Here's the qualifying statement I made, in an attempt to preempt pedantic squabbles over my choice of arbitrary figures and oversimplified math: I am not a statistician, but Here is a statement intended to startle you into re-examining your position: Simplistic probability puts the odds of success at 50% - either the attacker gets it right, or they don't. Here's the intended take home message: The next guess has the same rough odds of being correct as the 100563674th guess. Yes, you have to worry about a brute force attack succeeding, every hour of every day that you give it a window to knock on. Here is you nitpicking over figures; acknowledging the opportunity for an improvement of several orders of magnitude and disregarding it, stuck in your misconceptions; and wholly missing the point. Actually, each time you make a guess and it's wrong, the probability of success goes up slightly for your next guess. Imagine having 10 cups with a ball under one of them. The probability of turning over the right cup on the first try is 1/10. If you're wrong, though, then the probability of getting it right on the next cup goes up to 1/9, and so on. But it's all a moot point if there are 10^24 possible passwords and the odds of finding the right one in any conceivable length of time are essentially zero. Of course, no amount of guessing will succeed on a system that doesn't accept passwords. System security, in terms of probability, seems to be an 'every little bit helps' sort of endeavour. Well it depends on how literally you mean every little bit :) If the chance of a break-in occurring in the next year from a given attack is 1 in 10^10, you can reduce it to 1 in 10^20, but it's already less likely than your data center being hit by a meteorite. The real problem is that it takes away from time that can be used for things that have a greater likelihood of reducing the chance of a break-in. If I had taken the advice about ssh keys at the beginning of the thread, I never would have gotten to the suggestion about SELinux. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I'm moving on from this - much better men than I have tried and failed here. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Sunday, January 01, 2012 06:27:32 PM Bennett Haselton wrote: (I have already practically worn out my keyboard explaining the math behind why I think a 12-character alphanumeric password is secure enough :) ) Also see: https://lwn.net/Articles/369703/ ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
Bennett Haselton wrote: On 1/3/2012 12:32 PM, m.r...@5-cent.us wrote: Bennett Haselton wrote: mark wrote: snip 1. How will you generate truly random? Clicks on a Geiger counter? There is no such thing as a random number generator. snip To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Almost every time I said Ok, I'll answer, here and now: YOU IGNORED MY QUESTION: HOW WILL YOU RANDOMLY GENERATE THE PASSWORDS? All algorithmic ones are pseudo-random. If someone has any idea what the o/s is, they can guess which pseudo-random generator you're using, and can try different salts. I generally change them from the values assigned by the hosting company, and just bang my fingers around on the keyboard, with the shift key randomly on and off for good measure :) This also removes the Real random, there. Do you also use a Dvorak keyboard, or a std. querty? You want to be there aren't algorithms out there for guessing that? Certainly, until this minute, I hadn't thought of it, but I'll be there is. possibility that an incompetent hosting company will store their own Hosting co? You're hosted somewhere? And an admin there can't get into your snapshot and add a back door? copy of the password somewhere that it can be compromised. Even when that possibility is very unlikely, it's still astronomically more likely than the attacker guessing the password by brute force. Question 1: why is it that brute force attacks go on, day and night, everywhere? I see plenty of them here, when fail2ban tells me it's banning an IP. But even if someone did not do that, don't most Linux distros a good crypto-random number generator for generating new passwords, when they're picked by the machine and not the user? You can use salts that They're all pseudo-random. Unless, maybe, you can get truly random with quantum computing, all you can ever do is pseudo-random. snip Without fail2ban, or something like it, they'll hit your system thousands of times an hour, at least. Sooner or later, they'll get lucky. OK do you *literally mean that* -- that with 10^21 possible passwords that an attacker has to search, I have to worry about the attacker getting lucky if they're trying thousands of times per hour? But I suppose you'll ignore this, as well. Oh, and your system wasn't compromised, so all of us are wrong, and you're correct. This thread's killfiled for me - it's pointless. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:04 PM, Lamar Owen wrote: On Tuesday, January 03, 2012 03:24:34 PM Bennett Haselton wrote: That there are 10^21 possible random 12-character alphanumeric passwords -- making it secure against brute-forcing -- is a fact, not an opinion. To date, *nobody* on this thread has ever responded when I said that there are 10^21 possible such passwords and as such I don't think that the password can be brute-forced in that way. Hmm, methinks you need to rethink the number. The number of truly random passwords available from a character set with N charaters and of a length L is N^L. (see https://en.wikipedia.org/wiki/Password_strength#Random_passwords ) If L=12, then: For: The numerals only: 10^12. The Uppercase alphabet only: 26^12 (9.5x10^16) Uppers and lowers: 52^12 (3.9x10^20) Numerals plus uppers and lowers: 62^12 (3.2x10^21) Base64: 64^12 (4.7x10^21) This is the figure I'm using (because I actually use some chars that aren't letters or numbers so I rounded up to 64). You got on the order of 10^21, same as me. Full ASCII printables, minus space: 94^12 (4.76x10^23) This of course includes repeating characters. NIST recommends 80-bit entropy-equivalent passwords for secure systems; 12 characters chosen at random from the full 95 ASCII printable characters doesn't quite make that (at a calculated 78 bits or so). I'm not sure what their logic is for recommending 80. But 72 bits already means that any attack is so improbable that you'd *literally* have to be more worried about the sun going supernova. Having said all of that, please see and read http://security.stackexchange.com/questions/3887/is-using-a-public-key-for-logging-in-to-ssh-any-better-than-saving-a-password The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. Actually, the top answer at that link appears to say that the server sends the nonce to the client, and only the client can successfully decrypt it. (Is that what you meant?) This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. Yes, I've acknowledged that whether you think 1024 bits is more secure than 72 bits depends on how literally you mean more secure. If the odds of an attack working in the next year are 1 in 10^10, you can reduce the odds to 1 in 10^20, which in a strict mathematical sense may make you more secure, but -- not really. Furthermore, when you're dealing with probabilities that ridiculously small, they're overwhelmed by the probability that an attack will be found against the actual algorithm (which I think is your point about possible weaknesses in the stream cipher). However, *then* you have to take into account the fact that, similarly, the odds of a given machine being compromised by a man-in-the-middle attack combined with cryptanalysis of the stream cipher, is *also* overwhelmed by the probability of a break-in via an exploit in the software it's running. I mean, do you think I'm incorrect about that? Of the compromised machines on the Internet, what proportion do you think were hacked via MITM-and-advanced-crypto, compared to exploits in the services? It was that calculation I was making when I kept insisting that there must be something more probable than brute-forcing the login or decrypting the session -- and if I hadn't stood my ground about that, the discussion never would have gotten around to SELinux, which, if it works in the manner described, may actually help. Obviously, the authenticating key's protection is paramount, and the passphrase is but one part of that. But that key never travels over the wire. In stark constrast, in password auth the password has to leave the system and traverse the connection, even if it's over an encrypted channel (it's hashed on the server end and compared to the server's stored hash, plus salt (always did like a little salt with my hash!), not the client, right? After all, the client may not possess the algorithm used to generate the hash, but password auth still works.). This leaves a password vulnerable to a 'man in the middle' attack if a weakness is found in the negotiated stream cipher used in the channel. Even with a full man-in-the-middle 'sniff' going on, the key pair authentication is as strong as the crypto used to generate the key pairs, which can be quite a bit stronger than the stream cipher. (56 bit DES, for instance, can be directly brute-forced in 'reasonable' amounts of time now). Pfft, if I understand the theory correctly (and I always
Re: [CentOS] turning off udev for eth0
On Tue, 2012-01-03 at 11:52 -0500, James B. Byrne wrote: I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not exist in the cloned guest one has to manually edit /etc/udev/rules.d/70-persistent-net.rules to get rid of the bogus entries and then restart the clone instance to have the changes take effect. All this does is return the new guest to the prototype eth0 configuration. Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. Make sure the 70-persistent-net.rules is empty or doesn't contain any mappings in your template. This file is generated automatically when new hardware is discovered. So as long as the template doesn't contain it, you'll get it generated. The issue you'll find yourself in, however, is that you may discover the NICs in the wrong sequence so eth0 and eth1 gets swapped around for you. A better solution is to not use the MAC address but the bios location in 70-persistent-net.rules. If you do that, you can keep the file in the template. It's a very common problem. Another way is to have a %post script in KS or after initial startup as a VM, that fixes the file based on what the VM properties are. -- Best Regards Peter Larsen Wise words of the day: If you want to make God laugh, tell him about your plans. -- Woody Allen signature.asc Description: This is a digitally signed message part ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:10 PM, Pete Travis wrote: Here's the qualifying statement I made, in an attempt to preempt pedantic squabbles over my choice of arbitrary figures and oversimplified math: I am not a statistician, but Here is a statement intended to startle you into re-examining your position: Simplistic probability puts the odds of success at 50% - either the attacker gets it right, or they don't. Oh, did you mean something like, Let's pick any value p as the probability of the attacker getting in by brute force in a given hour? OK, that's different. But it's still missing the point that if the odds of an event happening in the next year are less than the Earth crashing into the Sun, then it's not worth worrying about. There's a more basic error in your math. If there are two ways X and Y to attack a server, and X has a 1 in 100 chance of succeeding and Y has a 1 in 10^10 chance of succeeding, then if you reduce the chances of Y succeeding to 1 in 10^20, that's only an order of magnitude change in the likelihood of Y, *not* an order of magnitude change in the overall chance of a break-in, which changes by a negligible amount. Here's the intended take home message: The next guess has the same rough odds of being correct as the 100563674th guess. Yes, you have to worry about a brute force attack succeeding, every hour of every day that you give it a window to knock on. Here is you nitpicking over figures; acknowledging the opportunity for an improvement of several orders of magnitude and disregarding it, stuck in your misconceptions; and wholly missing the point. Actually, each time you make a guess and it's wrong, the probability of success goes up slightly for your next guess. Imagine having 10 cups with a ball under one of them. The probability of turning over the right cup on the first try is 1/10. If you're wrong, though, then the probability of getting it right on the next cup goes up to 1/9, and so on. But it's all a moot point if there are 10^24 possible passwords and the odds of finding the right one in any conceivable length of time are essentially zero. Of course, no amount of guessing will succeed on a system that doesn't accept passwords. System security, in terms of probability, seems to be an 'every little bit helps' sort of endeavour. Well it depends on how literally you mean every little bit :) If the chance of a break-in occurring in the next year from a given attack is 1 in 10^10, you can reduce it to 1 in 10^20, but it's already less likely than your data center being hit by a meteorite. The real problem is that it takes away from time that can be used for things that have a greater likelihood of reducing the chance of a break-in. If I had taken the advice about ssh keys at the beginning of the thread, I never would have gotten to the suggestion about SELinux. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos I'm moving on from this - much better men than I have tried and failed here. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haselton benn...@peacefire.org wrote: The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. Actually, the top answer at that link appears to say that the server sends the nonce to the client, and only the client can successfully decrypt it. (Is that what you meant?) This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. Yes, I've acknowledged that whether you think 1024 bits is more secure than 72 bits depends on how literally you mean more secure. If the odds of an attack working in the next year are 1 in 10^10, you can reduce the odds to 1 in 10^20, which in a strict mathematical sense may make you more secure, but -- not really. You are still speculating about the wrong things, though. Is your password written down? Has anyone ever been in the same room when you typed it? Could a key logger have been installed anywhere you typed it?And for the brute-force side of things, these may be done from a large number of sources to a large number of targets. They may be too slow to break any specific target but repeat it enough and you'll match something, somewhere. Maybe you were just the lucky one that day - and if you used the same password on the other(s) they would be easy targets. However, *then* you have to take into account the fact that, similarly, the odds of a given machine being compromised by a man-in-the-middle attack combined with cryptanalysis of the stream cipher, is *also* overwhelmed by the probability of a break-in via an exploit in the software it's running. I mean, do you think I'm incorrect about that? Of the compromised machines on the Internet, what proportion do you think were hacked via MITM-and-advanced-crypto, compared to exploits in the services? Proportions don't matter. Unless you have something extremely valuable to make this machine a target or someone captured your password and connection destination it was probably a random hit of a random probe. It doesn't matter if they are likely to work or not, some do. The problem with such basic stuff is that in any field, if there's no way to directly test whether something has the desired effect or not, it can become part of accepted common sense even if it's ineffective. If you have multiple layers of protection and look at your logs, you'll see what people are trying. And they keep trying it because it works... If you aren't looking at your logs there's not much use in speculating about what might be happening. Case in point: in the *entire history of the Internet*, do you think there's been a single attack that worked because squid was allowed to listen on a non-standard port, that would have been blocked if squid had been forced to listen on a standard port? Generalize that question to 'do you think attacks are helped by permitting applications to use ports the administrator didn't expect them to use' and the answer is clearly yes. There are certainly rogue trojans around that do who-knows-what on other connections while pretending to be your normal applications. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 2:13 PM, Lamar Owen wrote: On Sunday, January 01, 2012 06:27:32 PM Bennett Haselton wrote: (I have already practically worn out my keyboard explaining the math behind why I think a 12-character alphanumeric password is secure enough :) ) Also see: https://lwn.net/Articles/369703/ The focus of this article seems to be on systems with multiple users where the admin can't necessarily trust all the users to make smart decisions. I've already said that I can see why in that case it might be desirable to require users to use ssh keys instead of passwords, since you can't force users to use good passwords. My point was that if you're the only user and you can make yourself use a 12-char password with enough entropy, that's good enough. Bennett ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On 1/3/2012 4:21 PM, Les Mikesell wrote: On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haseltonbenn...@peacefire.org wrote: The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. Actually, the top answer at that link appears to say that the server sends the nonce to the client, and only the client can successfully decrypt it. (Is that what you meant?) This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. Yes, I've acknowledged that whether you think 1024 bits is more secure than 72 bits depends on how literally you mean more secure. If the odds of an attack working in the next year are 1 in 10^10, you can reduce the odds to 1 in 10^20, which in a strict mathematical sense may make you more secure, but -- not really. You are still speculating about the wrong things, though. Is your password written down? Has anyone ever been in the same room when you typed it? Could a key logger have been installed anywhere you typed it? Right, but these are all valid concerns if you use keys as well. If someone's in the room when you type in the passphrase for your key, they might come back in later and take the key and use the passphrase. If they install malware, they can capture the passphrase and the key as well. And for the brute-force side of things, these may be done from a large number of sources to a large number of targets. They may be too slow to break any specific target but repeat it enough and you'll match something, somewhere. Well yes but that doesn't make *my* password any less secure if it's chosen from a space of 10^21 possible passwords. The attacker will just move on. Maybe you were just the lucky one that day - and if you used the same password on the other(s) they would be easy targets. However, *then* you have to take into account the fact that, similarly, the odds of a given machine being compromised by a man-in-the-middle attack combined with cryptanalysis of the stream cipher, is *also* overwhelmed by the probability of a break-in via an exploit in the software it's running. I mean, do you think I'm incorrect about that? Of the compromised machines on the Internet, what proportion do you think were hacked via MITM-and-advanced-crypto, compared to exploits in the services? Proportions don't matter. Unless you have something extremely valuable to make this machine a target or someone captured your password and connection destination it was probably a random hit of a random probe. It doesn't matter if they are likely to work or not, some do. I either disagree or I'm not sure what you're saying. What do you mean that proportions don't matter? If attack A is 1,000 times more likely to work than attack B, you don't think it's more important to guard against attack A? Wasn't that exactly what you were advising when you said to worry more about someone capturing my password with a keylogger, than brute-forcing it? The problem with such basic stuff is that in any field, if there's no way to directly test whether something has the desired effect or not, it can become part of accepted common sense even if it's ineffective. If you have multiple layers of protection and look at your logs, you'll see what people are trying. And they keep trying it because it works... Well they might be trying it because it works against some other systems (in particular, brute-forcing a weak password). That doesn't mean it's any more likely to work on a system with a 12-char random password. If you aren't looking at your logs there's not much use in speculating about what might be happening. Case in point: in the *entire history of the Internet*, do you think there's been a single attack that worked because squid was allowed to listen on a non-standard port, that would have been blocked if squid had been forced to listen on a standard port? Generalize that question to 'do you think attacks are helped by permitting applications to use ports the administrator didn't expect them to use' and the answer is clearly yes. There are certainly rogue trojans around that do who-knows-what on other connections while pretending to be your normal applications. Well that seems like it would be trivial for the trojan to circumvent -- just listen on the standard port, and if you receive a connection that contains the secret handshake, switch that connection over into trojan mode, while continuing to serve other users' standard requests on the same port. Wouldn't that work? In that case it seems like
Re: [CentOS] probleme with my wifi card on centos 6
Le 2012-01-04 01:48, Ljubomir Ljubojevic a écrit : On 01/03/2012 10:14 PM, fakessh wrote: So I think do a post on the bugtracker of elrepo to ask the creation of a new kmod-* So I tried to compile the driver provided in [1] module appears to load properly When you run lspci -v, it shows something like: Kernel driver in use: rtl8185 Kernel modules: rtl8185 ??? lspci -v does not send me what I want this my output root@localhost swilting]# lspci -v | egrep Kernel Kernel driver in use: nForce2_smbus Kernel modules: i2c-nforce2 Kernel driver in use: ohci_hcd Kernel driver in use: ehci_hcd Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Kernel driver in use: forcedeth Kernel modules: forcedeth Kernel driver in use: sata_nv Kernel modules: sata_nv Kernel driver in use: sata_nv Kernel modules: sata_nv Kernel driver in use: nouveau Kernel modules: nouveau, nvidiafb Kernel driver in use: k10temp Kernel modules: k10temp Kernel modules: r8185b Kernel driver in use: is missing 01:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller (rev 20) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8185 IEEE 802.11a/b/g Wireless LAN Controller Flags: medium devsel, IRQ 16 I/O ports at bc00 [size=256] Memory at fde0 (32-bit, non-prefetchable) [size=1K] Kernel modules: r8185b Still I have failed to create the wireless interface despite my attempts with the file ifcfg-wlan0 tape provided I to try to load ifup the interface without success Why do you manually edit that file? Have you tried if NetworkManager or system-config-network-tui command (package has the same name) see the interface? I am completely lost and I do not know how please help me -- http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] vmware fusion display auto-size problem
Greetings. I am running vmware fusion 4.1.1 on a OSX host. Centos6.2 is a guest. The box is a macbook laptop running leopard. Before upgrading to 6.2, the display auto-resize (or auto-fill) was working fine. After 6.2, it has stopped working. Centos is fully updated to 6.2. I have tried to install the vmware drivers from the repository (via yum), and yum reports I have the latest. Vmware reports I have the latest version of app and linux tools. I have uninstalled and re-installed vmware tools to no avail. During the vmware tools install it returns a statement that it does not have drivers for x. Anybody else come across this? Google and vmware sites either do not have any info, or I am asking the wrong question. This being my first foray into vmware, is it advisable not to run updates until needed? What is best practice in this config? Thanks in advance for your help. Monty ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] turning off udev for eth0
On Tue, Jan 3, 2012 at 5:13 PM, Peter Larsen plar...@famlarsen.homelinux.com wrote: Is there no way to alter udev's behaviour? Is udev even needed on a server system using virtual hardware? Altering the rules file not a big deal in itself but it adds needless busywork when setting up a new guest. Make sure the 70-persistent-net.rules is empty or doesn't contain any mappings in your template. This file is generated automatically when new hardware is discovered. So as long as the template doesn't contain it, you'll get it generated. The issue you'll find yourself in, however, is that you may discover the NICs in the wrong sequence so eth0 and eth1 gets swapped around for you. A better solution is to not use the MAC address but the bios location in 70-persistent-net.rules. If you do that, you can keep the file in the template. It's a very common problem. Another way is to have a %post script in KS or after initial startup as a VM, that fixes the file based on what the VM properties are. It happens in real hardware too if you move a disk to a different chassis, clone a drive, restore a backup to similar hardware, etc. Where is the best documentation on what triggers the rules to be rewritten, how the bios location works, etc.? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6.X compatible to ORACLE DB verssion????
Somebody in Oracle told me, they need one year to test, I'm not sure, it's true or not. At 2012-01-02 Mon 09:46 -0600，Johnny Hughes wrote： On 01/01/2012 06:07 PM, Christopher J. Buckley wrote: On 29 December 2011 19:15, Johnny Hughes joh...@centos.org wrote: They can't very well (at least not with a straight face) tell Red Hat that RHEL6 is not certified while saying that OEL6 is certified can they? If they do that for very long, they will be breaching their support agreements. Really? In what way, out of interest? Hint: they're not. I am talking about likely preexisting contracts between Red Hat and Oracle where new products are certified in a timely matter. This is an example of a disputed contract between Oracle and another party: http://www.bloomberg.com/news/2011-06-15/hp-sues-oracle-in-california-over-breach-of-contract-claims.html (Note: I am not saying one or the other party in the above are right or wrong, just showing it as an example of the kinds of partnership agreements that Oracle has with other companies) And my point is, right now Oracle can say that they have not certified their own OEL6 either ... therefore, one can not expect RHEL6 to be certified either. If they certify OEL6 for a version of Oracle Database, it would be difficult for them to tell Red Hat that they can not certify RHEL6 or that there are issues with that version of their Oracle Database. Maybe Oracle does not have a preferred agreement with Red Hat to certify future products in a timely manner ... but I would find that highly unlikely. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos signature.asc Description: 这是信件的数字签名部分 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Tue, Jan 3, 2012 at 6:49 PM, Bennett Haselton benn...@peacefire.org wrote: Of the compromised machines on the Internet, what proportion do you think were hacked via MITM-and-advanced-crypto, compared to exploits in the services? Proportions don't matter. Unless you have something extremely valuable to make this machine a target or someone captured your password and connection destination it was probably a random hit of a random probe. It doesn't matter if they are likely to work or not, some do. I either disagree or I'm not sure what you're saying. What do you mean that proportions don't matter? I mean, if you get hit by lightning, did it really matter that you didn't have the more likely heart attack? If attack A is 1,000 times more likely to work than attack B, you don't think it's more important to guard against attack A? It's not either/or here. You could be the guy who gets hit by lightning. Case in point: in the *entire history of the Internet*, do you think there's been a single attack that worked because squid was allowed to listen on a non-standard port, that would have been blocked if squid had been forced to listen on a standard port? Generalize that question to 'do you think attacks are helped by permitting applications to use ports the administrator didn't expect them to use' and the answer is clearly yes. There are certainly rogue trojans around that do who-knows-what on other connections while pretending to be your normal applications. Well that seems like it would be trivial for the trojan to circumvent -- just listen on the standard port, and if you receive a connection that contains the secret handshake, switch that connection over into trojan mode, while continuing to serve other users' standard requests on the same port. Wouldn't that work? In that case it seems like a case of a restriction that might work until it becomes widely deployed enough for trojan authors to take it into account, at which point it becomes obsolete. Do you lock your doors or just leave them open because anyone who wants in can break a window anyway? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
On Wed, Jan 4, 2012 at 11:40 AM, Les Mikesell lesmikes...@gmail.com wrote: Do you lock your doors or just leave them open because anyone who wants in can break a window anyway? Hi Benneth, In conclusion, IMHO, I think you are worried too much :) Don't be afraid just because it's a dangerous world out there. - Subscribe to security advisories - Read best practice docs - Follow suggestions said in this list And high chances you will be fine :) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] phpmyadmin issue
Greetings,
On Tue, Jan 3, 2012 at 4:40 PM, John R Pierce pie...@hogranch.com wrote:
On 01/03/12 1:55 AM, Rajagopal Swaminathan wrote:
When I try to access it throughhttp://localhost/phpmyadmin it is
giving me a 403 forbidden error
I'd look in /var/log/httpd/{access,error}_log
maybe `tail -f /var/log/httpd/*_log` in a shell window, then hit the
webpage and see what new errors are barfed out a few seconds later...
[root@centos ~]# tail /var/log/httpd/access_log
:1 - - [04/Jan/2012:09:21:52 +0530] GET /phpmyadmin HTTP/1.1 403 287
- Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24)
Gecko/2009 CentOS/3.6.24-3.el6.centos Firefox/3.6.24
::1 - - [04/Jan/2012:09:21:55 +0530] GET /favicon.ico HTTP/1.1 404
284 - Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24)
Gecko/2009 CentOS/3.6.24-3.el6.centos Firefox/3.6.24
[root@centos ~]# tail /var/log/httpd/error_log
[Wed Jan 04 09:04:23 2012] [error] python_init: Python version
mismatch, expected '2.6.5', found '2.6.6'.
[Wed Jan 04 09:04:23 2012] [error] python_init: Python executable
found '/usr/bin/python'.
[Wed Jan 04 09:04:23 2012] [error] python_init: Python path being used
'/usr/lib64/python26.zip:/usr/lib64/python2.6/:/usr/lib64/python2.6/plat-linux2:/usr/lib64/python2.6/lib-tk:/usr/lib64/python2.6/lib-old:/usr/lib64/python2.6/lib-dynload'.
[Wed Jan 04 09:04:23 2012] [notice] mod_python: Creating 4 session
mutexes based on 256 max processes and 0 max threads.
[Wed Jan 04 09:04:23 2012] [notice] mod_python: using mutex_directory /tmp
[Wed Jan 04 09:04:25 2012] [warn] mod_wsgi: Compiled for Python/2.6.2.
[Wed Jan 04 09:04:25 2012] [warn] mod_wsgi: Runtime using Python/2.6.6.
[Wed Jan 04 09:04:25 2012] [notice] Apache/2.2.15 (Unix) DAV/2
mod_auth_kerb/5.4 mod_auth_pgsql/2.0.3 mod_nss/2.2.15 NSS/3.12.10.0
PHP/5.3.8 mod_python/3.3.1 Python/2.6.6 mod_ssl/2.2.15
OpenSSL/1.0.0-fips SVN/1.6.11 mod_wsgi/3.2 mod_perl/2.0.4 Perl/v5.10.1
configured -- resuming normal operations
[Wed Jan 04 09:21:52 2012] [error] [client ::1] client denied by
server configuration: /usr/share/phpmyadmin
[Wed Jan 04 09:21:55 2012] [error] [client ::1] File does not exist:
/var/www/html/favicon.ico
[root@centos ~]#
--
Regards,
Rajagopal
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Antwort: phpmyadmin issue
Greetings, On Tue, Jan 3, 2012 at 5:17 PM, John Broome jbro...@gmail.com wrote: On Jan 3, 2012, at 5:12, Rajagopal Swaminathan raju.rajs...@gmail.com wrote: Greetings On Tue, Jan 3, 2012 at 3:32 PM, Andreas Reschke andreas.resc...@behrgroup.com wrote: centos-boun...@centos.org schrieb am 03.01.2012 10:55:43: Rajagopal Swaminathan raju.rajs...@gmail.com Gesendet von: centos-boun...@centos.org 03.01.2012 10:55 Bitte antworten an CentOS mailing list centos@centos.org have you modified /etc/httpd/conf.d/phpMyAdmin.conf ? # # Web application to manage MySQL # Directory /usr/share/phpMyAdmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Alias /phpmyadmin /usr/share/phpMyAdmin Alias /phpMyAdmin /usr/share/phpMyAdmin Alias /mysqladmin /usr/share/phpMyAdmin my phpmyadmin.conf file reads: [root@centos phpmyadmin]# cat /etc/httpd/conf.d/phpmyadmin.conf # # Web application to manage MySQL # Directory /usr/share/phpmyadmin Order Deny,Allow Deny from all Allow from 127.0.0.1 /Directory Unless you're going to access this through a ssh tunnel to this machine fix this stanza of the config. I am on the machine. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Request for suggestion of a SCM package for Centos 6
Greetings, On Tue, Jan 3, 2012 at 10:22 AM, Les Mikesell lesmikes...@gmail.com wrote: Trac is packaged in the EPEL repository, and an only slightly outdated subversion is in the base distribution. Redmine and git might be more fashionable these days. Thanks Les. I _did_ install trac from exactly from the same repository. Somehow I lost the path to instantiating it. I had installed trac+svn about two years back on a Centos 5 box successfully. I am feeling somewhat lost now with Centos 6. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Request for suggestion of a SCM package for Centos 6
Greetings, On Tue, Jan 3, 2012 at 7:24 PM, Karanbir Singh mail-li...@karan.org wrote: On 01/03/2012 03:46 AM, Rajagopal Swaminathan wrote: 1. Can somebody suggest a way to select all packages while installing from DVD? you cant install everything from the DVD, since packages overlap and conflict with each other. a %post of yum --skip-broken install \*; might be your best bet. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc Thanks Karan, I will try to do that today. -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] phpmyadmin issue
On 01/03/12 7:57 PM, Rajagopal Swaminathan wrote: [Wed Jan 04 09:21:52 2012] [error] [client ::1] client denied by server configuration: /usr/share/phpmyadmin that says it all right there. ::1 is the ipv6 localhost. you probably allowed 127.0.0.1 but not ::1 you should. -- john r pierceN 37, W 122 santa cruz ca mid-left coast ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] phpmyadmin issue
Greetings, On Wed, Jan 4, 2012 at 9:36 AM, John R Pierce pie...@hogranch.com wrote: On 01/03/12 7:57 PM, Rajagopal Swaminathan wrote: [Wed Jan 04 09:21:52 2012] [error] [client ::1] client denied by server configuration: /usr/share/phpmyadmin that says it all right there. ::1 is the ipv6 localhost. you probably allowed 127.0.0.1 but not ::1 you should. I just did add ::1 Still forbidden :-( -- Regards, Rajagopal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] an actual hacked machine, in a preserved state
If attack A is 1,000 times more likely to work than attack B, you don't think it's more important to guard against attack A? It's not either/or here. You could be the guy who gets hit by lightning. I'm not sure I entirely agree with you there Les. I'm not going to delve into the intricacies of Cost / Benefit analysis (it made my head spin in my accounting school days) but basically, protecting against threats is in part a case of weighing the costs of setting up the protection vs the benefits of being 'immune' to such an attack adding in a dash of probability and stirring the whole mess in a black cauldron. What comes out is what the Bean counters consider an acceptable cost for that protection. Case in point, I have several web servers sitting in a rack in our server room. I'm more likely to suffer an attack on my key infrastructure through a compromised web server then I am through someone breaking down the door and entering the room. If I asked for a security system that included bio-metric access control systems, I'd be laughed at and denied. OTOH, I have a firewall with a DMZ that is both physically and logically isolated from the internal network and has IDS/IPS running on all traffic passing through. At the end of the day, there are finite resources anyone can spend protecting their organization and sometimes, hard choices have to be made. We have threats X, Y, and Z but only enough to protect against 2 of them. Which ones would you chose to protect? -- Drew ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Passwords apparently stopped working.
The /etc/shadow file has fields that control account login properties. The
following is out of the man file for /etc/shadow:
struct spwd {
char *sp_namp; /* user login name */
char *sp_pwdp; /* encrypted password */
long sp_lstchg; /* last password change */
int sp_min; /* days until change allowed. */
int sp_max; /* days before change required */
int sp_warn; /* days warning for expiration */
int sp_inact; /* days before account inactive */
int sp_expire; /* date when account expires */
int sp_flag; /* reserved for future use */
}
Could it be that the expiration field was set such that the passwords
expired?
-Original Message-
From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf
Of James B. Byrne
Sent: 03 January 2012 17:31
To: centos@centos.org
Subject: [CentOS] Passwords apparently stopped working.
I encountered a couple of strange events with respect to
password authentication this morning. Two of our staff
were unable to login onto several systems using their
usual passwords. Both users had last logged in on these
hosts using their accounts and passwords on Friday past.
The two accounts could not log on to any of the servers
for which they had access and the message log on each
showed that access was denied for a failed password. The
systems involved were running either CentOS-4.9 or
CentOS-5.7. So, the effect was uniform across multiple
hardware and software platforms. I also checked these
accounts against our warm backup machine and encountered
the same problems for both.
I verified that the passwords being used were correct for
the accounts. I also verified that neither of passwords
had been reset in some months and there were no expiry
dates set for the accounts.
I would accept the coincidence of both forgetting their
passwords except for the fact that each had kept a record
of their password in their wallets and I was able to
confirm those values against our records as well.
Resetting both the passwords to their current values using
the passwd utility on each system corrected the problem
insofar as the users were concerned. However, I am
somewhat perplexed as to the reason for their passwords to
stop working in the first place. Is anyone here aware of
any reason why this might happen?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
[CentOS] ASP running on a Linux Machine
Good morning all, I currently have a website that was written in ASP back in 1999. The system is currently running Windows 2003 Server with MsSQL. Before everyone flames me for being in the wrong place, I was wondering if there is a way to allow centos to run old ASP code? I know years ago this wasn't possible without a program like ChiliASP, but noow I heard rumor that apache might have a plugin to allow it to read ASP. I am unsure if there is an apache solution, or other solution like nginx/lighttpd that runs ASP. Any information you guys could provide would be great. I do appreciate your help in advance PS. I will need to convert the mssql data to mysql, is there any good program that will convert this? I understand that this question is probably inappropriate for this e-mail thread but maybe someone could shoot me a quick suggestion. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
