$ echo "\"That's impossible"'!'"\" he said." "That's impossible!" he said.
You need to put the symbol between double and single quotes:
” ‘ <symbol> ‘ “
Source: http://qntm.org/bash
$ echo "\"That's impossible"'!'"\" he said." "That's impossible!" he said.
You need to put the symbol between double and single quotes:
” ‘ <symbol> ‘ “
Source: http://qntm.org/bash
Enabled wheel group in sudores
## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL
Add pippo to group wheel
# usermod -a -G wheel pippo
pippo ALL=(ALL) NOPASSWD: ALL
pippo ALL=(ALL) NOPASSWD: ALL Defaults:pippo !requiretty
Something to watch out for.
If you change the owner of a file that has setuid permission, the setuid bit gets removed:
# ls -l /usr/bin/gpasswd -rwsr-xr-x. 1 root root 78144 Mar 19 2013 /usr/bin/gpasswd # chown nobody /usr/bin/gpasswd # ls -l /usr/bin/gpasswd -rwxr-xr-x. 1 nobody root 78144 Mar 19 2013 /usr/bin/gpasswd
Therefore if you reset the owner of such a file (for instance, after an accidental recursive chown), then you need to reset the permissions afterwards.
If you reset both the owner AND the permissions, it has to be done in the correct order – ownership first, then permissions.
So what will this do?
# rpm --setperms --setugids
It turns out (on RHEL5 at any rate) that it changes the permissions first. So the binaries that ought to have the setuid bit were left without it.
The moral of this story is that you should do the work in two passes:
# rpm --setugids # rpm --setperms
find /source/path/ -type d -exec ls -la '{}' \; > file_list find /source/path/ -type d -exec ls -ld '{}' \; > dironly_list find /source/path/ -type f -exec ls -l '{}' \; > filesonly_list
usermod -a -G www-data tony
Source: http://www.cyberciti.biz/faq/howto-linux-add-user-to-group/
atop -a | Display only active processes atop -g | Display general process info atop -m | Display memory usage info atop -n | Display network usage info atop -d | Display Dick usage info Alternatively you can just use atop and then key in the letters above to switch between. atop -r | read raw data. Use this to basically start looking at the processes from the start of the day 00:00 atop -r -b 09:00 | read raw data from 09:00 today atop -r y | read raw data from yesterday atop -r yy | read raw data from the day before yesterday atop -r y -b 09:00 | read raw data from 09:00 yesterday atop -r yy -b 09:00 | read raw data from 09:00 the day before yesterday atop -r <log> | read data from a log stored in /var/log/atop
### Fail2Ban ### Best practise: - do NOT edit /etc/fail2ban/jail.conf BUT create a new /etc/fail2ban/jail.local file ============================================================= # Test fail2ban regex: example: fail2ban-regex /var/log/secure /etc/fail2ban/filter.d/sshd.conf example2: fail2ban-regex --print-all-matched/var/log/secure /etc/fail2ban/filter.d/sshd.conf ============================================================= # Remove email notifications: comment out 'sendmail-whois' from action in [ssh-iptables] FYI, comment with # at the BEGINNING of the line like this or it won't work!!! [ssh-iptables] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] # sendmail-whois[name=SSH, dest=root, [email protected], sendername="Fail2Ban"] logpath = /var/log/secure maxretry = 5 ============================================================= # Wordpress wp-login - block POST attacks /etc/fail2ban/jail.local [apache-wp-login] enabled = true port = http,https filter = apache-wp-login logpath = /var/log/httpd/blog.tian.it-access.log maxretry = 3 bantime = 604800 ; 1 week findtime = 120 ---------------------------------------------------------------------------------------------------------------------- /etc/fail2ban/filter.d/apache-wp-login.conf [Definition] failregex = <HOST>.*POST.*wp-login.php HTTP/1.1 ignoreregex = ============================================================= # Manually ban an IP: fail2ban-client -vvv set <CHAIN> banip <IP> # Check status of sshd chain fail2ban-client status sshd
If you want to make safer your remote server, it is good practise to use a good combination of sshd setup and fail2ban.
Firstly, you should setup your server to allow only key auth, and no passwords. This will drastically reduce the risk. This means anyway that you need to keep your ssh key safe and you won’t be able to access your server unless you have this key. Most of the time is something possible 🙂
For this reason, I’m explaining here how I configured my server.
Have these settings in the config file (NOTE: the verbosity is for Fail2ban)
LogLevel VERBOSE PasswordAuthentication no
(restart sshd)
[DEFAULT] # Ban hosts for # one hour: #bantime = 3600 # one day: bantime = 86400 # A host is banned if it has generated "maxretry" during the last "findtime" # # seconds. findtime = 30 # # "maxretry" is the number of failures before a host get banned. maxretry = 5 # Override /etc/fail2ban/jail.d/00-firewalld.conf: banaction = iptables-multiport [sshd] enabled = true filter = sshd-aggressive port = ssh logpath = /var/log/secure maxretry = 3 findtime = 30 bantime = 86400
Add a custom section after the ddos one:
custom = ^%(__prefix_line_sl)sDisconnected from <HOST> port [0-9]+ \[preauth\]$
This line matches whoever tries to connect without a proper ssh key.
Add this line to include custom to the sshd-aggressive setup:
aggressive = %(normal)s %(ddos)s %(custom)s
This can be achieved using the command nohup
nohup <command> <args> ><filename> 2>&1 & e.g. nohup /usr/bin/terminator -m -T 'main_terminal' -l My_Layout > /dev/null 2>&1 &
>> Exclude .txt files [! CASE SENSITIVE] $ rsync -avz --exclude '*.txt' source/ destination/ >> Exclude from file list $cat exclude-list.txt *.JPG *.TMP *.PDF *.jpg *.tmp *.pdf *.zip relative/path1/ relative/path2/ $ rsync -avz --exclude-from 'exclude-list.txt' /source/path/ /dest/path/ | tee rsync-report.txt >> Exclude directory $ rsync -avz --exclude 'folder1_within_source' --exclude 'folder2_within_source/subfolder2' source/ destination/
>> Create a screen session (labelled) screen -R 'myscreen' >> Detach screen ctrl+A (hold them) + D >> Check current screen sessions screen -ls >>Re-attach screen session screen -r <screen name, from screen -ls including the PID> e.g. screen -r 4238.myscreen >> Quit session screen -X -S [session # you want to kill] quit ======================================= >> When it gets badly stuck screen -ls | grep pts | cut -d. -f1 | awk '{print $1}' | xargs kill screen -ls | grep Attached | cut -d. -f1 | awk '{print $1}' | xargs kill ref: http://askubuntu.com/questions/356006/kill-a-screen-session