Linux System Archives - Page 3 of 15 - Linux Tutorial and something else.....

Introduction

In the earlier tutorials, you learned how to install and configure Postfix. But, despite doing the correct setup of Postfix and having correct MX, A and PTR record your emails might be getting flagged as spam by few of the major ISPs like Gmail, Outlook. So, in this tutorial, you will learn how to further improve email delivery to the recipient’s inbox by setting up SPF and DKIM on your server.

What are these SPF and DKIM records all about?

SPF (Sender Policy Framework) is a simple email validation system designed to detect email spoofing. It is an authentication protocol which, when used allows senders to specify which IP addresses are authorized to send emails on behalf of a particular domain. To ensure that your customers and brand are protected from phishing and spoofing attacks, you need to authenticate your email with an SPF record.

DKIM is the acronym for DomainKeys Identified Mail. It is an authentication protocol used to validate sending domain names with email messages. DKIM uses cryptographic authentication by inserting a digital signature into the email message header which is later verified by the receiving host to validate the authenticity of the sender’s domain. The DKIM digital signature is created using a unique string of characters encrypted as the public key and stored in your DNS. When a recipient gets your email signed by DKIM, the public key is retrieved from the DNS Records of the sender and is decrypted to authenticate the sender’s domain.

Setup SPF Record

Step 1: Create An SPF Record In DNS Of Your Sender Domain

If you are using example.com as the From/Sender domain in all your emails going through Postfix, then this is the domain for which you have to actually set up the SPF record. And, SPF record can be easily set up by login into your DNS provider, e.g. Godaddy, Namecheap.

Mechanisms can be used to describe the set of hosts which are designated outbound mailers for the domain and can be prefixed with one of four qualifiers:

+ (Pass)
– (Fail)
~ (SoftFail)
? (Neutral)

If a mechanism results in a hit, its qualifier value is used. The default qualifier is “+“, i.e. “Pass”. Mechanisms are evaluated in order. If no mechanism or modifier matches, the default result is “Neutral”.

More in-depth information on the differences between “~” and “–” can be found here

Examples:

“v=spf1 -all”

“v=spf1 a -all”

“v=spf1 a mx -all”

“v=spf1 +a +mx -all”

Evaluation of an SPF record can return any of these results:

*Result*	*Explanation*	*Intended action*
Pass	The SPF record designates the host to be allowed to send	accept
Fail	The SPF record has designated the host as NOT being allowed to send	reject
SoftFail	The SPF record has designated the host as NOT being allowed to send but is in transition	accept but mark
Neutral	The SPF record specifies explicitly that nothing can be said about validity	accept
None	The domain does not have an SPF record or the SPF record does not evaluate to a result	accept
PermError	A permanent error has occurred (eg. badly formatted SPF record)	unspecified
TempError	A transient error has occurred	accept or reject

Once you are logged in, just create a new TXT record like the one below:

TXT  @  v=spf1 mx ~all

Note, there might be a few DNS providers, who will require you to enclose the SPF record with quotes, like the one below:

TXT  @  "v=spf1 mx ~all"

Once you have added the SPF records, it might take up to 24-48 hrs to propagate globally over the internet. You can use the dig command to see the current SPF record which is updated globally:

dig example.com TXT

Or you can also use online SPF validators like mxtoolbox.com, Kitterman.com or spf.myisp.ch

Out of the above online SPF validators, spf.myisp.ch is quite useful because it gives a very detailed view of what all servers/IP addresses are allowed to send emails for your domain.

Step 2: Configuring SPF Policy Agent On Server

By setting up the SPF record for your domain, you have completed a very important step to improve the delivery of outgoing emails to recipient’s inbox. Like the way you did the SPF configuration for outgoing emails, the very same way you should also do the SPF validation for the incoming emails. This will help you to detect the forged incoming emails coming in your network.

First, install the required package for SPF policy agent

sudo apt install postfix-policyd-spf-python

The next step is to edit the postfix’s master file master.cf. You can use any of your favourite editor vim or nano to edit the file:

sudo nano /etc/postfix/master.cf

Append the following lines at the EOF. This will tell the postfix to start the SPF policy daemon whenever postfix starts itself.

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

Save and close the file. Next step is to edit the postfix’s main configuration file main.cf.

sudo nano /etc/postfix/main.cf

