NickTheGreek

4.2.7 is a maintenance release that fixes issues identified in 4.2.6 and also adds settings to help with GDPR compliance. This release also contains several security updates. Also included: 4.2.6 This is a maintenance release to fix reported bugs. Other changes include: RSS feeds now use guest page caching system Analytic tracking code has been moved to inside head tag Ad code placement has a new setting to clarify how sidebar display should be handled Various enhancements to Redis engine including data stored encrypted at rest Search result improvements

How to check Linux for Spectre and Meltdown vulnerability Posted onJanuary 8, 2018in CategoriesCentOS, Debian / Ubuntu, Linux, RedHat and Friends,Security, Suse last updated January 8, 2018 How do I check if my Linux server is still vulnerable to Spectre and Meltdown CPU bugs? Spectre & Meltdown Checker is a shell script that check for the following Intel/AMD/ARM and other CPUs for bugs: CVE-2017-5753: bounds check bypass (Spectre Variant 1). You need to recompile software and kernel with a modified compiler that introduces the LFENCE opcode at the proper positions in the resulting code. The performance impact of the mitigation is negligible. CVE-2017-5715: branch target injection (Spectre Variant 2). The performance impact of the mitigation depending on your CPU. CVE-2017-5754: rogue data cache load (Meltdown). You must install updated kernel version with PTI/KPTI patches. Updating the kernel is enough. The performance impact of the mitigation is low to medium. spectre-meltdown-checker.sh is a simple shell script to find out if your Linux kernel (installation) is vulnerable against the 3 “speculative execution” CVEs. Use this script to check or see if you are still vulnerable to Meltdown and Spectre CPU bugs after applying kernel patches. Installation The script must be run as root user. You can view source code here. Use the wget command or curl command to grab the source code on your Linux box: $ cd /tmp/ $ wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh OR $ git clone https://github.com/speed47/spectre-meltdown-checker.git Sample outputs: Cloning into 'spectre-meltdown-checker'... remote: Counting objects: 155, done. remote: Compressing objects: 100% (20/20), done. remote: Total 155 (delta 18), reused 21 (delta 10), pack-reused 125 Receiving objects: 100% (155/155), 49.78 KiB | 145.00 KiB/s, done. Resolving deltas: 100% (88/88), done. How to check Linux for Spectre and Meltdown vulnerability Run the script as root user using sudo command or su command: $ sudo sh spectre-meltdown-checker.sh Sample outputs from Ubuntu Linux desktop: [sudo] password for vivek: Spectre and Meltdown mitigation detection tool v0.16 Checking vulnerabilities against Linux 4.13.0-21-generic #24-Ubuntu SMP Mon Dec 18 17:29:16 UTC 2017 x86_64 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1' * Kernel compiled with LFENCE opcode inserted at the proper places: NO (only 42 opcodes found, should be >= 70) > STATUS: VULNERABLE CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2' * Mitigation 1 * Hardware (CPU microcode) support for mitigation: NO * Kernel support for IBRS: NO * IBRS enabled for Kernel space: NO * IBRS enabled for User space: NO * Mitigation 2 * Kernel compiled with retpoline option: NO * Kernel compiled with a retpoline-aware compiler: NO > STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability) CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3' * Kernel supports Page Table Isolation (PTI): NO * PTI enabled and active: NO > STATUS: VULNERABLE (PTI is needed to mitigate the vulnerability) Another output from my CentOS 7.x server where Meltdown/Spectre v1 was patched with Kernel: $ sudo sh spectre-meltdown-checker.sh Spectre Meltdown vulnerability mitigation detection check tool for Linux (click to enlarge) For more info see the official github page here. https://www.cyberciti.biz/faq/check-linux-server-for-spectre-meltdown-vulnerability/

http://www.zdnet.com/article/intel-starts-issuing-patches-for-meltdown-spectre-vulnerabilities/ Intel on Thursday began issuing patches for the Meltdown and Spectre vulnerabilities linked to its processors. In a press release, the Santa Clara-based tech giant said it has "developed and is rapidly issuing updates for all types of Intel-based computer systems -- including personal computers and servers -- that render those systems immune from both exploits reported by Google Project Zero." The two critical chip vulnerabilities date back more than two decades and were found to enable an attacker to steal data from the memory of running apps, such as data from password managers, browsers, emails, and photos and documents. The researchers who discovered the vulnerabilities said that "almost every system," since 1995, including computers and phones, is affected by the bug. Intel says it has already issued updates for the majority of its processor products released in the last five years. By the end of next week, the company expects to have updates for 90 percent of the past five years' processors. Additionally, Intel said that "many operating system vendors, public cloud service providers, device manufacturers and others have indicated that they have already updated their products and services." It's still unclear when Intel will have patches ready for processors that are more than five years old. Intel maintains that there are no known exploits for the vulnerabilities, but it's encouraging computer users worldwide to enable automatic updates of their operating systems and other computer software to keep their systems up-to-date.

