Re: [CentOS-docs] [CentOS] Securing SSH wiki article outdated
On 12/02/15 20:03, Warren Young wrote: Hi, just a quick note to whoever is maintaining this page: http://wiki.centos.org/HowTos/Network/SecuringSSH The procedure is missing the firewall-cmd calls necessary in EL7: firewall-cmd --add-port 2345/tcp firewall-cmd --add-port 2345/tcp --permanent Also, it may be worth mentioning that semanage is in the policycoreutils-python package, which isn’t installed by default in all stock configurations. Thank you, and copying to the centos-docs list for reference. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] Securing SSH wiki article outdated
On 12/02/15 20:03, Warren Young wrote: Hi, just a quick note to whoever is maintaining this page: http://wiki.centos.org/HowTos/Network/SecuringSSH The procedure is missing the firewall-cmd calls necessary in EL7: firewall-cmd --add-port 2345/tcp firewall-cmd --add-port 2345/tcp --permanent Also, it may be worth mentioning that semanage is in the policycoreutils-python package, which isn’t installed by default in all stock configurations. Thank you, and copying to the centos-docs list for reference. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On 12/02/15 20:03, Warren Young wrote: Hi, just a quick note to whoever is maintaining this page: http://wiki.centos.org/HowTos/Network/SecuringSSH The procedure is missing the firewall-cmd calls necessary in EL7: firewall-cmd --add-port 2345/tcp firewall-cmd --add-port 2345/tcp --permanent This is horrible advice anyway. It's not a good idea to run SSH on a port greater than 1024 since if a crash exploit is used to kill the process a non-root trojan process faking SSH to gather credentials could then bind on that port trivially totally compromising the system. If you really want to SSH to a port other than 22 for a little obscurity use an iptables dnat to map the high port to local host 22 and block 22 from external connections. That way SSH is still binding to a low port restricted to the root user and you can still get a little of that security through obscurity being desired. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote: On 02/13/2015 09:15 AM, Chris Adams wrote: Yeah, the old move stuff to alternate ports thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the bad guys. Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports. And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway. Lamar's comments are very sensible. I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses. Waste of time = all the time and energy required to clean-up after a hacker's breech when a few seconds work selecting a different port could make a beneficial improvement to security. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
Once upon a time, James Hogarth james.hoga...@gmail.com said: If you really want to SSH to a port other than 22 for a little obscurity use an iptables dnat to map the high port to local host 22 and block 22 from external connections. Yeah, the old move stuff to alternate ports thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the bad guys. -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On 02/13/2015 09:15 AM, Chris Adams wrote: Yeah, the old move stuff to alternate ports thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the bad guys. Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports. And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On 02/13/2015 05:41 AM, James Hogarth wrote: This is horrible advice anyway. It's not a good idea to run SSH on a port greater than 1024 since if a crash exploit is used to kill the process a non-root trojan process faking SSH to gather credentials could then bind on that port trivially totally compromising the system. This is where an SELinux policy on your server can come to your aid. You could set up your SELinux policy to allow binding to the desired SSH port by sshd alone, which would prevent the trojan process from rebinding it. But I think the '2345' is just there as an example. Perhaps a line in the HOWTO mentioning that it is preferred to have it listen to a port below 1024 would be appropriate. That way SSH is still binding to a low port restricted to the root user and you can still get a little of that security through obscurity being desired. I hate to break it to you, but all security is security through obscurity in some form or fashion. Some forms of obscurity (such as RSA private keys) are just more obscure than other forms of obscurity (like which of a mere 65,535 ports SSH is listening to today, or what knock code you need for the port knocker to access port 22, or whatever). Brute-forcing is just a way of breaking the obscurity of a password, etc. Even layered security is only as secure as the obscurity of how the layers interact. One of my day job's responsibilities is as site locksmith (and reverse engineering rotating constant master key systems using the Edwards matrix system is one of my current areas of study, since the site's previous occupants didn't leave complete records of the dozen or so RCM key systems here); it is tacit knowledge in locksmithing circles that all security is security through obscurity (even in safes with included hardplate, the security is only as good as the obscurity of the locations of the hardplate's inclusions). But it doesn't matter how randomly you pick the progressions, or whether you use TPP or limited progression or RCM or even spherical methods, it's still all about obscurity, as laid open by Matt Blaze's classic paper Rights Amplification in Master-Keyed Mechanical Locks (which caused a bit of a firestorm in certain locksmithing circles when it was published, even though it was a bit of an open secret anyway). Locksmiths have know for decades that security is not ever absolute; this is why safes are rated by how long they can resist knowledgeable attack (and I'm impressed that any safe can resist a thermic lance for longer than 30 minutes, but some can); this is also why lock hardware you buy is rated on a system (and higher rated locks do actually cost more to make). This is also why the Orange Book and its Rainbow kin exist (Orange Book = 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria). ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
Always Learning wrote: On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote: On 02/13/2015 09:15 AM, Chris Adams wrote: Yeah, the old move stuff to alternate ports thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the bad guys. Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports. And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway. Lamar's comments are very sensible. I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses. snip I disagree - I am in the waste of time camp. The reality is that only script kiddies start out by trying 22 (and I *do* mean script kiddies - I've seen attempts to ssh in that were obviously from warez, man, where they were too stupid to fill in ___ with a username, or salt. All the others, I figure they don't need to be major league, just someone with a clue, who'll run a scan; in fact, I'd expect them to run a scan just to see what IPs were visible, and I know that if I was writing a scan, I don't assume that I'm *so* brilliant that I'm the only one to think of scanning ports 1k while looking for systems that I might hit. mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, February 13, 2015 9:05 am, Always Learning wrote: On Fri, 2015-02-13 at 09:46 -0500, Lamar Owen wrote: On 02/13/2015 09:15 AM, Chris Adams wrote: Yeah, the old move stuff to alternate ports thing is largely a waste of time and just makes it more difficult for legitimate use. With large bot networks and tools like zmap, finding services on alternate ports is not that hard for the bad guys. Having SSH on 22 is lower-hanging fruit than having SSH on a different port. Sure, an NBA all-star will be able to reach the apples at the top of the tree easily, but most people are not NBA all-stars. Most port-scanners do not scan all possible ports. And I am fully aware that people in the 'it's a waste of time' camp are unmoved by that. It's not worth arguing about; those who move to non-standard ports are going to want to do it anyway. Lamar's comments are very sensible. I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses. Waste of time = all the time and energy required to clean-up after a hacker's breech when a few seconds work selecting a different port could make a beneficial improvement to security. Just to mention (even though someone already mentioned that): changing port numbers, or, say removing disclosure by the daemon what software, version, ... it is does not really add security. Security through obscurity is only considered to be efficient by Windows folks. Quite wrongfully IMHO. So, I would suggest to not do these non-standard things fooling yourself in wrongful feeling of better security. But instead, maintain the daemons updated. Keep passwords reasonably sophisticated. Do not start unnecessary services. Defend against brute force attacks (I use --hitcount option of iptabels on Linuxes and sshguard on FreeBSD). And speaking of security: maintain system free of local exploits (update, update, update...), that is if (when I always consider it for my systems) the bad guys are already in, they can not successfully elevate privileges. Each of the above is like big chapter on system security each said in one short phrase. And most importantly, read good fundamental Unix/Linux system book, and revisit your system configurations (from security point of view) while reading. Just my $0.02 Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, Feb 13, 2015 at 9:57 AM, Ken Smith k...@kensnet.org wrote: Hi All, I'm just wanting to check that my understanding of the settings is correct as my web searches are finding a lot of dated information. If I want a Centos 6 sendmail system act as the secondary MX for domain b.co.uk do I just add a Connect:b.co.uk RELAY statement into /etc/mail/access and restart sendmail Obviously I have the DNS MX records for the domain are already established. I've been getting /config error/: /mail loops back to me/ errors. I think I may be stumbling into a variant of cname problem where the hostname as far as the sendmail machine is concerned is a.com but the DNS setting for the secondary MX is smtp1.b.co.uk. They both resolve to the same IP but when sendmail looks up the MX records for b.co.uk it will find smtp.b.co.uk and smtp1.b.co.uk listed and it may relay the mail off to smtp1.b.co.uk without recognising that a.com = smtp1.b.co.uk. Am I on the right track here, as I then just need to change the secondary MX setting in DNS to a.com? I'd recommend not having a secondary MX at all unless it is equipped to reject invalid users and spam in all the same ways as your primary. Otherwise it accept junk that your primary rejects and then you are obligated to send a bounce message which is always a bad thing - you want the authoritative receiver to reject at the smtp level instead of accepting at all. There's a whole category of spam where the real target is the apparent sender where a bounce will go. Also anything sending valid mail should be prepared to queue and retry on temporary failures just as well as your own secondary would. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Centos 6 Sendmail backup MX Config
Hi All, I'm just wanting to check that my understanding of the settings is correct as my web searches are finding a lot of dated information. If I want a Centos 6 sendmail system act as the secondary MX for domain b.co.uk do I just add a Connect:b.co.uk RELAY statement into /etc/mail/access and restart sendmail Obviously I have the DNS MX records for the domain are already established. I've been getting /config error/: /mail loops back to me/ errors. I think I may be stumbling into a variant of cname problem where the hostname as far as the sendmail machine is concerned is a.com but the DNS setting for the secondary MX is smtp1.b.co.uk. They both resolve to the same IP but when sendmail looks up the MX records for b.co.uk it will find smtp.b.co.uk and smtp1.b.co.uk listed and it may relay the mail off to smtp1.b.co.uk without recognising that a.com = smtp1.b.co.uk. Am I on the right track here, as I then just need to change the secondary MX setting in DNS to a.com? Many thanks Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-es] Bug horrible en CentOS 7 Desktop
El error te lo manda gnome-shell, y si por lo visto es un bug reportado en fedora 19 mismo comportamiento y esto debido a un consumo alto de recursos, de igual manera la recomendacion es deshabilitar las extensiones. Lo que podrias intentar no se si exista en la version de gnome 3.x es entrar como en modo para resolver problemas. En caso de no funcionar podrias ejecutar un kill -HUP gnome-shell volver a hacer un trace para indentificar la extension. Y bueno en todo caso seria esperar a que resuelvan el bug mientras tanto podrias intentar iniciar con XFCE para que puedas continuar trabajando. Saludos! On Thu, Feb 12, 2015 at 3:43 AM, Alex ( Servtelecom ) alex.and...@servtelecom.com wrote: Hola compañeros llevo desde que salio CentOS 7 utilizando en mi Portátil ya que busco algo estable y no sufrir de verionitis Desde que salio que tengo el mismo bug que no hay manera de que se solucione, a la que llevo 1h trabajando el escritorio se vuelve inestable, se queda congelado durante varios minutos y siempre cuando más urgencia tienes en hacer algo Me estoy planteando cambiar de distro pero quiero dar una oportunidad ya que son muchos años utilizando CentOS en servidores y en mi portátil desde CentOS 6 que lo utilizo los log's que muestra mi portátil: *Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:54 Portatil dbus-daemon: dbus[620]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'** ** **eb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed* Alguna idea, creéis que con la 7.1 aumentaran las versiones de tal manera que se solucione el problema?? Este problema es el mismo que mucha gente se quejaba con Fedora 19 que es la referencia que utiliza CentOS 7. Espero vuestras respuestas para poder reportar los desarrolladores de CentOS ya que mi ingles es muy malo y lo he intentado pero ni me responden ;( ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es -- Aldo Rivadeneira Reyna ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] Thread moderation and list etiquette (Reference - Another Fedora Decision)
On 12/02/15 16:51, Brian Mathis wrote: Thanks for putting in the effort here. It's never a good situation to have to moderate, but sometimes it is necessary. From my perspective, this kind of thing happens far more often than the current example, though maybe not with such intensity. This situation A large part of this is that some of the regular people are now using the list as a way to socialise and contribute 'me too' or 'yes/no' sort of comments that dont really have much relevance to the real thread. All of this not only makes the list unwelcoming to new users, it also dramatically drops the quality of conversation. If moderating is the only way to restore sanity and keep things productive for the folks bringing through conversations then so be it, we will start putting individual accounts on moderation. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thread moderation and list etiquette (Reference - Another Fedora Decision)
On 12/02/15 18:08, Les Mikesell wrote: On Thu, Feb 12, 2015 at 10:51 AM, Brian Mathis brian.mathis+cen...@betteradmin.com wrote: CentOS is unquestionably one of the most used Linux distros in the world, and yet the mailing list is relatively quiet. To me this is a symptom of a problem, and I feel that it's partially a result of the same regular people, I think it is generally a good thing when the bulk of the conversation here is ranting about mostly irrelevant opinions. That is, instead yes, lots of irrelevant conversation on the list - and it comes from a handful of users. Its irrelevant, take it to an irrelevant venue. of 'Why doesn't this work', or 'How do I fix this problem that you would have if there were something fundamentally wrong with the disto. By assuming that the mailing list is a bug reporting venue, you miss the entire point of what a community might be. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thread moderation and list etiquette (Reference - Another Fedora Decision)
On Fri, Feb 13, 2015 at 12:09 PM, Karanbir Singh mail-li...@karan.org wrote: I think it is generally a good thing when the bulk of the conversation here is ranting about mostly irrelevant opinions. That is, instead yes, lots of irrelevant conversation on the list - and it comes from a handful of users. Its irrelevant, take it to an irrelevant venue. of 'Why doesn't this work', or 'How do I fix this problem that you would have if there were something fundamentally wrong with the disto. By assuming that the mailing list is a bug reporting venue, you miss the entire point of what a community might be. Agreed, but second-guessing other people's opinions and moderating what they can say is pretty shaky ground too... I'm just saying that's what happens when there aren't bugs to report and generic 'how to' questions tend to be met with a 'go google it yourself' response. It would sort of nice if there were a way to sort pure-technical stuff from 'slightly-related' and 'way-off-topic' postings so actual conversations could run their course without mangling the list's purpose. But I don't have any idea how to manage that... -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
Les Mikesell wrote: On Fri, Feb 13, 2015 at 11:39 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: Otherwise it accept junk that your primary rejects Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn't behave as mail server (thus never comes for re-delivery, and definitely doesn't try backup MX which real servers always do even before attempt of re-delivery). I'm not convinced. Spam is big business and trying a 2nd MX is cheap. Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. Aside from the blowback of the bounces, if you've ever accepted an address it is likely to get on lists of known-good spam and cause extra traffic forever after. In this case the secondary MX has the same RBL's etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses. Thoughts on my configuration?? I might just change the DNS name in the secondary MX anyway. Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thread moderation and list etiquette (Reference - Another Fedora Decision)
On Fri, February 13, 2015 12:07 pm, Karanbir Singh wrote: On 12/02/15 16:51, Brian Mathis wrote: Thanks for putting in the effort here. It's never a good situation to have to moderate, but sometimes it is necessary. From my perspective, this kind of thing happens far more often than the current example, though maybe not with such intensity. This situation A large part of this is that some of the regular people are now using the list as a way to socialise and contribute 'me too' or 'yes/no' sort of comments that dont really have much relevance to the real thread. All of this not only makes the list unwelcoming to new users, it also dramatically drops the quality of conversation. If moderating is the only way to restore sanity and keep things productive for the folks bringing through conversations then so be it, we will start putting individual accounts on moderation. (answering off the list to diminish buzz) More than agree. Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, February 13, 2015 11:52 am, Les Mikesell wrote: On Fri, Feb 13, 2015 at 11:39 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: Otherwise it accept junk that your primary rejects Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn't behave as mail server (thus never comes for re-delivery, and definitely doesn't try backup MX which real servers always do even before attempt of re-delivery). I'm not convinced. Spam is big business and trying a 2nd MX is cheap. I stated pure observation on at least two pairs of primary - backup MX I maintain. Still I made backup MXes with greylisting as well (they are separately hit by same bad spammers scripts, at a rate about 10 times smaller than primary MXes are and absolutely independently). Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. With standard backup MX based on postix (with rather trivial configuration) you always do have list of legitimate recipients of primary MX on the secondary MX. Sorry if my previous e-mail is not explicit enough about it. It's a work, however, to maintain that table on backup MX (so your backup MX does accept mail for newly added users to primary MX). But having backup MX receiving everything is wrong configuration prone to backscatter - at least I see we agree on that. So, just don't roll out badly configured backup MX, I would say. Valeri Aside from the blowback of the bounces, if you've ever accepted an address it is likely to get on lists of known-good spam and cause extra traffic forever after. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, February 13, 2015 12:18 pm, Ken Smith wrote: Les Mikesell wrote: On Fri, Feb 13, 2015 at 11:39 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: Otherwise it accept junk that your primary rejects Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn't behave as mail server (thus never comes for re-delivery, and definitely doesn't try backup MX which real servers always do even before attempt of re-delivery). I'm not convinced. Spam is big business and trying a 2nd MX is cheap. Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. Aside from the blowback of the bounces, if you've ever accepted an address it is likely to get on lists of known-good spam and cause extra traffic forever after. In this case the secondary MX has the same RBL's etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses. What software the secondary MX is based on in whose case you say secondary MX doesn't know legitimate addresses of primary MX? I know about postfix. And all my servers are based on postfix. And even in the most trivial configuration of secondary MX based on postfix secondary MX _does_ have to have all legitimate addressed of primary MX. These are in relay_recipients table. Any address that is not in that table, will not be accepted by secondary MX. Postfix even in the most trivial configuration is sane and does not accept everything. So, what is the secondary MX server that you are describing that accepts everything is based on? Valeri Thoughts on my configuration?? I might just change the DNS name in the secondary MX anyway. Ken -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, Feb 13, 2015 at 12:45 PM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: In this case the secondary MX has the same RBL's etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses. What software the secondary MX is based on in whose case you say secondary MX doesn't know legitimate addresses of primary MX? I know about postfix. And all my servers are based on postfix. And even in the most trivial configuration of secondary MX based on postfix secondary MX _does_ have to have all legitimate addressed of primary MX. These are in relay_recipients table. Any address that is not in that table, will not be accepted by secondary MX. Postfix even in the most trivial configuration is sane and does not accept everything. So, what is the secondary MX server that you are describing that accepts everything is based on? I think he means that the secondary does not know the user names on the primary. Which it won't, unless someone maintains it, regardless of the server software. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, Feb 13, 2015 at 11:39 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: Otherwise it accept junk that your primary rejects Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn't behave as mail server (thus never comes for re-delivery, and definitely doesn't try backup MX which real servers always do even before attempt of re-delivery). I'm not convinced. Spam is big business and trying a 2nd MX is cheap. Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. Aside from the blowback of the bounces, if you've ever accepted an address it is likely to get on lists of known-good spam and cause extra traffic forever after. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] firewalld default policy = allow = no affect.
On 02/12/2015 08:14 PM, dE wrote: Looking at the default policies of various zones, I've come to realize that only the drop zone has an affect, that's because this's the only one which drops unmatched packets. I'm not sure what you mean, but most firewall sets for iptables follow the same pattern. First, allow packets which are part of an established connection, or related to an established connection (such as an FTP data connection). Next, allow new connections by local policy. Finally, drop or reject everything else. The first and last parts are fairly standard. Some tools will set the policy to DROP, where firewalld instead terminates the rule set with a DROP for invalid packets and REJECT for the rest. If your point is that the INPUT table policy doesn't have an effect, that is by design. A DROP policy is not required, and it means that if a local admin resets the rule set in order to reload it, there won't be a moment where the POLICY is DROP and there are no ACCEPT rules, leaving the system potentially inaccessible. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, Feb 13, 2015 at 12:32 PM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: I stated pure observation on at least two pairs of primary - backup MX I maintain. Still I made backup MXes with greylisting as well (they are separately hit by same bad spammers scripts, at a rate about 10 times smaller than primary MXes are and absolutely independently). I think that's unusual - spammers often target the secondaries as a preference on the premise that they are likely to not be as well-configured as the primary. But it has been a while since I ran one so maybe things have changed. Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. With standard backup MX based on postix (with rather trivial configuration) you always do have list of legitimate recipients of primary MX on the secondary MX. Doing greylisting right means you also have to keep the table of already-known senders up to date and that may be very dynamic. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, February 13, 2015 11:04 am, Les Mikesell wrote: On Fri, Feb 13, 2015 at 9:57 AM, Ken Smith k...@kensnet.org wrote: Hi All, I'm just wanting to check that my understanding of the settings is correct as my web searches are finding a lot of dated information. If I want a Centos 6 sendmail system act as the secondary MX for domain b.co.uk do I just add a Connect:b.co.uk RELAY statement into /etc/mail/access and restart sendmail Obviously I have the DNS MX records for the domain are already established. I've been getting /config error/: /mail loops back to me/ errors. I think I may be stumbling into a variant of cname problem where the hostname as far as the sendmail machine is concerned is a.com but the DNS setting for the secondary MX is smtp1.b.co.uk. They both resolve to the same IP but when sendmail looks up the MX records for b.co.uk it will find smtp.b.co.uk and smtp1.b.co.uk listed and it may relay the mail off to smtp1.b.co.uk without recognising that a.com = smtp1.b.co.uk. Am I on the right track here, as I then just need to change the secondary MX setting in DNS to a.com? I'd recommend not having a secondary MX at all unless it is equipped to reject invalid users and spam in all the same ways as your primary. Agree, but... Otherwise it accept junk that your primary rejects Not exactly. If greylisting on primary is set, but on backup MX is not, still what is killed by greylisting by primary MX, almost never will come through backup MX. This is due to the same reason why greylisting is efficient: it trows off all that doesn't behave as mail server (thus never comes for re-delivery, and definitely doesn't try backup MX which real servers always do even before attempt of re-delivery). Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. and then you are obligated to send a bounce message which is always a bad thing - you want the authoritative receiver to reject at the smtp level instead of accepting at all. I agree, it is wrongful behavior to accept something which later you discover you can not deliver. I would call it bad MX setup, as you are making yourself potential source of backscatter (which though is not as much exploited yet as open relays, but still is bad setup). If you set backup MX based on postfix, there is relay_recipients you have to specify, which lists all e-mail addresses that are legitimate on primary MX. Nothing else is being accepted by default, thus secondary MX does not become a source of backscatter. rant I've seen at least at some point that google mail accepts everything. Then, (after they parsed and filed information in that message I would speculate) they send non-delivery notification. That was a real incident after which I have a policy on my servers: I do not forward e-mail of users who left department to their google mail. As I don't want _my_ server to become a source of backscatter as a result of the crap they do. /rant Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
Once upon a time, Ken Smith k...@kensnet.org said: In this case the secondary MX has the same RBL's etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses. That's a big bad idea. Aside from spam filtering, your backup will accept invalid recipients and then (when delivery to primary fails) generate bounces back to senders. This is known as back scatter and will get your server black-listed. If you don't have a network name service of some type (e.g. LDAP), don't do this. The real question is: what are you trying to achieve with a backup MX? If it is to store mail when the primary is down, legitimate remote mail servers will do that for you; you don't need to have a backup. -- Chris Adams li...@cmadams.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Feb 13, 2015, at 9:03 AM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: ...changing port numbers...does not really add security. Security through obscurity is only considered to be efficient by Windows folks. “Security through obscurity” is an overused mantra of derision. Originally, it was a cry against systems where obscurity was the *only* security measure taken. You could legitimately use it today against software that uses a Caesar cipher instead of AES, or against an admin who moves a publicly-visible file to a nonstandard location to hide it instead of changing its permissions away from world-readable. Obscurity as an addition to other forms of strength has been a useful tactic since before the Roman Empire was founded. “…that general…is successful in defense whose opponent does not know what to attack.” — Sun Tzu, approx 500 BCE Moving the sshd listening port greatly cuts down on the amount of log spam you get from bots. Yes, the script kiddies can still find your server. But before you dismiss this tactic, try the experiment. Move your sshd to a different port and see what happens to your log spam. Another legitimate reason to move the SSH port is to cope with overly-restrictive outbound firewalls on other people’s networks. We have one SSH server that listens on port 110 because the site that logs into it has unconditionally blocked port 22 outbound, and we can’t get the local admin to open that port up for us. If you want to talk about naive security associated with Windows admins, let’s talk about admins who block SSH, which is almost never a *successful* attack vector, while still allowing outbound POP3 connections in a world where email is probably the #1 vector. :facepalm: ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, February 13, 2015 12:52 pm, Les Mikesell wrote: On Fri, Feb 13, 2015 at 12:45 PM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: In this case the secondary MX has the same RBL's etc etc as the primary. I do see the spammers sending their junk to the secondary more than the primary MX. Agree the secondary does not know the difference between valid and invalid addresses. What software the secondary MX is based on in whose case you say secondary MX doesn't know legitimate addresses of primary MX? I know about postfix. And all my servers are based on postfix. And even in the most trivial configuration of secondary MX based on postfix secondary MX _does_ have to have all legitimate addressed of primary MX. These are in relay_recipients table. Any address that is not in that table, will not be accepted by secondary MX. Postfix even in the most trivial configuration is sane and does not accept everything. So, what is the secondary MX server that you are describing that accepts everything is based on? I think he means that the secondary does not know the user names on the primary. Which it won't, unless someone maintains it, regardless of the server software. Did you ever set up backup MX based on postfix? Sounds like not, as in case of postfix you have to maintain that table on backup MX, or it will not accept anything destined to primary MX. It is only now that I read the thread subject... which is about sendmail. So, I guess my comments about postfix are not relevant or not quite relevant to this thread. I started replacing venerable sendmail almost two decades back with postfix which was written with security in mind from the very beginning by brilliant person: Vietse Venema. I still like human readable configuration files of postfix and got really used to all logic of it. So even though sendmail I heard is not a security disaster for long time already I'm quite happy with postfix. At some point even RedHat switched to postfix as default MX software on their system (not long ago though...). I guess, backup MX example makes me even happier: postfix really prevents you from doing wrong thing (making your backup MX a source of backscatter). Just my $0.02 Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On 13/02/15 18:45, Valeri Galtsev wrote: So, what is the secondary MX server that you are describing that accepts everything is based on? if you actually read the thread you are replying to blindly, you might find out ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Getting strange message in terminal
On Sat, 14 Feb 2015 01:52:00 +0530 MOHD HOMAIDUR RAHMAN wrote: when I am login in terminal I am getting following message. Something is running the export command when you login. Type the word export at a bash prompt and I'd bet you'll see the same output again. You probably have something screwed up in your ~/.bashrc file. -- MELVILLE THEATRE ~ Real D 3D Digital Cinema ~ www.melvilletheatre.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] xfs_quotas
Hi, folks, (The system I'm doing this on is actually RHEL 6.6, but that list is so quiet) We've got a new RAID box attached to the server. Large. We'd like to implement xfs quotas... but one thing I can't find is information on this: we want to export the real directory to /project, and let automount bind it under there. (/project/hisproj). All I find shows creating a permanent mount point. Is this actually do-able? Can I set the quota on the real location? (/mnt/drive/project/hisproj, say), and have them work? mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, February 13, 2015 12:41 pm, Les Mikesell wrote: On Fri, Feb 13, 2015 at 12:32 PM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: I stated pure observation on at least two pairs of primary - backup MX I maintain. Still I made backup MXes with greylisting as well (they are separately hit by same bad spammers scripts, at a rate about 10 times smaller than primary MXes are and absolutely independently). I think that's unusual - spammers often target the secondaries as a preference on the premise that they are likely to not be as well-configured as the primary. But it has been a while since I ran one so maybe things have changed. Consider me lucky... Still, it is good to have the same greylisting on backup MX. And all other blows and whistles. Greylisting would be kind of hard to do right. You'd have to keep the known-good senders in sync across the receivers. But my bigger worry would be a dictionary-type attack on user names as recipients if you don't have access to the real user list on the secondary. With standard backup MX based on postix (with rather trivial configuration) you always do have list of legitimate recipients of primary MX on the secondary MX. Doing greylisting right means you also have to keep the table of already-known senders up to date and that may be very dynamic. If you are kind person, yes. Sqlgrey is designed to work simultaneously for primary, secondary (and tretary maybe - didn't check) MXes. Yet, even if they are independent, all will work, you are just not being nice to other servers and make them make 3 delivery attempts (the last is successful) instead of two (that is: primary MX - temporary failure, secondary - temporary failure, primary after some time - accepted; instead of primary MX - temporary failure, secondary - accepted which will be in nice configuration common for both MXes greylisting engine and database). Valeri Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] docker 1.5 in virt7-testing
On 13/02/15 19:18, Lokesh Mandvekar wrote: On Fri, Feb 13, 2015 at 12:15:39PM +, Karanbir Singh wrote: hi guys, docker 1.5 is now in virt7-testing repos, please test and feedback so we can move to release.. thanks lokesh! - KB Sure thing KB. Also, docker-registry will be ready for release by tonight (meaning working package and docs etc.) docker HEAD for c7 -- I was hoping for wider feedback on daily rebuilds of docker master branch for c7 (which I already do for fedora rawhide), under a new package name (docker-unstable / docker-head / whatever). IIRC, KB and jperrin were for it. How does that sound to others? Or should I go ahead with this already? :) I am still for it! Thanks! ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] xfs_quotas
- Original Message - | Hi, folks, | |(The system I'm doing this on is actually RHEL 6.6, but that list is so | quiet) | |We've got a new RAID box attached to the server. Large. We'd like to | implement xfs quotas... but one thing I can't find is information on | this: we want to export the real directory to /project, and let | automount bind it under there. (/project/hisproj). All I find shows | creating a permanent mount point. | |Is this actually do-able? Can I set the quota on the real location? | (/mnt/drive/project/hisproj, say), and have them work? | | mark | XFS quotas are set on the device/filesystem in question, not a particular mount point. We use automount to mount filesystems all over the place and XFS quotas work just fine. -- James A. Peltier IT Services - Research Computing Group Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpelt...@sfu.ca Website : http://www.sfu.ca/itservices Twitter : @sfu_rcg Powering Engagement Through Technology Build upon strengths and weaknesses will generally take care of themselves - Joyce C. Lock ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
Ken Smith wrote: Hi All, I'm just wanting to check that my understanding of the settings is correct as my web searches are finding a lot of dated information. If I want a Centos 6 sendmail system act as the secondary MX for domain b.co.uk do I just add a Connect:b.co.uk RELAY statement into /etc/mail/access and restart sendmail Obviously I have the DNS MX records for the domain are already established. I've been getting /config error/: /mail loops back to me/ errors. I think I may be stumbling into a variant of cname problem where the hostname as far as the sendmail machine is concerned is a.com but the DNS setting for the secondary MX is smtp1.b.co.uk. They both resolve to the same IP but when sendmail looks up the MX records for b.co.uk it will find smtp.b.co.uk and smtp1.b.co.uk listed and it may relay the mail off to smtp1.b.co.uk without recognising that a.com = smtp1.b.co.uk. Am I on the right track here, as I then just need to change the secondary MX setting in DNS to a.com? Many thanks Ken I've changed the secondary MX record for the domain and I'll see if the problem goes away. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] docker 1.5 in virt7-testing
On Fri, Feb 13, 2015 at 12:15:39PM +, Karanbir Singh wrote: hi guys, docker 1.5 is now in virt7-testing repos, please test and feedback so we can move to release.. thanks lokesh! - KB Sure thing KB. Also, docker-registry will be ready for release by tonight (meaning working package and docs etc.) docker HEAD for c7 -- I was hoping for wider feedback on daily rebuilds of docker master branch for c7 (which I already do for fedora rawhide), under a new package name (docker-unstable / docker-head / whatever). IIRC, KB and jperrin were for it. How does that sound to others? Or should I go ahead with this already? :) Thanks! -- Lokesh Freenode, OFTC: lsm5 GitHub: @lsm5 GPG: 0xC7C3A0DD pgp4vIjqDsCBb.pgp Description: PGP signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, Feb 13, 2015 at 1:11 PM, Valeri Galtsev galt...@kicp.uchicago.edu wrote: So even though sendmail I heard is not a security disaster for long time already I'm quite happy with postfix. Sendmail was pretty much all fixed by the time postfix was released, and made even better with the addition of the milter interface that lets you run scanning, etc. processes under different uids but able to participate in the smtp conversation. Postfix eventually got around to copying that too. At some point even RedHat switched to postfix as default MX software on their system (not long ago though...). Just another change for change's sake as far as I'm concerned. Sendmail continues to work just fine and the configs as shipped rarely take more than a few lines of change in the m4 file to do normal operations. I guess, backup MX example makes me even happier: postfix really prevents you from doing wrong thing (making your backup MX a source of backscatter). It's not postfix doing that, it is you, doing whatever has to be done to keep your lists in sync. Still, I don't see the point of even having a secondary MX. The days are long gone when chunks of the internet can't reach each other for long periods of time and anything sending should do its own queuing and retries. In fact if you do greylisting, you have forced all of your senders to prove it. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Getting strange message in terminal
Dear all when I am login in terminal I am getting following message. declare -x ALL_PROXY=socks://hproxy.iitm.ac.in:3128/ declare -x AMBERHOME=/sware/amber/amber12 declare -x COLORTERM=gnome-terminal declare -x CPPFLAGS=-I/usr/local/bin/include declare -x DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-adjIuc8A5l,guid=d2289573889e3cae1ac3908354de3192 declare -x DESKTOP_SESSION=gnome-classic declare -x DISPLAY=:0 declare -x FTP_PROXY=http://hproxy.iitm.ac.in:3128/; declare -x G09BASIS=/usr/local/gaussian/g09/basis declare -x GAUSS_ARCHDIR=/usr/local/gaussian/g09/arch declare -x GAUSS_BSDDIR=/usr/local/gaussian/g09/bsd declare -x GAUSS_EXEDIR=/usr/local/gaussian/g09/bsd:/usr/local/gaussian/g09/local:/usr/local/gaussian/g09/extras:/usr/local/gaussian/g09 declare -x GAUSS_LEXEDIR=/usr/local/gaussian/g09/linda-exe declare -x GAUSS_SCRDIR=/scratch declare -x GDMSESSION=gnome-classic declare -x GDM_LANG=en_US.utf8 declare -x GNOME_DESKTOP_SESSION_ID=this-is-deprecated declare -x GNOME_KEYRING_CONTROL=/run/user/1000/keyring-oPxj9T declare -x GNOME_KEYRING_PID=2515 declare -x GNOME_SHELL_SESSION_MODE=classic declare -x GPG_AGENT_INFO=/run/user/1000/keyring-oPxj9T/gpg:0:1 declare -x GV_DIR=/usr/local/gaussian/gv declare -x HARDWARE_PLATFORM=x86_64 declare -x HISTCONTROL=ignoredups declare -x HISTSIZE=1000 declare -x HOME=/home/rahman declare -x HOSTNAME=localhost.btb.igloonet declare -x HTTPS_PROXY=http://hproxy.iitm.ac.in:3128/; declare -x HTTP_PROXY=http://hproxy.iitm.ac.in:3128; declare -x IMSETTINGS_INTEGRATE_DESKTOP=yes declare -x IMSETTINGS_MODULE=none declare -x KDEDIRS=/usr declare -x LANG=en_US.utf8 declare -x LC_MEASUREMENT=en_US.utf8 declare -x LC_MONETARY=en_US.utf8 declare -x LC_NUMERIC=en_US.utf8 declare -x LC_PAPER=en_US.utf8 declare -x LC_TIME=en_US.utf8 declare -x LDFLAGS=-L/usr/local/lib declare -x LD_LIBRARY_PATH=/usr/local/gaussian/g09/bsd:/usr/local/gaussian/g09/local:/usr/local/gaussian/g09/extras:/usr/local/gaussian/g09:/usr/local/gaussian/g09/bsd:/usr/local/gaussian/g09/local:/usr/local/gaussian/g09/extras:/usr/local/gaussian/g09::/lib:/usr/local/gaussian/gv/lib:/usr/local/gaussian/gv/lib declare -x LESSOPEN=||/usr/bin/lesspipe.sh %s declare -x LOADEDMODULES= declare -x LOGNAME=rahman declare -x LS_COLORS=rs=0:di=38;5;27:ln=38;5;51:mh=44;38;5;15:pi=40;38;5;11:so=38;5;13:do=38;5;5:bd=48;5;232;38;5;11:cd=48;5;232;38;5;3:or=48;5;232;38;5;9:mi=05;48;5;232;38;5;15:su=48;5;196;38;5;15:sg=48;5;11;38;5;16:ca=48;5;196;38;5;226:tw=48;5;10;38;5;16:ow=48;5;10;38;5;21:st=48;5;21;38;5;15:ex=38;5;34:*.tar=38;5;9:*.tgz=38;5;9:*.arc=38;5;9:*.arj=38;5;9:*.taz=38;5;9:*.lha=38;5;9:*.lz4=38;5;9:*.lzh=38;5;9:*.lzma=38;5;9:*.tlz=38;5;9:*.txz=38;5;9:*.tzo=38;5;9:*.t7z=38;5;9:*.zip=38;5;9:*.z=38;5;9:*.Z=38;5;9:*.dz=38;5;9:*.gz=38;5;9:*.lrz=38;5;9:*.lz=38;5;9:*.lzo=38;5;9:*.xz=38;5;9:*.bz2=38;5;9:*.bz=38;5;9:*.tbz=38;5;9:*.tbz2=38;5;9:*.tz=38;5;9:*.deb=38;5;9:*.rpm=38;5;9:*.jar=38;5;9:*.war=38;5;9:*.ear=38;5;9:*.sar=38;5;9:*.rar=38;5;9:*.alz=38;5;9:*.ace=38;5;9:*.zoo=38;5;9:*.cpio=38;5;9:*.7z=38;5;9:*.rz=38;5;9:*.cab=38;5;9:*.jpg=38;5;13:*.jpeg=38;5;13:*.gif=38;5;13:*.bmp=38;5;13:*.pbm=38;5;13:*.pgm=38;5;13:*.ppm=38;5;13:*.tga=38;5;13:*.xbm=38;5;13:*.xpm=38;5;13:*.tif=38;5;13:*.tiff=38;5;13: *.png=38;5;13:*.svg=38;5;13:*.svgz=38;5;13:*.mng=38;5;13:*.pcx=38;5;13:*.mov=38;5;13:*.mpg=38;5;13:*.mpeg=38;5;13:*.m2v=38;5;13:*.mkv=38;5;13:*.webm=38;5;13:*.ogm=38;5;13:*.mp4=38;5;13:*.m4v=38;5;13:*.mp4v=38;5;13:*.vob=38;5;13:*.qt=38;5;13:*.nuv=38;5;13:*.wmv=38;5;13:*.asf=38;5;13:*.rm=38;5;13:*.rmvb=38;5;13:*.flc=38;5;13:*.avi=38;5;13:*.fli=38;5;13:*.flv=38;5;13:*.gl=38;5;13:*.dl=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=38;5;45:*.mka=38;5;45:*.mp3=38;5;45:*.mpc=38;5;45:*.ogg=38;5;45:*.ra=38;5;45:*.wav=38;5;45:*.axa=38;5;45:*.oga=38;5;45:*.spx=38;5;45:*.xspf=38;5;45: declare -x MAIL=/var/spool/mail/rahman declare -x MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles declare -x MODULESHOME=/usr/share/Modules declare -x OLDPWD declare -x PATH=/home/rahman/Gabedit64:/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/sware/amber/amber12/bin::/usr/local/bin/vmd::/sware/packmol/packmol::/usr/local/gromacs/bin::/usr/bin/qmake-qt4/bin/qmake:/usr/local/gaussian/g09/bsd:/usr/local/gaussian/g09/local:/usr/local/gaussian/g09/extras:/usr/local/gaussian/g09:/home/rahman/.local/bin:/home/rahman/bin:/usr/local/gaussian/g09/bsd:/usr/local/gaussian/g09/local:/usr/local/gaussian/g09/extras:/usr/local/gaussian/g09 declare -x PGI_TERM=trace,abort declare -x PWD=/home/rahman/learn4prog declare -x QTDIR=/usr/bin/qmake-qt4 declare -x QTINC=/usr/lib64/qt-3.3/include declare -x QTLIB=/usr/lib64/qt-3.3/lib declare -x QT_GRAPHICSSYSTEM_CHECKED=1 declare -x QT_IM_MODULE=ibus declare -x QT_PLUGIN_PATH=/usr/lib64/kde4/plugins:/usr/lib/kde4/plugins declare -x
Re: [CentOS] Centos 6 Sendmail backup MX Config
Karanbir Singh wrote: On 13/02/15 18:45, Valeri Galtsev wrote: So, what is the secondary MX server that you are describing that accepts everything is based on? if you actually read the thread you are replying to blindly, you might find out ? :-) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, 2015-02-13 at 10:03 -0600, Valeri Galtsev wrote: On Fri, February 13, 2015 9:05 am, Always Learning wrote: I always change the SSH port to something conspicuously different. Every server has a different and difficult to guess SSH port number with access restricted to a few IP addresses. Just to mention (even though someone already mentioned that): changing port numbers, or, say removing disclosure by the daemon what software, version, ... it is does not really add security. Security through obscurity is only considered to be efficient by Windows folks. Quite wrongfully IMHO. Changing the SSH port is the *START* of extra security (no Port 22 here) - not the end of my efforts. SSH ports are 'protected' by restricting access from and to designated IPs. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, 2015-02-13 at 11:04 -0600, Les Mikesell wrote: I'd recommend not having a secondary MX at all unless it is equipped to reject invalid users and spam in all the same ways as your primary. Otherwise it accept junk that your primary rejects and then you are obligated to send a bounce message which is always a bad thing - you want the authoritative receiver to reject at the smtp level instead of accepting at all. There's a whole category of spam where the real target is the apparent sender where a bounce will go. Also anything sending valid mail should be prepared to queue and retry on temporary failures just as well as your own secondary would. On some domains I have 3 MXs - primary, secondary and tertiary - all share exactly the same coding, configuration and reporting. Absolutely no sense is weakening security for any MX although some spammers think the highest numbered MX is the weakest ! -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-es] Bug horrible en CentOS 7 Desktop
Gracias por tu respuesta esperare a la 7.1 a ver si lo solucionan sino me rendiré y abandonare CentOS como desktop yo hago alt+f2+r y puedo estar 1h más trabajando pero no es plan Gracias por tus comentarios -- El 13/02/15 a las 17:09, Aldo Rivadeneira escribió: El error te lo manda gnome-shell, y si por lo visto es un bug reportado en fedora 19 mismo comportamiento y esto debido a un consumo alto de recursos, de igual manera la recomendacion es deshabilitar las extensiones. Lo que podrias intentar no se si exista en la version de gnome 3.x es entrar como en modo para resolver problemas. En caso de no funcionar podrias ejecutar un kill -HUP gnome-shell volver a hacer un trace para indentificar la extension. Y bueno en todo caso seria esperar a que resuelvan el bug mientras tanto podrias intentar iniciar con XFCE para que puedas continuar trabajando. Saludos! On Thu, Feb 12, 2015 at 3:43 AM, Alex ( Servtelecom ) alex.and...@servtelecom.com wrote: Hola compañeros llevo desde que salio CentOS 7 utilizando en mi Portátil ya que busco algo estable y no sufrir de verionitis Desde que salio que tengo el mismo bug que no hay manera de que se solucione, a la que llevo 1h trabajando el escritorio se vuelve inestable, se queda congelado durante varios minutos y siempre cuando más urgencia tienes en hacer algo Me estoy planteando cambiar de distro pero quiero dar una oportunidad ya que son muchos años utilizando CentOS en servidores y en mi portátil desde CentOS 6 que lo utilizo los log's que muestra mi portátil: *Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_editable: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_get_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:44 Portatil gnome-session: (gnome-shell:1814): Clutter-CRITICAL **: clutter_text_set_text: assertion `CLUTTER_IS_TEXT (self)' failed** **Feb 12 10:36:54 Portatil dbus-daemon: dbus[620]: [system] Activating via systemd: service name='net.reactivated.Fprint' unit='fprintd.service'** ** **eb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed** **Feb 12 10:37:00 Portatil gnome-session: (logview:4460): Gtk-CRITICAL **: gtk_text_buffer_insert: assertion `text != NULL' failed* Alguna idea, creéis que con la 7.1 aumentaran las versiones de tal manera que se solucione el problema?? Este problema es el mismo que mucha gente se quejaba con Fedora 19 que es la referencia que utiliza CentOS 7. Espero vuestras respuestas para poder reportar los desarrolladores de CentOS ya que mi ingles es muy malo y lo he intentado pero ni me responden ;( ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] Securing SSH wiki article outdated
On Fri, 2015-02-13 at 11:21 -0500, m.r...@5-cent.us wrote: I disagree - I am in the waste of time camp. The reality is that only script kiddies start out by trying 22 (and I *do* mean script kiddies - I've seen attempts to ssh in that were obviously from warez, man, where they were too stupid to fill in ___ with a username, or salt. All the others, I figure they don't need to be major league, just someone with a clue, who'll run a scan; in fact, I'd expect them to run a scan just to see what IPs were visible, and I know that if I was writing a scan, I don't assume that I'm *so* brilliant that I'm the only one to think of scanning ports 1k while looking for systems that I might hit. Changing SSH port to a non-standard port is the beginning. Restricting access to that port to a few IPs is another layer of protection and then more things are done to lessen the chances of unauthorised access. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-docs] [CentOS] Securing SSH wiki article outdated
Hi, Am 13.02.2015 um 09:48 schrieb Ned Slider: On 12/02/15 20:03, Warren Young wrote: Hi, just a quick note to whoever is maintaining this page: http://wiki.centos.org/HowTos/Network/SecuringSSH The procedure is missing the firewall-cmd calls necessary in EL7: firewall-cmd --add-port 2345/tcp firewall-cmd --add-port 2345/tcp --permanent added to that page. cheers Christoph -- Christoph Galuschka CentOS-QA-Team member | IRC: tigalch ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS-es] Error al momento de navegar en CENTOS 7
Hola estoy configurando mi servidor en centos 7 y ya configure todo los parametro de mi red pero no puedo navegar, pero si puedo hacer ping al 8.8.8.8 pero cuando hago ping www.google.es unknown host www.google.es ---Robin Guadalupe GoñasAsistente InformáticoUGEL San Martín - TarapotoRPM: #969829349 ___ CentOS-es mailing list CentOS-es@centos.org http://lists.centos.org/mailman/listinfo/centos-es
Re: [CentOS] Centos 6 Sendmail backup MX Config
On Fri, 2015-02-13 at 11:39 -0600, Valeri Galtsev wrote: I've seen at least at some point that google mail accepts everything. That is because Google is primarily a USA government sponsored intelligence gathering operation. It wants as much information as possible. Google's commercial activities were never originally planned. They are an unexpected, and very lucrative, bonus. -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thread moderation and list etiquette (Reference - Another Fedora Decision)
On Fri, 2015-02-13 at 18:09 +, Karanbir Singh wrote: yes, lots of irrelevant conversation on the list - and it comes from a handful of users. Its irrelevant, take it to an irrelevant venue. centos.m...@centos.org centos...@centos.org ? c...@centos.org -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS-docs] Where is the official doc for CentOS 7
Hi, I don't see the official doc for CentOS 7. Does anybody know where is it? Thanks. https://www.centos.org/docs/ -- Regards, Peng ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
[CentOS] C5 BASH IF
Being new to some aspects of BASH, I tried to reduce the quantity of
scripts by introducing a comparison test into an existing working
script.
The script refused to work until I placed [ ] around the actual test.
The second test, in the same script, misfunctioned until I removed the
[ ] around the second test.
NON WORKING first comparison
5 if $dir=law
6 then
7www=law
8dir=${file:0:5}
9 else
10www=www/s
11 fi
Error message = /root/bin/.us: line 5: law=law: command not found
-
WORKING first comparison
5 if [ $dir=law ]
6 then
7www=law
8dir=${file:0:5}
9 else
10www=www/s
11 fi
NON-WORKING second comparison
15 if [ $file='law00.css' ]
16 then
17file=$dir/$file
18echo css
19 else
20file=$dir/$file\.php
21echo no css
22 fi
23 #
Every comparison in the second test, including wrong comparisons,
satisfy the test and caused the 'css' display.
When line 15 was changed to
15 if [ $file='law00css' ]
everything continued to match including items with no 'css' in the file
name.
Baffled.
Are C5 BASH scripts restricted to only 1 IF comparison ?
--
Regards,
Paul.
England, EU. Je suis Charlie.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C5 BASH IF
On Fri, Feb 13, 2015 at 11:26 PM, Always Learning cen...@u64.u22.net wrote: Being new to some aspects of BASH, I tried to reduce the quantity of scripts by introducing a comparison test into an existing working script. The script refused to work until I placed [ ] around the actual test. The second test, in the same script, misfunctioned until I removed the [ ] around the second test. I think you are missing some very basic concepts here. First, the shell likes to parse things separated by white space. Second, [ is a synonym for test which is a build-in version of /bin/test, so try 'man test' for the syntax of tests. And third, you generally should use double quotes around variables in tests so they continue to exist as an empty string if the variable happens to not be set. -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C5 BASH IF
On Sat, 2015-02-14 at 05:26 +, Always Learning wrote: NON-WORKING second comparison 15 if [ $file='law00.css' ] 16 then 17file=$dir/$file 18echo css 19 else 20file=$dir/$file\.php 21echo no css 22 fi 23 # Every comparison in the second test, including wrong comparisons, satisfy the test and caused the 'css' display. When line 15 was changed to 15 if [ $file='law00css' ] everything continued to match including items with no 'css' in the file name. I re-ran the script with 'set -x' for 16 if [ $file='law00css' ] 17 then 18echo $file 19echo css 20 else 21echo no css 22 fi and received:- + '[' law45p07a01=law00css ']' + echo law45p07a01 law45p07a01 + echo css css -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C5 BASH IF
On Fri, 2015-02-13 at 23:46 -0600, Les Mikesell wrote: I think you are missing some very basic concepts here. First, the shell likes to parse things separated by white space. Second, [ is a synonym for test which is a build-in version of /bin/test, so try 'man test' for the syntax of tests. And third, you generally should use double quotes around variables in tests so they continue to exist as an empty string if the variable happens to not be set. Thanks for that. I assumed if test 1 worked, so would test 2. Have re-run test 2 with 16 if [ $file = law00css ] 17 then 18echo $file 19echo css 20 else 21echo no css 22 fi and got + '[' law45p07a01 = law00css ']' + echo 'no css' no css + exit which is correct (for the first time). It seems that following your good advice and plonking spaces around the = has solved the problem. Thank you very much. Now I can go to bed a satisfied person :-) -- Regards, Paul. England, EU. Je suis Charlie. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, 2015-02-13 at 18:27 -0800, PatrickD Garvey wrote: On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote: On 02/13/2015 05:41 AM, James Hogarth wrote: This is also why the Orange Book and its Rainbow kin exist (Orange Book = 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria). Should anyone care to learn from the Rainbow Books, they are available from the United States of America (USA) National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC) Selected Historical Computer Security Papers, http://csrc.nist.gov/publications/secpubs/ There is a caveat however, The Rainbow Series of Department of Defense standards is outdated, out of print, and provided here for historical purposes ONLY. I imagine the CSRC believes some of their other readily available publications are not outdated. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos Staying on the original post, there are valuable information from this thread about how to secure ssh, now which one of us are willing to update the wiki. We can include the use of two factor authentication, public key authentication, challenge response authentication, modifying the /etc/hosts.allow (I have noticed that libwarp no longer contain ssh etc... I will read up on how to contribute to the CentOS wiki and get involved with the documentation. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Securing SSH wiki article outdated
On Fri, Feb 13, 2015 at 7:12 AM, Lamar Owen lo...@pari.edu wrote: On 02/13/2015 05:41 AM, James Hogarth wrote: This is also why the Orange Book and its Rainbow kin exist (Orange Book = 5200.28-STD, aka DoD Trusted Computer System Evaluation Criteria). Should anyone care to learn from the Rainbow Books, they are available from the United States of America (USA) National Institute of Standards and Technology (NIST) Computer Security Resource Center (CSRC) Selected Historical Computer Security Papers, http://csrc.nist.gov/publications/secpubs/ There is a caveat however, The Rainbow Series of Department of Defense standards is outdated, out of print, and provided here for historical purposes ONLY. I imagine the CSRC believes some of their other readily available publications are not outdated. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