Add the following lines at the end of the file main.cf. Adding these lines means, you are giving the instructions to postfix to check SPF on incoming emails and reject the emails which are unauthorized.

policyd-spf_time_limit = 3600
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_policy_service unix:private/policyd-spf

Save and close the file. You are now done with the SPF setup, just restart the postfix to reflect the changes.

sudo service postfix restart

sudo systemctl restart postfix

How to see whether the emails which you sent to Gmail are SPF passed?

Open any of the email sent via your postfix to Gmail and click on Show original link as shown below:

Next, you will see a window like the one below, where you will see the status of SPF (whether Pass or Fail) in Gmail.

If you see the below line, then this means SPF is pass:

Received-SPF: Pass (sender SPF authorized)

Setting up DKIM

DKIM can be set up by installing OpenDKIM- an open-source package for setting up DKIM.

sudo apt install opendkim opendkim-tools

Once the installation is successful, you need to add postfix user to opendkim group. By doing this, you are actually linking DKIM with your Postfix installation:

sudo gpasswd -a postfix opendkim

Next step is to edit the main configuration file of the OpenDKIM:

sudo nano /etc/opendkim.conf

Change the below-highlighted content in the main configuration:

# This is a basic configuration that can easily be adapted to suit a standard
# installation. For more advanced options, see opendkim.conf(5) and/or
# /usr/share/doc/opendkim/examples/opendkim.conf.sample.

# Log to syslog
Syslog          yes
# Required to use local socket with MTAs that access the socket as a non-
# privileged user (e.g. Postfix)
UMask           002

# Sign for example.com with key in /etc/mail/dkim.key using
# selector '2007' (e.g. 2007._domainkey.example.com)
#Domain         example.com
#KeyFile        /etc/mail/dkim.key
#Selector       2007

# Commonly-used options; the commented-out versions show the defaults.
Canonicalization  relaxed/simple
Mode            sv
SubDomains      no
#ADSPAction             continue
AutoRestart       yes
AutoRestartRate         10/1M
Background          yes
DNSTimeout          5
SignatureAlgorithm      rsa-sha256

# Always oversign From (sign using actual From and a null From to prevent
# malicious signatures header fields (From and/or others) between the signer
# and the verifier.  From is oversigned by default in the Debian pacakge
# because it is often the identity key used by reputation systems and thus
# somewhat security sensitive.
OversignHeaders     From

# List domains to use for RFC 6541 DKIM Authorized Third-Party Signatures
# (ATPS) (experimental)

#ATPSDomains        example.com

#OpenDKIM user
# Remember to add user postfix to group opendkim
UserID                 opendkim

# Map domains in From addresses to keys used to sign messages
KeyTable            refile:/etc/opendkim/key.table
SigningTable        refile:/etc/opendkim/signing.table

# Hosts to ignore when verifying signatures
ExternalIgnoreList  /etc/opendkim/trusted.hosts

# A set of internal hosts whose mail should be signed
InternalHosts /etc/opendkim/trusted.hosts

Once changes are done, save and close the file.

Create Signing Table

In order to create the signing table, you need to first create a directory structure for OpenDKIM. Execute the following commands to configure the same:

sudo mkdir /etc/opendkim
sudo mkdir /etc/opendkim/keys

Change the permission and role:

sudo chown -R opendkim:opendkim /etc/opendkim
sudo chmod go-rw /etc/opendkim/keys

Execute the following command to create the signing table:

sudo nano /etc/opendkim/signing.table

then add the following lines in the above file:

*@your-domain.com    default._domainkey.your-domain.com

Save and close the file.

Create Key Table

Execute the following command to create the key table:

sudo nano /etc/opendkim/key.table

Once created, add the following lines in the file:

default._domainkey.your-domain.com     your-domain.com:default:/etc/opendkim/keys/your-domain.com/default.private

Save and close the file.

Create The Trusted Hosts File

Execute the following command to create the trusted table:

sudo nano /etc/opendkim/trusted.hosts

Once created, add the following lines in the file:

127.0.0.1
localhost

*.your-domain.com

Adding the above line means that emails coming from the mentioned IP addresses and domains will be trusted and signed.

Generation of the Private and Public Key for DKIM

DKIM is going to be used for signing outgoing emails. So, you need to generate both private and the public key for DKIM. The private key will be used to signing and the public key which will be published in the DNS will be used for remote verification.