Huge Flaws Affect Nearly Every Modern Device; Patch Could Hit CPU Performance Wednesday, January 03, 2018 Swati Khandelwal UPDATE: Researchers have finally disclosed complete technical details of two kernel side-channel attacks, Meltdown and Spectre—which affect not only Intel but also systems and devices running AMD, ARM processors—allowing attackers to steal sensitive data from the system memory. ____________ The first week of the new year has not yet been completed, and very soon a massive vulnerability is going to hit hundreds of millions of Windows, Linux, and Mac users worldwide. According to a blog post published yesterday, the core team of Linux kernel development has prepared a critical kernel update without releasing much information about the vulnerability. Multiple researchers on Twitter confirmed that Intel processors (x86-64) have a severe hardware-level issue that could allow attackers to access protected kernel memory, which primarily includes information like passwords, login keys, and files cached from disk. The security patch implements kernel page-table isolation (KPTI) to move the kernel into an entirely separate address space and keeps it protected and inaccessible from running programs and userspace, which requires an update at the operating system level. "The purpose of the series is conceptually simple: to prevent a variety of attacks by unmapping as much of the Linux kernel from the process page table while the process is running in user space, greatly hindering attempts to identify kernel virtual address ranges from unprivileged userspace code," writes Python Sweetness. It is noteworthy that installing the update will hit your system speed negatively and could bring down CPUs performance by 5 percent to 30 percent, "depending on the task and processor model." "With the page table splitting patches merged, it becomes necessary for the kernel to flush these caches every time the kernel begins executing, and every time user code resumes executing." Much details of the flaw have been kept under wraps for now, but considering its secrecy, some researchers have also speculated that a Javascript program running in a web browser can recover sensitive kernel-protected data. AMD processors are not affected by the vulnerability due to security protections that the company has in place, said Tom Lendacky, a member of the Linux OS group at AMD. "AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against," the company said. "The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault." The Linux patch that is being released for ALL x86 processors also includes AMD processors, which has also been considered insecure by the Linux mainline kernel, but AMD recommends specifically not to enable the patch for Linux. Microsoft is likely to fix the issue for its Windows operating system in an upcoming Patch Tuesday, and Apple is also likely working on a patch to address the vulnerability. https://thehackernews.com/2018/01/intel-kernel-vulnerability.html

https://meltdownattack.com/ Meltdown and Spectre Bugs in modern computers leak passwords and sensitive data. Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware bugs allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages and even business-critical documents. Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. Depending on the cloud provider's infrastructure, it might be possible to steal data from other customers. Meltdown Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system. If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown. Spectre Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

https://googleprojectzero.blogspot.gr/2018/01/reading-privileged-memory-with-side.html Tested Processors Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz (called "Intel Haswell Xeon CPU" in the rest of this document) AMD FX(tm)-8320 Eight-Core Processor (called "AMD FX CPU" in the rest of this document) AMD PRO A8-9600 R7, 10 COMPUTE CORES 4C+6G (called "AMD PRO CPU" in the rest of this document) An ARM Cortex A57 core of a Google Nexus 5x phone [6] (called "ARM Cortex A57" in the rest of this document)

Red Hat has been made aware of multiple microarchitectural (hardware) implementation issues affecting many modern microprocessors, requiring updates to the Linux kernel, virtualization-related components, and/or in combination with a microcode update. An unprivileged attacker can use these flaws to bypass conventional memory security restrictions in order to gain read access to privileged memory that would otherwise be inaccessible. There are 3 known CVEs related to this issue in combination with Intel, AMD, and ARM architectures. Additional exploits for other architectures are also known to exist. These include IBM System Z, POWER8 (Big Endian and Little Endian), and POWER9 (Little Endian). Background Information An industry-wide issue was found with the manner in which many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. All three rely upon the fact that modern high performance microprocessors implement both speculative execution, and utilize VIPT (Virtually Indexed, Physically Tagged) level 1 data caches that may become allocated with data in the kernel virtual address space during such speculation. The first two variants abuse speculative execution to perform bounds-check bypass (CVE-2017-5753), or by utilizing branch target injection (CVE-2017-5715) to cause kernel code at an address under attacker control to execute speculatively. Collectively these are known as "Spectre". Both variants rely upon the presence of a precisely-defined instruction sequence in the privileged code, as well as the fact that memory accesses may cause allocation into the microprocessor’s level 1 data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use these two flaws to read privileged memory by conducting targeted cache side-channel attacks. These variants could be used not only to cross syscall boundary (variant 1 and variant 2) but also guest/host boundary (variant 2). The third variant (CVE-2017-5754) relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. Researchers have called this exploit "Meltdown". Subsequent memory accesses may cause an allocation into the L1 data cache even when they reference otherwise inaccessible memory locations. As a result, an unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks. https://access.redhat.com/security/vulnerabilities/speculativeexecution?sc_cid=701f2000000tsLNAAY&

