PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
 
Loading
It is currently Thu Mar 23, 2017 11:05 pm

All times are UTC - 5 hours




Post new topic Reply to topic  [ 5 posts ] 
Author Message
PostPosted: Wed Apr 15, 2015 2:37 pm 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 170
Hi, I am about to change my SSH port. I have the commands prepared as listed below as extracted from this link. http://www.cyberciti.biz/faq/centos-change-ssh-port/. However in place of the manually entered firewall command I was thinking I would run the script shown in quotes to flush the iptables and reset everything (but with the new SSH port being used). The command in the script is slightly different. Am I correct in assuming that because I am flushing the iptables with my script I should be okay? I am tempted to just go for it but the lockout thing is haunting me I guess. Maybe someone can scare away the ghosts :-) Thanks, John

cp /etc/ssh/sshd_config /etc/ssh/ sshd_config.jwbBackup004
vim /etc/ssh/sshd_config
Change from "#Port 22" to "Port 2222" (port for windows servers but not for Linux servers)
save your changes and close the sshd_config file
semanage port -a -t ssh_port_t -p tcp 2222 (If you are using OpenSSH SELinux)

NOTE: this would be replaced with the command in the script below but using port 2222
-A INPUT -m state --state NEW -m tcp -p tcp --dport 2222 -j ACCEPT (<<<<<<<<<<<<<<<<<<<<<<<<<<<Manually entered command)

service iptables stop
service sshd reload (uses the changes made above in sshd_config)
netstat -tulpn | grep sshd (Verify the new port settings. You should see 2222)
service iptables start

change Putty to use port 2222 and change WinSCP to use port 2222




Quote:
#!/bin/bash
#
# MyFireWall script - chmod +X MyFireWall - ./MyFireWall
#
# Basic Website Criteria:
# PHP, MySql, Apache driven web pages with file down load and upload.
# FTP is turned off and everything is working fine
# Putty and WinSCP is used.
# No incoming mail. Only outgoing mail with Postfix
#
# Created with http://wiki.centos.org/HowTos/Network/IPTables NOTE: you used this one to rough in this script and it explains running this. Comments were coppied to the 2nd last command below.
# Created with http://articles.slicehost.com/assets/20 ... tables.txt NOTE: this one had some more commands you might have used
# created with https://help.ubuntu.com/community/IptablesHowTo NOTE: this explains a little more of what is in this script
# created with http://blog.adityapatawari.com/2011/12/ ... ained.html NOTE: this explains some basic commands
#
# NOTES: when you close port 25 you are blocking incoming mail to your VPS. All your outgoing ports are open so you can send email (ports 465 and 587).
# http://serverfault.com/questions/149903 ... ail-server
# You are keeping a backup of this script in C:\Access\GuitarPracticeRecords\Jamming\Installing_On_Each_WebHost\LinuxScripts\Velcom
#
#If connecting remotely we must first temporarily set the default policy on the INPUT chain to ACCEPT otherwise once we flush the current rules we will be locked out of our server.
iptables -P INPUT ACCEPT
#
#
# Flush all current rules from iptables - We used the -F switch to flush all existing rules so we start with a clean state from which to add new rules.
iptables -F
#
#
# Set access for localhost
# use the -i switch (for interface) to specify packets matching or destined for the lo (localhost, 127.0.0.1) interface and finally
# So this rule will allow all incoming packets destined for the localhost interface to be accepted.
# This is generally required as many software applications expect to be able to communicate with the localhost adaptor.
# Link https://help.ubuntu.com/community/IptablesHowTo is the link that suggested putting this in.
# Allows all loopback (lo0) traffic
iptables -A INPUT -i lo -j ACCEPT
#
#
# Accept packets belonging to established and related connections
# we are adding (-A) it to the INPUT chain.
# Here we're using the -m switch to load a module (state).
# The state module is able to examine the state of a packet and determine if it is NEW, ESTABLISHED or RELATED.
# NEW refers to incoming packets that are new incoming connections that weren't initiated by the host system.
# ESTABLISHED and RELATED refers to incoming packets that are part of an already established connection or related to and already established connection.
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
#
#
# Here we add a rule allowing SSH connections over tcp port 22. - By default SSH uses port 22 and again uses the tcp protocol.
# So if we want to allow remote logins, we would need to allow tcp connections on port 22 Putty
# This is essential when working on remote servers via SSH to prevent locking yourself out of the system
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
#
#
# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
#
#
# Allow ping
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
#
#
# log iptables denied calls
# iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
#
#
# Set default policies for INPUT, FORWARD and OUTPUT chains
# The -P switch sets the default policy on the specified chain.
# So now we can set the default policy on the INPUT chain to DROP.
# This means that if an incoming packet does not match one of the following rules it will be dropped.
# If we were connecting remotely via SSH and had not added the rule above, we would have just locked ourself out of the system at this point.
iptables -P INPUT DROP
#
#
# set the default policy on the FORWARD chain to DROP as we're not using our computer as a router so there should not be any packets passing through our computer.
iptables -P FORWARD DROP
#
#
# Set the default policy on the OUTPUT chain to ACCEPT as we want to allow all outgoing traffic (as we trust our users).
iptables -P OUTPUT ACCEPT
#
#
# Save settings - the last thing we need to do is save our rules so that next time we reboot our computer our rules are automatically reloaded:
# This executes the iptables init script, which runs /sbin/iptables-save and writes the current iptables configuration to /etc/sysconfig/iptables.
# Upon reboot, the iptables init script reapplies the rules saved in /etc/sysconfig/iptables by using the /sbin/iptables-restore command.
/sbin/service iptables save
#
#
# List rules - we can list (-L) the rules we've just added to check they've been loaded correctly. -v means verbose
iptables -L -v