Create a folder for your domain for which DKIM to be signed

sudo mkdir /etc/opendkim/keys/your-domain.com

You can use the opendkim-genkey tool to generate the keys

sudo opendkim-genkey -b 2048 -d your-domain.com -D /etc/opendkim/keys/your-domain.com -s default -v

Once you will execute the above command, two files will get generated:

1. This file will contain your private key.

/etc/opendkim/keys/your-domain.com/default.private

2. This file will contain your public key which you need to add in the DNS record of your domain.

/etc/opendkim/keys/your-domain.com/default.txt

Change the ownership of the private key file:

sudo chown opendkim:opendkim /etc/opendkim/keys/your-domain.com/default.private

Configure Public Key in DNS Record of Domain

Get the public key by doing cat:

sudo cat /etc/opendkim/keys/your-domain.com/default.txt

Copy the record, and log in to your DNS manager e.g. if your DNS is with GoDaddy or Namecheap, then login to their dashboard and add the following DNS record:

Testing Your DKIM Configuration

Execute the following command on your Ubuntu machine to test your keys:

sudo opendkim-testkey -d your-domain.com -s default -vvv
in my server i need to use mail instead of default because it's a prefix I used in the configuratioon

If the setup is correct, you will get the following message:

key OK

Integrate Postfix to OpenDKIM

Postfix can connect with OpenDKIM via Unix socket i.e. /var/run/opendkim/opendkim.sock. But, we need to change the file path because the SMTP daemon which comes with Ubuntu resolves all filenames relative to the Postfix queue directory (/var/spool/postfix).

Create a new directory to keep the OpenDKIM socket file

sudo mkdir /var/spool/postfix/opendkim

sudo chown opendkim:postfix /var/spool/postfix/opendkim

The next step is to edit the socket conf file.

sudo nano /etc/default/opendkim

Search for the following line:

SOCKET="local:/var/run/opendkim/opendkim.sock"

And, replace it with the following:

SOCKET="local:/var/spool/postfix/opendkim/opendkim.sock"

Save and close the file.

Note: You need to do similar changes in the opendkim.conf file too:

sudo nano /etc/opendkim.conf

Search for the following line:

Socket                  local:/var/run/opendkim/opendkim.sock

And, replace it with the following:

Socket                  local:/var/spool/postfix/opendkim/opendkim.sock

Next step is to edit the Postfix main configuration file:

sudo nano /etc/postfix/main.cf

Append the following lines after smtpd_recipient_restriction section in the main.cf file.

# Milter configuration
milter_default_action = accept
milter_protocol = 6
smtpd_milters = local:/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

Save and close the file.

You are now all done. Just restart opendkim and postfix service to reflect all the changes.

sudo service opendkim restart
sudo service postfix restart

Now, your Postfix setup is ready with the SPF and DKIM. You can also visit the official Ubuntu community page for additional detailed documentation on SPF and DKIM set up.

Quick Question: Do you know about DMARC policy? It’s another crucial component of email authentication.

Keep reading the tutorials and blogs to get deeper into email delivery. Rate us if you loved the article.

26 March 2021

Yum remove but not the dependencies

yum remove –noautoremove openproject

18 January 2021

[SOLVED] Denied DNS cache queries originating from 127.0.0.1

from here

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;

…..

10 November 202010 November 2020

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.

20 August 202016 December 2020

How to create and manage services in CentOS 7 with systemd

Systemd is a system and service manager and like most major Linux distributions the init deamon was replaced by systemd in CentOS 7. One of the main functions of systemd is to manage the services, devices, mount points, sockets and other entities in a Linux system. Each of these entity that are managed by systemd is called a unit. Each unit is defined by a unit file (configuration file) which is located in one of the following directories.

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: Simple: This is the default. The main process of the service is the process started with ExecStart. Forking: The process started with ExecStart spawns a new child process which becomes the main process and the parent process is terminated when the startup is completed. Onehot: Similar to simple but systemd waits for the process to exit before proceeding with other units. Dbus: Similar to simple but systemd waits for the process to take a name on the dbus. Notify: Similar to simple Systemd will wait for a notification from the process before continuing with other units. Idle: Similar to simple but service will not run until all other jobs are finished.
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.