A critical security vulnerability has been reported in phpMyAdmin—one of the most popular applications for managing the MySQL database—which could allow remote attackers to perform dangerous database operations just by tricking administrators into clicking a link. Discovered by an Indian security researcher, Ashutosh Barot, the vulnerability is a cross-site request forgery (CSRF) attack and affects phpMyAdmin versions 4.7.x (prior to 4.7.7). Cross-site request forgery vulnerability, also known as XSRF, is an attack wherein an attacker tricks an authenticated user into executing an unwanted action. According to an advisory released by phpMyAdmin, "by deceiving a user to click on a crafted URL, it is possible to perform harmful database operations such as deleting records, dropping/truncating tables, etc." phpMyAdmin is a free and open source administration tool for MySQL and MariaDB and is widely used to manage the database for websites created with WordPress, Joomla, and many other content management platforms. Moreover, a lot of hosting providers use phpMyAdmin to offer their customers a convenient way to organize their databases. Barot has also released a video, as shown above, demonstrating how a remote attacker can make database admins unknowingly delete (DROP) an entire table from the database just by tricking them into clicking a specially crafted link. "A feature of phpMyAdmin was using a GET request and after that POST request for Database operations such as DROP TABLE table_name; GET requests must be protected against CSRF attacks. In this case, POST requests were used which were sent through URL (for bookmarking purpose may be); it was possible for an attacker to trick a database admin into clicking a button and perform a drop table database query of the attacker’s choice." Barot explains in a blog post. However, performing this attack is not simple as it may sound. To prepare a CSRF attack URL, the attacker should be aware of the name of targeted database and table. "If a user executes a query on the database by clicking insert, DROP, etc. buttons, the URL will contain database name and table name," Barot says. "This vulnerability can result in the disclosure of sensitive information as the URL is stored at various places such as browser history, SIEM logs, Firewall Logs, ISP Logs, etc." Barot reported the vulnerability to phpMyAdmin developers, who confirmed his finding and released phpMyAdmin 4.7.7 to address this issue. So administrators are highly recommended to update their installations as soon as possible. https://thehackernews.com/2018/01/phpmyadmin-hack.html

Hi, I wrote this script in order to add a line to root crontab if it does not already contain such line. The script also checks if the crontab is empty. Is there a better way to achieve this? Code: cronList=$(sudo crontab -u root -l) if [ $(echo $cronList | grep -c "@weekly /home/user/command") -eq 0 ]; then if [ -z "$cronList" ]; then echo "@weekly /home/user/command" | sudo crontab -u root - else (sudo crontab -u root -l; echo "@weekly /home/user/command" ) | sudo crontab -u root - fi fi Thank you https://ubuntuforums.org/showthread.php?t=2315654

@reboot sleep 600; find ${HOME}/my_app/check_conn.rb https://askubuntu.com/questions/490881/run-the-script-file-after-5-or-10-min-after-restarting-the-system

nice ideas @reboot sleep 60 && my_script.sh or @reboot echo /root/bin/do_the_stuff | at now + 2 minutes # at assigns it an execution time truncated to whole minutes, # so this means it will execute in 1--2 minutes. https://unix.stackexchange.com/questions/57852/crontab-job-start-1-min-after-reboot

http://www.shopdeluxe.fr/check_ps/index.php

http://runprestashop.com/ Does Website X Run Prestashop?

How to configure PrestaShop to work with another domain PrestaShop, like many other applications out there is domain name dependent. In case you wish to use your PrestaShop with a different domain name you should follow the instructions below: For PrestaShop 1.4.x or the older versions: Access phpMyAdmin in cPanel and navigate to your PrestaShop database. Select the configuration table (e.g. ps_configuration) and find the PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL records. Change their values to match your new domain name. You should also make sure that your PrestaShop's base directory is correctly set in the application's configuration file located under /config/settings.inc.php. You can edit the configuration file via FTP, or File Manager in cPanel. Once you have opened the file for editing look for the line: define('__PS_BASE_URI__', '/'); In case your PrestaShop installation is located in the web root folder of your domain name, this line should remain as above. If the installation is located into a sub folder, the line should be changed to reflect its location: define('__PS_BASE_URI__', '/subfolder/'); Where subfolder is the actual name of the folder where PrestaShop is installed. For PrestaShop 1.5.x: The only thing that you need to do is to change the shop URL from the database of your application. In order to do that you will need to: Log into cPanel and access phpMyAdmin. Locate the table shop_url and change the values for the records: domain and domain_ssl to your new domain name. Then change the value of the record physical_url in the same table. If you have installed the PrestaShop directly in the domain's document root, you will need to change the physical_url to " / ". If Prestashop is installed in a sub folder, the value of physical_url should be the sub folder's name. Example: For PrestaShop installed in http://yourdomain.com/subfolder the records should be: domain = yourdomain.com domain_ssl = yourdomain.com physical_url = /subfolder/ For PrestaShop 1.6.x/1.7.x: Log into cPanel and go to phpMyAdmin. Navigate to your PrestaShop database and open the configuration table (e.g. ps_configuration). Find the PS_SHOP_DOMAIN and PS_SHOP_DOMAIN_SSL records and change their values to match your new domain name. Then open the shop_url table (e.g. ps_shop_url) and change the domain, domain_ssl and physical_uri columns to match the new location of the application. Remove all the files inside the folders cache/smarty/compile/ and cache/smarty/cache/, except the index.php files situated there. You can do that easily via FTP. Log into your PrestaShop admin panel on new domain and verify if everything is working properly - browse through all pages, products, images and themes, etc. In case you need to modify the MySQL database details of your PrestaShop you can do that in the following database configuration files located in the root folder of your PrestaShop installation: PrestaShop 1.4.x/1.5.x/1.6.x - config/settings.inc.php PrestaShop 1.7.x - app/config/parameters.php

