I'm having trouble generating an email notice when someone is trying to do an ssh bruteforce attack on my server with Bro (v2.4.1). I have a Bro script like this which redefines the max login attemps to 5 per 24 hours:
#load protocols/ssh/detect-bruteforcing
redef SSH::password_guesses_limit=5;
redef SSH::guessing_timeout=1440 mins;
hook Notice::policy(n: Notice::Info)
{
if ( n$note == SSH::Password_Guessing && /192\.168\.178\.16/ in n$sub )
add n$actions[Notice::ACTION_EMAIL];
}
where 192.168.178.16 is the local ip of my server and I've made sure the script gets loaded by including it in $PREFIX/site/local.bro. The output of broctl scripts shows that the script is loaded just fine on startup. However, I never receive any email notice of ssh bruteforcing attacks.
Connection summaries, dropped packets and invalid ssl certificate notices are emailed just fine, so it's not an email configuration issue. When I check the ssh log output like so:
sudo cat /opt/bro/logs/current/ssh.log | bro-cut -d ts uid id.orig_h id.orig_p id.resp_h id.resp_p version auth_success direction client server cipher_alg
The 6 failed login attemps (that I generated for testing this) are logged just fine in /opt/bro/logs/current/ssh.log:
2016-11-11T14:45:08+0100 CRoENl2L4n5RIkMd0l 84.241.*.* 43415 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
2016-11-11T14:45:13+0100 CMflWI2ESA7KVZ3Cmk 84.241.*.* 43416 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
2016-11-11T14:45:17+0100 CZuyQO2NxvmpsmsWwg 84.241.*.* 43417 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
2016-11-11T14:45:20+0100 CC86Fi3IGZIFCoot2l 84.241.*.* 43418 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
2016-11-11T14:45:25+0100 CHqcJ93qRhONQC1bm4 84.241.*.* 43419 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
2016-11-11T14:45:28+0100 CdV0xh1rI4heYaFDH2 84.241.*.* 43420 192.168.178.16 22 2 - INBOUND SSH-2.0-JuiceSSH SSH-2.0-OpenSSH_6.7p1 Raspbian-5+deb8u3 aes128-ctr
However I never get any email notice of this happening. The only reason I can think of is I have password login over ssh disabled, so maybe the login attemps without a private key are not firing the ssh_failed_login events in Bro? The auth_success column in above table shows a "-" for the failed login attemps whereas a succesfull login shows a "T", so maybe that should be a "F" in order for the event to fire?
Any help or suggestions is greatly appreciated!
Due to SSH being encrypted, we've had to resort to heuristics for detection of successful and unsuccessful authentications. Those heuristics have improved through time but are still far from perfect. If the "auth_success" column is unset like it is in the examples you provided it means that Bro was unable to make the guess if the login was successful or not.
The reason that the bruteforce detection script isn't working is because it's never detecting an unsuccessful login. Your suspicion at the end of your question is correct.
Slackware OS, trying to setup fetchmail
I have coded this .fetchmailrc file:
set daemon 600 //fetches mail every hour or 60 minutes.
set logfile /root/fetchmail.log
poll 10.200.***.** protocol POP3
user "bob" password "bob" is "bob" here preconnect "date>>/root/fetchmail.log"
ssl
no rewrite
keep
It worked before but now it is failing to retrieve mail, i checked the fetchmail.log file and i get this error:
Thu Nov 5 10:15:32 GMT 2015
fetchmail: connection errors for this poll:
name 0: connection to 10.200.***.**:pop3s [10.200.***.**/995] failed: Connection refused.
fetchmail: POP3 connection to 10.200.***.** failed: Connection refused
fetchmail: Query status=2 (SOCKET)
I've reset the daemons, ended the process and no progress.
I had exactly the same problem on a Mageia 5 Linux. Apparently, I
solved it by redoing network configuration, which the Mageia can do
with a single click on the relevant Configure button in the Network
Center window.
I did not touch my .fetchmailrc file.
I am trying to clone repository via SSH. Public key for my user is set as deploy key in a project.
I got this error message:
Access denied.
fatal: The remote end hung up unexpectedly
Here is my /var/log/secure for this attempt
Jul 16 11:09:54 gitlab sshd[32217]: Accepted publickey for git from <IP> port 55499 ssh2
Jul 16 11:09:54 gitlab sshd[32217]: pam_unix(sshd:session): session opened for user git by (uid=0)
Jul 16 11:09:54 gitlab sshd[32219]: Received disconnect from <IP>: 11: disconnected by user
Jul 16 11:09:54 gitlab sshd[32217]: pam_unix(sshd:session): session closed for user git
And here is /var/log/gitlab/gitlab-shell/gitlab-shell.log
[2014-07-16T11:09:54.407037 #32220] ERROR -- : API call <GET https://gitlab//api/v3/internal/allowed?action=git-upload-pack&ref=_any&project=group%2Fproject&forced_push=false&key_id=5> failed: 404 => <{"message":"404 Not found"}>.W,
[2014-07-16T11:09:54.407161 #32220] WARN -- : gitlab-shell: Access denied for git command <git-upload-pack 'group/project.git'> by user with key key-5.
Can you please help me to figure out what's wrong?
For many other deploy keys specified everything works just well.
Today I run into the same behavior as you describe. I found an open issue in gitlabhq(https://github.com/gitlabhq/gitlabhq/issues/6908).
The problem is that it can happen that the same public key are two times listed in /home/git/.ssh/authorized_keys. In my case I deleted the deploy key and recreate it to have a better name. In this case the key was not remove from the authorized_keys file.
After I deleted the deploy key and the corresponding lines in the authorized_keys file and recreate the deploy key in my project the access is working.
This time I have another question. This one is related to FTP. We have an ftp server say 127.0.0.2. The application server is on ip say 127.0.0.1. From the application server, we connect to the FTP server every 10 minutes and pull or push certain files in the INWARD and OUTWARD folders respectively.
The ftp server is running linux with the following details:
-bash-3.2$ uname -n
ftpserver.companyname.com
-bash-3.2$ uname
Linux
-bash-3.2$ uname -r
2.6.18-308.13.1.el5
The problem is that the FTP user gets locked automatically on a random basis. Random meaning really random... This instance it is working but within the next 15 seconds it will get locked triggering of an alert and thus requiring user intervention to get it unlocked.
To check when the locking is happening, we wrote a monitoring shell script to check the ftp connection every 15 seconds. This script will only connect to the ftp machine and quit. If everything is ok, it will not do anything but if connection fails it will mail the stake holders with the ftp log.
SCRIPT >>
ftp -niv $FTP_HOST <<END_SCRIPT > $FTP_LOG
quote USER $FTP_USER
quote PASS $FTP_PASSWD
quit
END_SCRIPT
Now if we see the log generated from the script, we can see the below information:
LOG >>
::::: DATE/TIME = Wed Apr 23 17:35:00 UTC 2014 :::::
Step 1 complete : Initialised log file ~/ftp_support_23_Apr_2014.log
Step 2 complete : Completed check for ftp login
FTP connection to 127.0.0.2 is ok.
Step 3 completed. Deleted ftp.log
::::: DATE/TIME = Wed Apr 23 17:35:15 UTC 2014 :::::
Step 1 complete : Initialised log file ~/ftp_support_23_Apr_2014.log
Step 2 complete : Completed check for ftp login
FTP user username is locked on 127.0.0.2.
Step 3 completed. Deleted ftp.log
----- SAME OUTPUT AS ABOVE EVERY 15 SECONDS TILL USER IS UNLOCKED ------
Here the ftp user was unlocked by the SA.
::::: DATE/TIME = Wed Apr 23 17:41:40 UTC 2014 :::::
Step 1 complete : Initialised log file ~/ftp_support_23_Apr_2014.log
Step 2 complete : Completed check for ftp login
FTP connection to 127.0.0.2 is ok.
Step 3 completed. Deleted ftp.log
Now the question that we all have is what could have happened in 15 seconds causing the user to get locked? At 17:35:00 UTC the connection is ok, at 17:35:15 UTC, the connection goes dead. The log which is mailed to the stake holders is as below -
MAILED FTP LOG >>
Connected to 127.0.0.2.
220 (vsFTPd 2.0.5)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
331 Please specify the password.
530 Login incorrect.
221 Goodbye.
Now we know for sure, that the password is read from a encrypted config file and used by the program. If it works every 10 mins, then there is no problem with the program sending the password to the ftp user. And any system user is not typing in the password incorrectly. Hence the question here is what do we need to check at our end?
How do we interpret the 530 Login incorrect. error message? Can anyone suggest what we have to do here? Has the SA changed any setting on the ftp server? What can we ask them to check at OS level or for the ftp service?
If the output of any command is needed or if any running service needs to be checked, let me know.
It used to be working, but out of the blue, it stopped sending mail. I thought I set everything up in both linux and exchange to function correctly, but we're not receiving the emails - internally or externally.
I'm not that knowledgeable about linux, so I use webmin to get around.
So, we have our shopping cart and online forms on the linux server that will email users confirmations and such. It won't receive any mail, so I don't need to worry about that. It only sends mail out, both inside our network, and outside. Here is a recent addition to the mail log:
Dec 6 11:51:04 istalinux2 sendmail[1696]: rB6Gp4lr001696: from=www-data, size=246, class=0, nrcpts=1, msgid=, relay=www-data#localhost
Dec 6 11:51:05 istalinux2 sm-mta[1697]: rB6Gp4hY001697: from=, size=485, class=0, nrcpts=1, msgid=, proto=ESMTP, daemon=MTA-v4, relay=localhost [127.0.0.1]
Dec 6 11:51:05 istalinux2 sendmail[1696]: rB6Gp4lr001696: to="John Smith" jsmith#ista-in.org, ctladdr=www-data (33/33), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30246, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (rB6Gp4hY001697 Message accepted for delivery)
Dec 6 11:51:05 istalinux2 sm-mta[1699]: rB6Gp4hY001697: to=jsmith#ista-in.org, delay=00:00:01, xdelay=00:00:00, mailer=relay, pri=120485, relay=10.20.51.30, dsn=5.1.2, stat=Host unknown (Name server: 10.20.51.30: host not found)
Dec 6 11:51:05 istalinux2 sm-mta[1699]: rB6Gp4hY001697: to=www-data#istalinux2.ista-in.org, delay=00:00:01, mailer=local, pri=120485, dsn=5.1.1, stat=User unknown
Dec 6 11:51:05 istalinux2 sm-mta[1699]: rB6Gp4hY001697: rB6Gp5hY001699: postmaster notify: User unknown
Dec 6 11:51:05 istalinux2 sm-mta[1699]: rB6Gp5hY001699: to=root, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30000, dsn=2.0.0, stat=Sent
I have a receive connector set up in Exchange to receive incoming mail from our linux server and pass it through.
I am using sendmail in linux - but I honestly don't care how it's set up, as long as it works and doesn't break, lol. Please help me make sure all my settings in linux are correct ... and keep in mind that I am NOT a linux guy.
The problem seems to be this part:
relay=10.20.51.30, dsn=5.1.2, stat=Host unknown (Name server: 10.20.51.30: host not found)
I assume that 10.20.51.30 is the ip address of your exchange server. Now, without seeing the actual configuration files, it's a bit hard to find out what you did wrong, but normally, when you specify a mail relay, you have to use either a) a real dns name, not an ip, or b) enclose the ip in [] brackets - just like the line before that one, which says relay=[127.0.0.1].
Try enclosing the 10.20.51.30 in [] brackets, or, use the name of the exchange server instead of the IP, and make sure your DNS server can resolve that name.