yum remove –noautoremove openproject
[SOLVED] Denied DNS cache queries originating from 127.0.0.1
i had thi situation:
[SOLVED] Denied DNS cache queries originating from 127.0.0.1
Hi,
recently Virtualmin complained that I needed to add 127.0.0.1 to the BIND Zones.
Since then I’ve started seeing the following entries in my /var/named/data/named.run
:
13-Jan-2016 14:20:12.442 client 127.0.0.1#24778: query (cache) 'w3.org/NS/IN' denied
13-Jan-2016 14:20:12.442 client 127.0.0.1#24778: query (cache) 'comcast.net/NS/IN' denied
13-Jan-2016 14:20:12.443 client 127.0.0.1#24778: query (cache) 'akamai.com/NS/IN' denied
13-Jan-2016 14:21:03.839 client 127.0.0.1#33857: query (cache) 'cingular.com/NS/IN' denied
13-Jan-2016 14:21:03.839 client 127.0.0.1#33857: query (cache) 'kernel.org/NS/IN' denied
13-Jan-2016 14:21:03.840 client 127.0.0.1#33857: query (cache) 'gmx.net/NS/IN' denied
13-Jan-2016 19:55:38.304 client 127.0.0.1#30860: query (cache) 'sun.com/NS/IN' denied
13-Jan-2016 19:55:38.305 client 127.0.0.1#30860: query (cache) 'w3.org/NS/IN' denied
13-Jan-2016 19:55:38.307 client 127.0.0.1#30860: query (cache) 'mit.edu/NS/IN' denied
I already have the named-refused-udp
and named-refused-tcp
fail2ban jails activated, so I’m not worried about any such entries which originate from an external ip address.
What concerns me is those originating from 127.0.0.1.
Have I been hacked?
Thanks
i patch like this
I’ll answer my own question to help anyone else looking. To stop these entries add the following to /etc/named.conf
allow-query-cache { none; };
recursion no;
additional-from-auth no;
additional-from-cache no;
minimal-responses yes;
in this way:
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory “/var/named”;
dump-file “/var/named/data/cache_dump.db”;
statistics-file “/var/named/data/named_stats.txt”;
memstatistics-file “/var/named/data/named_mem_stats.txt”;
allow-query { any; };
allow-recursion {“none”;};
recursion no;
version “Not disclosed”;
allow-query-cache { none; };
additional-from-auth no;
additional-from-cache no;
minimal-responses yes;
…..
6 commands to check and list active SSH connections in Linux (connections in general)
1. Using ss command
ss
is used to dump socket statistics. It allows showing information similar to netstat
. It can display more TCP and state information than other tools. We will use grep function to only get the list of active SSH sessions on our local host
[root@node3 ~]# ss | grep -i ssh tcp ESTAB 0 0 10.0.2.32:ssh 10.0.2.31:37802 tcp ESTAB 0 64 10.0.2.32:ssh 10.0.2.2:49966 tcp ESTAB 0 0 10.0.2.32:ssh 10.0.2.30:56088
From the above example we know that there are three hosts which are currently connected to our node3. We have active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2
2. Using last command
last
searches back through the file /var/log/wtmp
(or the file designated by the -f
flag) and displays a list of all users logged in (and out) since that file was created. Names of users and tty’s can be given, in which case last will show only those entries matching the arguments.
Using this command you can also get the information about the user using which the SSH connection was created between server and client. So below we know the connection from 10.0.2.31 is done using ‘deepak‘ user, while for other two hosts, ‘root‘ user was used for connecting to node3.
[root@node3 ~]# last -a | grep -i still deepak pts/1 Fri May 31 16:58 still logged in 10.0.2.31 root pts/2 Fri May 31 16:50 still logged in 10.0.2.30 root pts/0 Fri May 31 09:17 still logged in 10.0.2.2
Here I am grepping for a string “still” to get all the patterns with “still logged in
“. So now we know we have three active SSH connections from 10.0.2.31, 10.0.2.30 and 10.0.2.2
3. Using who command
who
is used to show who is logged on on your Linux host. This tool can also give this information
[root@node3 ~]# who root pts/0 2019-05-31 09:17 (10.0.2.2) root pts/1 2019-05-31 16:47 (10.0.2.31) root pts/2 2019-05-31 16:50 (10.0.2.30)
Using this command we also get similar information as from last
command. Now you get the user details used for connecting to node3 from source host, also we have terminal information on which the session is still active.
We generally hear terminal as tty
but here we see terminal is referenced as pts
, but now:
What is the difference between tty and pts?
How to disable or enable individual tty terminal console in Linux?
4. Using w command
w
displays information about the users currently on the machine, and their processes. This gives more information than who and last command and also serves our purpose to get the list of active SSH connections. Additionally it also gives us the information of the running process on those sessions.
Using w
command you will also get the idle time details, i.e. for how long the session is idle. If the SSH session is idle for long period then it is a security breach and it is recommended that such idle SSH session must be killed, you can configure your Linux host to automatically kill such idle SSH session.
[root@node3 ~]# w 17:01:41 up 7:44, 3 users, load average: 0.00, 0.01, 0.05 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 10.0.2.2 09:17 9:41 0.31s 0.00s less -s deepak pts/1 10.0.2.31 16:58 3:06 0.03s 0.03s -bash root pts/2 10.0.2.30 16:50 5.00s 0.07s 0.02s w
5. Using netstat command
Similar to ss
we have netstat
command to show active ssh sessions. Actually we can also say that ss is the new version of netstat. Here we can see all the ESTABLISHED SSH sessions from remote hosts to our localhost node3. it is also possible that one or some of these active ssh connections are in hung state so you can configure your host to automatically disconnect or kill these hung or unresponsive ssh sessions in Linux.
[root@node3 ~]# netstat -tnpa | grep 'ESTABLISHED.*sshd' tcp 0 0 10.0.2.32:22 10.0.2.31:37806 ESTABLISHED 10295/sshd: deepak tcp 0 0 10.0.2.32:22 10.0.2.2:49966 ESTABLISHED 4329/sshd: root@pts tcp 0 0 10.0.2.32:22 10.0.2.30:56088 ESTABLISHED 10125/sshd: root@pt
6. Using ps command
Now to show active ssh sessions, ps
command may not give you accurate results like other commands we discussed in this article but it can give you some more additional information i.e. PID
of the SSHD
process which are currently active and connected.
# ps auxwww | grep sshd: | grep -v grep root 4329 0.0 0.1 154648 5512 ? Ss 09:17 0:00 sshd: root@pts/0 root 10125 0.0 0.1 154648 5532 ? Ss 16:50 0:00 sshd: root@pts/2 root 10295 0.0 0.1 154648 5480 ? Ss 16:58 0:00 sshd: deepak [priv] deepak 10301 0.0 0.0 156732 2964 ? S 16:58 0:00 sshd: deepak@pts/1
Check ssh connection history
To get the ssh connection history you can always check your SSHD logs for more information on connected or disconnected SSH session. Now the sshd log file may vary from distribution to distribution. On my RHEL 7.4 my sshd logs are stored inside /var/log/sshd
Lastly I hope the steps from the article to check active SSH connections and ssh connection history in Linux was helpful. So, let me know your suggestions and feedback using the comment section.
How to create and manage services in CentOS 7 with systemd
Directory | Description |
---|---|
/usr/lib/systemd/system/ | Unit files distributed with installed packages. Do not modify unit files in this location. |
/run/systemd/system/ | Unit files that are dynamically created at runtime. Changes in this directory are lost when rebooted. |
/etc/systemd/system/ | Unit files created by systemctl enable and custome unit files created by system administrators. |
Any custom unit files that you create should be placed in the /etc/system/system/ directory. This directory takes precedence over other directories.
Unit files names are of the form
unit_name.unit_type
Unit_type
can be one of the following:
Unit Type | Description |
---|---|
device | A device unit. |
service | A system service. |
socket | A socket for inter-process communication. |
swap | A swap file or device. |
target | A group of units. |
timer | A systemd timer. |
snapshot | A snapshot of systemd manager. |
mount | A mount point. |
slice | A group of unit that manage the system processes. |
path | A file or directory. |
automount | A automount point. |
scope | An externally created process. |
Creating a new service (systemd unit)
To create a custom service to be managed by systemd
, you create a unit file that defines the configuration of that service. To create a service named MyService
for example, you create a file named MyService.service
in /etc/systemd/system/
# vim /etc/systemd/system/MyService.service
The unit file of service consists of a set of directives that are organized in to three sections – Unit, Service and Install. Below is an example of a very simple unit file.
[Unit] Description=Service description [Service] ExecStart=path_to_executable [Install] WantedBy=default.target
Once you have created the unit file with all the necessary configuration options, save the file and set the correct file permissions.
# chmod 664 /etc/systemd/system/MyService.service
The next step is to reload all unit files to make systemd know about the new service.
# systemctl daemon-reload
Finally to start the service, run
# systemctl start MyService.service
# systemctl enable MyService.service
to enable the service to start at boot
systemctl reboot
Reboot the host to verify whether the scripts are starting as expected during system boot.
[Unit] Section
The following are the main directives that you specify in the [Unit] section.
Description | A short description of the unit. |
Documentation | A list of URIs pointing to the documentation for the unit. |
Requires | A list of units that must be started alongside the current unit. If the any these units fail to start then current unit will not be activated. |
Wants | Similar to the Requires directive but the difference is the current unit will be activated even if the depended units fail to start. |
Before | List of units that cannot be started before the current unit. |
After | The current unit can started only after the units listed here. |
Conflicts | List units that cannot be run concurrently with the current unit. |
[Service] Section
Some of the common directives that you’ll see in service section are.
Type | Defines the startup type of the unit which can be one of the values:
|
ExecStart | Specifies the command to the executed to start service. |
ExecStartPre | Specifies the command to be executed before the main process specified in the ExecStart is started. |
ExecStartPost | Specifies the command to be executed after the main process specified in the ExecStart has finished. |
ExecStop | Specifies the command to be executed when the service is stopped. |
ExecReload | Specifies the command to be executed when the service is restarted. |
Restart | Specifies when to restart the service automatically. Possible values are “always”, “on-success”, “on-failure”, “on-abnormal”, “on-abort”, or “on-watchdog”. |
[Install] Section
The [install] section provides information required to enable or disable the units using the systemctl
command. The common options are:
RequiredBy | A list of units that requires unit. A symbolic link of this unit is created in the .requires directory of the listed unit. |
WantedBy | Specifies a list of targets under which the service should be started. A symbolic link of this unit is created in the .wants directory of the listed target. |
Using systemctl to manage services
systemctl is the command line tool you can use to control and manage services in systemd. Let’s now take a look at the some of the important systemctl commands for service management.
Listing Service Units and Unit files
To list all the units that are loaded
# systemctl list-units
To list only units of type service
# systemctl list-units -t service
To list all installed unit files of type service
# systemctl list-unit-files -t service
To list all installed unit files of type service
# systemctl list-unit-files -t service
You can use the --state
option to filter the output by the state of the unit. The following command lists all services that are enabled.
# systemctl list-unit-files --state enabled
Note the difference between list-units and list-unit-files is that list-unit will only show units that are loaded while list-unit-files shows all unit files that are installed on the system.
Start and Stop service
This is quite straightforward, start option to start a service and stop option to stop a service
# systemctl start service_name.service
# systemctl stop service_name.service
Restart and Reload services
The restart option will restart a service that is running. If the service is not running, it will be started.
# systemctl restart service_name.service
If you want to restart the service only if its running then use the try-restart option.
# systemctl try-restart service_name.service
The reload option will try to reload the service specific configuration of a unit if it is supported.
# systemctl reload service_name.service
Enable and Disable services
Units can be enabled or disabled using the enable or disable options of systemctl command. When a unit a enabled symbolic links are created in various locations as specified in the [install] section of the unit file. Disabling a unit will remove the symbolic links that wer created when the unit was enabled.
# systemctl enable service_name.service
# systemctl disable service_name.service
Reload Unit Files
Whenever you make any changes to the unit files you need to let systemd know by executing daemon-reload which reloads all unit files.
# systemctl daemon-reload
Modifying system services
The unit files that come with installed packages are stored in /usr/lib/systemd/system/
. The unit files in this directory should not be modified directly as the changes will be lost when if you update the package. The recommended method is to first copy the unit file to /etc/systemd/system/
and make the changes in that location. The unit files in /etc/systemd/system/
takes precedence over unit files in /usr/lib/systemd/system/
so the original unit file will be overridden.
How email works (MTA, MDA, MUA)
As simple as it is to use, email relies on a more complicated set of operating procedures than that of the Web. For most users, its operation is transparent, which means that it is not necessary to understand how email works in order to be able to use it.
However, the short introduction below has been provided to help you to understand its basic principles, give you an idea of how to best configure your email clients, and inform you about the underlying mechanisms of spam.
How Email Works
Email is based around the use of electronic mailboxes. When an email is sent, the message is routed from server to server, all the way to the recipient’s email server. More specifically, the message is sent to the mail server tasked with transporting emails (called the MTA, for Mail Transport Agent) to the recipient’s MTA. On the Internet, MTAs communicate with one another using the protocol SMTP, and so are logically called SMTP servers (or sometimes outgoing mail servers).
The recipient’s MTA then delivers the email to the incoming mail server (called the MDA, for Mail Delivery Agent), which stores the email as it waits for the user to accept it. There are two main protocols used for retrieving email on an MDA: POP3 (Post Office Protocol), the older of the two, which is used for retrieving email and, in certain cases, leaving a copy of it on the server; and IMAP (Internet Message Access Protocol), which is used for coordinating the status of emails (read, deleted, moved) across multiple email clients. With IMAP, a copy of every message is saved on the server, so that this synchronization task can be completed.
For this reason, incoming mail servers are called POP servers or IMAP servers, depending on which protocol is used:
To keep everyone from checking other users’ emails, MDA is protected by a user name called a login and by a password.
Retrieving mail is done using a software program called an MUA (Mail User Agent). When the MUA is a program installed on the user’s system, it is called an email client (such as Mozilla Thunderbird, Microsoft Outlook, Eudora Mail, Incredimail or Lotus Notes).
When it is a web interface used for interacting with the incoming mail server, it is called webmail.
Open Relay
By default, it is not necessary to authenticate oneself to send email, which means that it is very easy to falsify one’s own address when sending mail. For this reason, nearly all Internet service providers lock down their SMTP servers so that only their subscribers can use them, or more precisely, only machines whose IP address belongs to the ISP’s domain. This explains why users must modify the outgoing server settings in their email clients each time they move to a new home or business.
When an organization’s email server is improperly configured and allows third-party users on any network to send emails, this is called an open relay. Open relays are generally used by spammers, as using them hides the true origins of their messages. As a result, many ISPs keep an up-to-date blacklist of open relays to keep subscribers from receiving messages from such servers.