The Psychology Behind Why Websites Get Hacked November 12, 2014Joseph Herbrandson It’s an everyday conversation for security professionals that interact with new customers. The one where we have to explain that just because everything seems fine, doesn’t mean that the best security practices shouldn’t be followed, or that being safe so far doesn’t grant future invincibility. The question, “Why should I worry?” is heard so much, that our own fear for those who ask it has made us realize we are watching online business owners play out in traffic on a virtual highway, somehow believing they will never get hit. The Truth: You Should Worry. The psychology behind why you are getting hacked is because you AREN’T worried. In the 90’s, if you were among those first using email in the mainstream, you will remember that it was important to be worried about opening emails with strange attachments. Like cavemen wondering whether they should fear the rustling grass, some of us were gobbled up by tigers lurking in our inboxes when we chose to proceed, and clicked without caution. Those getting hacked are the next generation of those beaten by email worms and viruses. Fast-forward to the present day. A business that has just started making sales is more satisfied with the projected analytic data than dissatisfied with the lack of a security review or policy pertaining to its website. For that, it may soon be punished in a rise to success cut short by a brand destroying malware infection. The Reason? More specifically than not being worried, business owners didn’t understand the environment. Rustling grass was dismissed as just the wind, and not a hungry tiger. Cries to implement security practices and build a secure infrastructure on bricks rather than straw, fell on deaf ears. This is a very common start to a story about the hurdles businesses face in information security issues, and it often carries a theme of simply neglecting to understand. To operate in a world where you don’t fully know all of the details about an environment is dangerous enough. To charge forward unknowing of the dangers is an unfortunate re-occurrence among users using technology to achieve their goals. The mindsets we’ve taken to protect us in life do not translate well to the web, and we see our websites as objects controlled only by us, and inherently protected from others, just because we never told anybody the password. My home has never been burglarized, I still lock my doors. The mentality of a security professional is not a baseline, since it’s not the norm to want complete security in every aspect of existence. No matter what I’m securing, I see the initial layout of what needs to be protected and I go the extents required to secure an environment. It’s not expected that everyone will take every measure possible, but above all else, and no matter what, I lock my doors when I leave my home, and would hope that this is everybody else’s rule as well. Surprisingly, denizens of cyberspace figuratively leave the doors of their business wide open for months at a time on busy digital street-fronts, frequented by malware-wielding thugs and gangsters. Their reasoning usually goes along the lines of, “Well I’ve never been hacked before”. The flipside is awareness. On a website, on a webserver, owned by a far-away hosting company, in a datacenter across the country, do you even know how to lock the doors? A high-density apartment complex brings about a far different scenario than a large industrial compound. There are differing levels of security required depending on value and space, along with all of the possible vulnerabilities in the establishment itself. It’s not hard to find people to agree on a good physical security policy. The psychology in the material world is that there are things to protect from other people taking or damaging, and therefore easier to make good habits in environmental awareness. Awareness: Address Uncertainty The psychology surrounding security in the digital world is a stark contrast to that in our physical realm. With malicious web activity up around the globe, corporate attacks, identity thefts and website infections continue to rise. At the same time, new users flock to the online frontier in the Internet’s ongoing modern-day gold-rush. These users, like historic pioneers to a new land, often arrive with no clue of what to expect. They find themselves learning concepts and technologies that have only recently come into existence, and education can be sparse to newcomers. Push a user through this scenario to the point where hosting is actually purchased, a site is actually developed, and consistent sales are actually made, and the result will quite possibly be a success story marred with a horrible security incident. The general psychology of how and why we come online is completely contrary to the attitude held by those that know the dangers that lie beneath the surface. How Do You Become More Security-Minded? You can completely change your state of security by understanding three basic concepts: 1. You are a target . Simply existing on the Internet puts a bullseye on your chest for hackers to use automated networks of malicious scripts and services to poke and prod at your website until it finds a way past the front door. Remember that just having a website online is opening up a connection on a system you own or rent to the wilds of the web, and all the types of traffic that come with it. 2. Awareness is everything . Understanding the infrastructure of your website, the type of server you run on, and all of the supplemental add-ons and services you use is the entry-level standard to being able to provide security for yourself when working on the Internet. 3. Security is an essential department . Fail to build an administration, and you won’t have leadership to get your business started. Ignore marketing, and no one will show up when you open the doors. Shy away from customers seeking quality service, and lack of loyalty will destroy you. These ‘departments’ are never ignored, but security often is. Make security an essential role in your environment, or your peril will be intruders betraying you from the inside when you least expect it. Most people grasp that it’s important to prevent nefarious persons from taking or doing harm to their stuff. However, modern society has interwoven a complex system of technology into a new way of life that has given the masses an excuse-driven frame of mind to hide behind in that we simply don’t have the comprehension or even the drive to try to understand the unknown. Safety is an Epiphany Away Watch the grass grow and grow impatient. Forget to maintain it and learn quickly that lack of maintenance brings more work than the maintenance itself. It can take a long time to learn this lesson in website security though, as pest infestations from wild tall grass are much easier to detect than malware infections contained within hundreds of files of thousands of lines of code. Understand a final concept: Security as an eternal struggle, a process that is kept up each and every day. It cycles through protecting yourself and your space, detecting problems and vulnerabilities, and responding to those issues. Best practices and maintenance principles prop this system up work soundly, but it requires an operator. Be an aware target that maintains the division keeping your site’s functionality safe: the Security Department. Change your psychology to stop getting hacked. https://blog.sucuri.net/2014/11/the-psychology-behind-why-websites-get-hacked.html

