I've had a postfix(SASL) mail server running well for a long time with no problems. However recently I've installed vsftp to allow users to login and download files.
I created a linux user with a generic username/password which I thought didn't matter as I had disabled ssh login and wasn't too concerned if anyone had logged into the ftp account (read-only access). However what I hadn't realised was that several spammers have brute forced entry (logging into SASL) and sending emails.
Is there any way to disable the linux user for mail but keep the credentials the same for vsftp?
Try
usermod -s /bin/false username
I ended up removing the linux user and adding the user as a user for vsftp. This then still allowed the username/password to work and disabled the intruder from using the server as a spam server. Issue resolved :).
Related
i want to save the user's IP when he connects to it's home folder, this is because i'm a user in a server where my team has a folder where our public_html is located, but we use the same account, so i just want to register who connected.
So i want to make a script that triggers when a connection is made and save the user's IP into a hidden file.
But i don't know if i could leave running a script in background to do it, and How?
If you're a root on that machine, you can simply check the auth log / messages / journal / ... (depends on the distribution). By default sshd logs all you need already.
If you're not a root, then you'll have to keep in mind this will never be secure. You can do this in the user's bash profile, but:
Since it's running as the same user, whoever logs in can just change the file (you can't hide it)
Anyone can workaround the script by executing some other command instead of the shell (for example ssh user#host /some/command will not be logged)
It's not secret.
If that's ok with you, then you just need to add this to bashrc
echo "new connection at $(date) from ${SSH_CLIENT}" >> ~/your_connection_log
Different solution, which should've been the default actually. Most distributions provide login history which you can request for your account without root privileges.
Running last your_username should give you the details of last few logins which cannot be manipulated by the user. (the log can possibly be spammed with entries however)
My problem with one email account is not incoming / outgoing spam, that I could manage. It's the Brute Force attempts. My csf and cphulk take care of the attemps already, BUT its like 10 attemps per second from VERY different IPs.
So only solution I can think of is temprorarily disabling / suspending the said email account. But I cant find a way to do this via whm linux or cpanel.
Apparently it's already a feature request for whm/cpanel: https://features.cpanel.net/topic/disable-email-account
The only thing i found close to a solution was this: http://cpanelplesk.com/disabling-an-email-account-in-cpanelwhm/
But I dont know if It would work, and if its the right way to do this. Any opinions ?
You can not disable/suspend any single mail account on cpanel server, As per the above URL you can prevent outgoing email from the single account. But you are getting invalid login attempts issues so that will not help you on this.
I configured my Jenkins server to only use HTTPS and enabled security.
As well I don't like anybody who's not logged on to see the Dashboard (even if it would be empty). Here for I disabled the 'read' access for 'anonymous'.
So far all this works exactly to my likings :)
But wanting to add some build notification functionality to remote clients by e.g. using something like 'CCtray' I run into trouble. The access to the https://<SERVER>/cc.xml now only works for logged in users.
Where I would have liked to be able to get those notifications for 'anonymous'.
Probably combining these wishes is kind of contradictory - I suppose?
Maybe someone has a better idea which could match my likings?
Possibly any other notification tool which can be used???
For the Mercurial hook triggering the sw-builds I can use a construction like
curl --cacert <CERTIFICATE> https://<USER>:<PASSWORD>#<SERVER>/job/MyPROJECT/build?delay=0sec
But a similar approach for the URL in CCtray doesn't seem to work.
I've just started using the cctray Jenkins transport extension. Early days, but it seems to work as advertised and is connecting to our secure server perfectly happily.
Currently, the only significant limitation seems to be that if your password expires there's no way to re-enter your credentials.
For Jenkins servers without anonymous access, you can use Catlight build notification tool. You can provide access token or username/password to authenticate to your server.
I you have a self-signed ssl certificate, make sure that you add it to trusted by OS. That way, most applications will recognize it and connect to server without warnings.
Adding to #MrBlueSky 's answer, you can avoid the password expiration hassle; simply use a Jenkins-issued API Token instead of your password.
Log into Jenkins
Click your username (in the upper right corner)
Click Configure (in the left navbar)
Click Show API Token
Use this token in place of your password when setting up the Jenkins Transport settings
I'm use an Debian based OS here on my work an i've configured the service for test routines of ERP app...
This service (Tomcat+Java service) it's consumed via HTTP on intranet correctly...but the test leader sometimes need chance the database used by service application and uses SSH to access my machine to change database on config file and restart the service...eventually this person change some service or O.S. config throwing problems to me (on my O.S and others things..).
What i want know is if can i change my password only for SSH service (doesn't change to my KDE/Gnome session), just because the company's policy requires everyone to have a default password on stations...
Remebering that i'm a manager of config, maintenance and others jobs of service to test team...and change database solicitations can made to me.
A simple example:
KDE login if user 'carlos' and password '123456'
SSH login if user 'carlos' and password '4nyJokeHere'
That it's possible ?
Thanks in advance.
Possible? Maybe. You'd probably have to fiddle with pam.d to get SSH authenticating via a different mechanism to KDE etc.
Coming from a different angle, I may be missing something, can you not create a second user for the SSH process, keeping your main user for KDE etc cleanly separate?
I'd really strongly recommend trying to "split" a user into multiple purposes/security groups with differing passwords for each!
You can use authorized_keys to restrict the SSH commands available, and/or sudo...
Update: Some expansion on the subject as requested by the OP
You can limit commands available via SSH by using ~/.ssh/authorised_keys file - see O'Reilly for a good explanation.
I'm was solved this case applying a single rule here. On SSH service i'm was locked access of my user 'carlos --> sudoers' and enable access only for a user called 'padrao' (padrao translated to english is 'default').
This user 'padrao' doesn't have sudoers permissions. If i needed access with SSH my machine i'm do:
ssh padrao#my.intranet.machine
password: ***
$ su carlos
password: ***
This is not the best way to solve, but solved my problem here.
Thanks.
I have Configured LDAP Authentication for my Linux Machines. The LDAP Server is Novell eDirectory. The LDAP Users are able to login into the machine. But when i am issuing passwd command it is asking LDAP password then asking to give me new password. After that i am getting a message saying that all the authentication tokens are successfully updated.
But when i try to login with the new password into the machine it is not allowing but when i tried with the old password it is allowing me to loign. Even the eDirectory password also didn't got changed?
What's wrong i am doing?
Thanks and regards,
Sunny.
Do you have access to the eDirectory server you are pointing at? If so, go to iMonitor (https://serverIP:8030/nds/trace) and login, and then in Trace settings (box in the bar with tick marks, and lightning bolts) and clear all, and then enable LDAP tracing.
Refresh and go to Trace Live, then do the password change and look at the trace event from the LDAP server perspective. Likely something will be revealed there.