Top
 Profile  
 
PostPosted: Wed Apr 15, 2015 3:49 pm 
Offline
Spammer :|
User avatar

Joined: Wed Oct 15, 2008 2:35 am
Posts: 6379
Location: WA, USA
Don't need a script for it. Personally, I'd rather execute the commands by hand.

Keep in mind that once you've established an SSH session, it will continue even if:
a) You restart sshd. Doing that only restarts the daemon which handles incoming connections and won't affect the child process your connection is actually using.
b) You restart sshd on a new port. Port 22/2222 is only for new connections; once connected you begin using a completely different port.
c) You reload iptables with a new configuration. Your existing connection (which is on neither port 22 nor port 2222) will continue as iptables is pretty much always configured to allow existing connections and only really filters new connections.

CentOS I assume? As root/with sudo, obviously, here's the general sequence steps:
1. Use "service iptables save" to save the current iptables rules to /etc/sysconfig/iptables, which then gets loaded automatically on startup.
2. Go into that file, find the rule which allows SSH connections, and change it to use the new port. You may want to make a backup first.
3. Reload the rules with "iptables-restore </etc/sysconfig/iptables".
4. Set the SSH daemon to the new port, (possibly make a backup,) and restart it.
5. Try a second SSH session with the new port to see if you can connect.
6. If that doesn't work then undo your changes/restore the backups, apply the changes, and then find out what went wrong.


Top
 Profile  
 
PostPosted: Wed Apr 15, 2015 5:29 pm 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 170
Thanks requinix, You have answered a lot of questions I was wondering about which takes the fear out of it. I am going to give it a run tomorrow morning when I am more alert. I basically use the script (with heavy comments on anything I learn that is new) so I can go back and look things up and also have a place to add more comments as I pick up more info.
John


Top
 Profile  
 
PostPosted: Thu Apr 16, 2015 9:51 am 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 170
I got it to work. I had made a mistake in switching off passwords and they were not actually off but this round of tests caught the problem so I fixed that too. So it is fully working on keys now. I will check the /var/log/secure file later. I am looking forward to see all these root password login attempts gone. It looks like they are gone now. Thanks for everyone's help.


Top
 Profile  
 
PostPosted: Fri Apr 17, 2015 7:03 am 
Offline
Forum Contributor

Joined: Fri Jul 18, 2014 1:54 pm
Posts: 170
I just checked the /var/log/secure file and it is now completely clear of failed log in attempts even though I turned off fail2ban. The only entries are for my logging in and out. I turned off fail2ban because it seems to be unneeded now and it was creating unwanted messages in the maillog file.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group