Microsoft SQL Server is a relational database management system developed by Microsoft. As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications which may run either on the same computer or on another computer across a network (including the Internet). In order to enable PHP MSSQL Extension, There are few modules need to be installed before you enable MSSQL Extension for PHP on server. a) Txt2man b) unixODBC c) freeTDS d) PHP mssql.so Step1: Download FreeTDS #wget http://ibiblio.org/pub/Linux/ALPHA/freetds/stable/freetds-stable.tgz Step2: Extract the downloaded file #tar zfvx freetds-stable.tgz Step3: Install it using the below commands #cd freetds-*; #./configure --prefix=/usr/local/freetds --with-tdsver=8.0 --enable-msdblib --enable-dbmfix --with-gnu-ld; make ; make install Step4: Add the compile flag for freetds to /var/cpanel/easy/apache/rawopts/all_php5 In this version, PHP 5 is the focus hence that specific file. Add the following: #echo "--with-mssql=/usr/local/freetds" >> /var/cpanel/easy/apache/rawopts/all_php5 *If you are using other Builds of Apache or PHP you may refer to the following for the correct file to edit instead of /var/cpanel/easy/apache/rawopts/all_php5 such as the case here. * Apache 1.3.x - /var/cpanel/easy/apache/rawopts/Apache1 * Apache 2.0.x - /var/cpanel/easy/apache/rawopts/Apache2 * Apache 2.2.x - /var/cpanel/easy/apache/rawopts/Apache2_2 * All PHP 4.x versions - /var/cpanel/easy/apache/rawopts/all_php4 * All PHP 5.x versions - /var/cpanel/easy/apache/rawopts/all_php5 * Mod_suPHP - /var/cpanel/easy/apache/rawopts/all_suphp * Specific PHP Version - /var/cpanel/easy/apache/rawopts/PHP-X.X.X Step5: Touch the following files as these are what are checked for by PHP. The following error will result if they are not in place. configure: error: Directory /usr/local/freetds is not a FreeTDS installation directory Here are the files to create for PHP's conditional check: #touch /usr/local/freetds/lib/libtds.a #touch /usr/local/freetds/include/tds.hp Step6: Now run Easy Apache and make sure that Mysql, Mysql of the system, amd Mysqli are all selected. Step7: Simply build. #/scripts/easyapache Note: If running a 64bit OS and get an error about configure: error: Could not find /usr/local/freetds/lib64/libsybdb.a|so you'll need to link a directory. In this example it was an easy fix. #cd /usr/local/freetds/ #ln -s /usr/local/freetds/lib lib64 #ll /usr/local/freetds/lib64/libsybdb.a #ll /usr/local/freetds/lib64/libsybdb.so #/scripts/easyapache http://techies-world.com/mssql-cpanel/

Τα SSL Certificates, εκτός από μέσο ασφαλείας και κρυπτογράφησης δεδομένων, αποτελούν συμβόλαια αστικής ευθύνης προς τρίτους, στην περίπτωση προσβολής/ζημιών τους από απώλεια/κλοπή δεδομένων (όπως τραπεζικά στοιχεία, πιστωτικές κάρτες) μέσα από τις ιστοσελίδες σας. Με απλά λόγια, αν μέσα από ασφαλές περιβάλλον, προστατευμένο από ένα συγκεκριμένο SSL, πραγματοποιηθεί hacking της σύνδεσης και απώλεια δεδομένων του πελάτη, η εκδούσα αρχή οφείλει να καταβάλει την εγγύηση του αρχικού ποσού ασφάλισης στον πελάτη. Για το λόγο αυτό, πραγματοποιείται η διαδικασία νομιμοποίησης ιδιοκτησίας ενός domain name και επιβεβαιώνεται επίσης το δικαίωμα χρήσης ενός domain από τον αιτούντα για SSL certificate. Εκτός των χαρακτηριστικών των DV (Domain Validation) SSL, που εκδίδονται εντός λεπτών και πραγματοποιούν αποκλειστικά επιβεβαίωση κρυπτογράφησης και ασφαλούς σύνδεσης, ένα OV (Business/Organization Validation) ή EV (Extended Validation) SSL αποτελεί επιπλέον τεκμηρίωση εταιρικής πιστότητας, ιδιοκτησίας ενός website και δικαιώματος χρήσης ενός domain από το διαχειριστή της ιστοσελίδας. Η διαφοροποίηση των πιστοποιητικών μεταξύ τους αφορά στο διεθνές κύρος και στις πιστοποιήσεις της εκδούσας αρχής, στο ποσό ασφάλισης προς τρίτους, στη συμβατότητα με συσκευές/browsers (παλαιότερες αρχές πιστοποίησης έχουν γνωστότερα σε παλιές συσκευές πιστοποιητικά επικύρωσης και θα εμφανίζουν ασφαλή σύνδεση σχεδόν παντού) και στην ταχύτητα των servers αποκρυπτογράφησης και πιστοποίησης (OCSP). Μια σελίδα με μεγάλη κίνηση θα πρέπει να έχει πιστοποιητικό σε ταχύτερους servers καλύτερου δικτύου, καθώς η ταχύτητα της ιστοσελίδας θα επηρεάζεται μέσα από τα OCSP ή άλλα απαιτούμενα connections. Η διαδικασία νομιμοποίησης είναι όμοια που ακολουθείται στον τραπεζικό τομέα. 1. Πρέπει να επιβεβαιωθεί ότι η μια εταιρεία είναι υπαρκτή, νόμιμη και ενεργή. Τα έντυπα που επιβεβαιώνουν κάτι τέτοιο μπορούν να είναι κάποια από τα παρακάτω: - Certificate of Incorporation (πιστοποιητικό/βεβαίωση έναρξης) - Certificate of Good Stance (ενημερότητα/βεβαίωση λειτουργίας χωρίς φορολογικές εκκρεμότητες) - Partial Bank Statements (μέρος αποδεικτικού τράπεζας με τραπεζικές κινήσεις λογαριασμού της εταιρείας) - Αντίγραφο Κινήσεων Δεύτερου Τραπεζικού Λογαριασμού είναι επίσης βοηθητικό για την έγκριση του αιτήματος - VIES Προβολή του VAT Number της εταιρείας για εταιρείες στην Ευρωπαϊκή Ένωση - Προβολή σελίδας έγκριτης εταιρείας καταλόγου και καταγραφής στοιχείων εταιρειών, όπως το DUNS 2. Σε πολλές περιπτώσεις πρέπει να βεβαιωθεί η έδρα μιας επιχείρησης καθώς μέσω των παρακάτω εντύπων: - Certificate of Address (κατά την έναρξη της εταιρείας ή την αλλαγή έδρας) - Declaration of Compliance (υπογεγραμμένο ότι καταχωρήθηκε από την εκάστοτε κρατική αρχή) 3. Θα πρέπει να βεβαιωθεί ότι το τηλέφωνο επικοινωνίας ανήκει στον αιτούντα για SSL, ο αιτών έχει πρόσβαση σε αυτό και το τηλέφωνο είναι στο όνομα της εταιρείας. Αυτό μπορεί να βεβαιωθεί με τα παρακάτω έντυπα: - βεβαίωση της εταιρείας παροχής τηλεφωνίας για την ιδιοκτησία - αντίγραφο λογαριασμού για τη χρήση του τηλεφωνικού αριθμού, κατά προτίμηση από δημόσια εταιρεία τηλεπικοινωνιών 4. Για την επιβεβαίωση του domain name, θα πρέπει να συμπεριληφθεί στα έντυπα μια βεβαίωση του καταχωρητή του domain για την επαφή ιδιοκτησίας. Η εκδούσα αρχή θα επιβεβαιώσει μέσα από whois servers ποιος είναι ο επίσημος καταχωρητής για το domain και μπορεί να ζητήσει επιπλέον τεκμηρίωση ότι αυτός ο καταχωρητής στέλνει τη βεβαίωση. Σε περίπτωση κύριων domain extensions της ICANN (όπως για παράδειγμα τα com, net, org), είναι βοηθητική η μη απόκρυψη των στοιχείων ιδιοκτησίας μέσα από το whois (απενεργοποίηση πιθανής προστασίας προβολής στοιχείων ιδιοκτήτη). 5. Ο αιτών πρέπει να είναι το πρόσωπο το οποίο δηλώνει ότι είναι και να βεβαιωθεί η τοποθεσία του/τόπος διαμονής. Αυτό μπορεί να γίνει με: - Ενεργή Ταυτότητα ή Διαβατήριο κατά προτίμηση - Άδεια Οδήγησης - Λογαριασμό στο όνομά του για κατανάλωση ρεύματος οικίας ή τηλεπικοινωνιών, κατά προτίμηση από δημόσια υπηρεσία 6. Θα πρέπει να επιβεβαιωθεί ότι ο αιτών για το SSL έχει δικαίωμα αίτησης και χρήσης του site. Αυτό μπορεί να επιβεβαιωθεί με τα έντυπα: - Board of Directors (βεβαίωση των διαχειριστών), στην περίπτωση που ο αιτών είναι διαχειριστής της εταιρείας - Power of Attorney (πληρεξούσιο), στην περίπτωση που ο αιτών δεν είναι διαχειριστής, θα πρέπει να έχει apostilled (εγκεκριμένο με συμβολαιογραφική πράξη) πληρεξούσιο που του επιτρέπει την αίτηση έκδοσης πιστοποιητικών SSL καθώς και οποιαδήποτε ενέργεια χρήσης της συγκεκριμμένης ιστοσελίδας της εταιρείας. Το πληρεξούσιο θα πρέπει να επιτρέπει την αίτηση έκδοσης, την έκδοση, την ανανέωση και τη διαγραφή (revocation) οποιουδήποτε SSL. - Καταστατικό εταιρείας που βεβαιώνει ότι έχει τα παραπάνω δικαιώματα σχετικά με τα SSL και τη χρήση/διαχείριση της εταιρικής ιστοσελίδας 7. Στην περίπτωση Extended Validation Certificates (EV), η διαδικασία νομιμοποίησης θα πρέπει να πραγματοποιηθεί και από τρίτο νομικό πρόσωπο, όπως μια δικηγορική επιχείρηση, ένα συμβολαιογραφικό γραφείο ή ένα κρατικό οργανισμό. Η εκδούσα αρχή του SSL θα αναζητήσει τη νομιμότητα των ατόμων που πραγματοποιούν τη νομιμοποίηση μέσα από επικοινωνία για επικύρωση των αριθμών μητρώου του δικηγορικού η συμβολαιογραφικού συλλόγου για παράδειγμα. Σημειώσεις - Η αποστολή των απαιτούμενων εγγράφων και η ανταλλαγή μηνυμάτων για τη νομιμοποίηση πραγματοποιείται αποκλειστικά μεταξύ αιτούντα και εκδούσας αρχής. Η angellight Services Ltd δεν έχει δικαίωμα, δε θα διαβιβάσει πληροφορίες και έντυπα, δε θα εκπροσωπήσει και δεν έχει καμία απολύτως ευθύνη για τη διαδικασία αποδοχής ή απόρριψης ενός πιστοποιητικού. Σε περίπτωση απόρριψης, θα πραγματοποιηθεί πλήρης επιστροφή χρημάτων. - Ιδίως σε περιπτώσεις extended validation, τα έντυπα θα πρέπει να είναι γραμμένα ή επίσημα μεταφρασμένα στα Αγγλικά από το αντίστοιχο υπουργείο, από δικηγόρο ή συμβολαιογράφο. - Μετά την αίτηση έκδοσης του πιστοποιητικού, στο δηλωμένο eMail του πελάτη θα γνωστοποιηθεί από την εκδούσα αρχή η διεύθυνση eMail στην οποία πρέπει να αποσταλούν όλα τα έντυπα συμπεριλαμβάνοντας τον αριθμό παραγγελίας της εκδούσας αρχής (συμπεριλαμβάνεται στο μήνυμα επιβεβαίωσης της εκδούσας αρχής). Σημειώνουμε ότι ο αριθμός παραγγελίας αυτός δεν είναι ο αριθμός παραγγελίας προς την angellight Services Ltd. - Η εκδούσα αρχή φέρει κάθε δικαίωμα απόρριψης ενός αιτήματος χωρίς ακριβή δικαιολόγηση της απόρριψης. - Προφανώς η εκάστοτε εκδούσα αρχή υποστηρίζεται από ασφαλιστικές εταιρείες οι οποίες πραγματοποιούν νομιμοποίηση παράλληλα για το κάθε αίτημα. Καθώς τα ποσά εγγύησης είναι μεγάλα, θα πρέπει να υπάρχει κατανόηση ως προς το σύνθετο της διαδικασίας και για το λόγο αυτό προτείνουμε την έκδοση OV ή EV πιστοποιητικών με τη μέγιστη διαθέσιμη περίοδο ανανέωσης (2 χρόνια συνήθως). - Ένα SSL μπορεί να χρησιμοποιηθεί για πιστοποίηση ενός website (DV, OV, EV), ενός eMail (Digital ID) ή ενός λογισμικού (Code Signing). Αυτός είναι ένας επιπλέον παράγοντας διαφοροποίησης των προϊόντων SSL. Michael Pavlides - Software Engineer, Research & Development Analyst https://www.linkedin.com/in/michael-pavlides-0511926b/ https://angellight.com

You may 1, remove the Email address from your cron file, /var/spool/cron/<username> (cPanel) 2, append ">/dev/null 2>&1" to ever cronjobs, so that no output will be generated, and hence no Email. http://www.webhostingtalk.com/showthread.php?t=1591674

Question sent in by Howard from Pasadena: Q: I have some cron jobs that run overnight on my Linux systems. Each of these jobs output information to a text file if I ever need to review. Some are written to send emails via the mail command. But since I put these scripts on a new system and added them to crontab, I am getting an email for each job that runs. There are too maybe emails being sent to root. Is there a way to stop this behavior? A: Crond typically sends an email when a cron job is run. It uses the MAILTO variable in /etc/crontab to determine who receives the email, by default this is root. There are several ways to stop this behavior. 1. Change the MAILTO variable to blank. You can edit the /etc/crontab file and change the MAILTO variable to the following: MAILTO="" This will effectively disable all emails from the cron daemon. You can then decide from within the script to send mail using the mailx command or the command of your choice. This is not my preferred method as I like to receive an email when there is an error with the cronjob. 2. Redirect STDOUT and STDERR to null to suppress output. By suppressing output of the script, there will be nothing for crond to send. Add the following to the crontab entry to send all output (STDERR and STDOUT) to the /dev/null. >/dev/null 2>&1 For example: 0 5 * * * /example/script >/dev/null 2>&1 This also has it's drawbacks as you will be suppressing any errors that may be helpful to debug problems with the script. 3. Configure crond to send the script output to the system log, and disable sending mail of output. You can configure crond by editing the /etc/sysconfig/crond file and changing the CRONDARGS line. Adding the "-s" argument will send the output to the system log, and adding the "-m off" argument will disable crond from sending emails of the job output. For example: [root@centos7 ~]# cat /etc/sysconfig/crond # Settings for the CRON daemon. # CRONDARGS= : any extra command-line startup arguments for crond CRONDARGS=-s -m off You will have to restart the crond service to read the new arguments: systemctl restart crond.service Any of the above methods will work for completely suppressing emails from cron daemon when jobs run. This is not ideal in my mind as I would like to be notified if errors occur in my cron jobs. I prefer to either write my scripts to produce no output (no standard output-but still output errors), or redirect STDOUT only to /dev/null. This will cause crond to ONLY send an email if an error has occurred. Example of only redirecting STDOUT only: 0 5 * * * /example/script > /dev/null http://www.putorius.net/2015/03/stop-cron-daemon-from-sending-email-for.html

Run nmap -sV <hostname/ip> - which is nmap with service detection, meaning it works out what's actually listening on the port, rather than guessing the service based on the port it's using. This will give you output that looks something like: PORT STATE SERVICE VERSION 666/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu4 (protocol 2.0) If it still doesn't find the port, run nmap -p- -sV <hostname/IP> - this will scan all 65k ports - it's slower, but it will find it if it's running on a high up port https://superuser.com/questions/152877/figure-out-non-standard-ssh-port

IPS Community Suite 4.2.6 Released 11/08/2017 Key Changes This is a maintenance release to fix reported bugs. Other changes include: RSS feeds now use guest page caching system Analytic tracking code has been moved to inside head tag Ad code placement has a new setting to clarify how sidebar display should be handled Various enhancements to Redis engine including data stored encrypted at rest Search result improvements

What is Gzip compression? Gzip is a method of compressing files (making them smaller) for faster network transfers. It is also a file format. Compression allows your web server to provide smaller file sizes which load faster for your website users. Enabling gzip compression is a standard practice. If you are not using it for some reason, your webpages are likely slower than your competitors. How to enable Gzip compression Compression is enabled via webserver configuration Different web servers have different instructions (explained below) Here are the most common ways to enable compression including .htaccess, Apache, Nginx, and Litespeed webservers. Enable compression via .htaccess For most people reading this, compression is enabled by adding some code to a file called .htaccess on their web host/server. This means going to the file manager (or wherever you go to add or upload files) on your webhost. The .htaccess file controls many important things for your site. If you are not familiar with the .htaccess file, please read my working with .htaccess article to get some know how before changing it. The code below should be added to your .htaccess file... <ifModule mod_gzip.c> mod_gzip_on Yes mod_gzip_dechunk Yes mod_gzip_item_include file .(html?|txt|css|js|php|pl)$ mod_gzip_item_include handler ^cgi-script$ mod_gzip_item_include mime ^text/.* mod_gzip_item_include mime ^application/x-javascript.* mod_gzip_item_exclude mime ^image/.* mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.* </ifModule> Save the .htaccess file and then refresh your webpage. Check to see if your compression is working using the Gzip compression tool. Enable compression on Apache webservers The instructions and code above will work on Apache. If they are not working there is another way that may work for you. If the above code did not seem to work, remove it from your .htaccess file and try this one instead... AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript Enable compression on NGINX webservers To enable compression in NGINX you will need to add the following code to your config file gzip on; gzip_comp_level 2; gzip_http_version 1.0; gzip_proxied any; gzip_min_length 1100; gzip_buffers 16 8k; gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript; # Disable for IE < 6 because there are some known problems gzip_disable "MSIE [1-6].(?!.*SV1)"; # Add a vary header for downstream proxies to avoid sending cached gzipped files to IE6 gzip_vary on; Enable compression on Litespeed webservers The ideal way to enable compression in Litespeed is to do it through the configuration under "tuning". Just go down to "enable compression" and check to see if it is on, if not click "edit" then choose to turn it on. While you are there, look over the several Gzip options that are nearby. How effective is gzip compression? Compression of your HTML and CSS files with gzip typically saves around fifty to seventy percent of the file size. This means that it takes less time to load your pages, and less bandwidth is used over all. How compressed files work on the web When a request is made by a browser for a page from your site your webserver returns the smaller compressed file if the browser indicates that it understands the compression. All modern browsers understand and accept compressed files. Testing compression To see if gzip compression is working use our gzip compression tool. Also consider using the page speed tool which will test compression and many other factors. https://varvy.com/pagespeed/enable-compression.html