Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I had Fail2ban working on a CentOS 5.4 Server. Then I installed a second server CentOS 5.5/6 (all the latest updates.
I configured Fail2ban exxactly the same as it was on the 5.4 box. It starts perfect;y - no errors that I can find,
Fail2ban (pid 3726) is running...
Status
|- Number of jail: 6
`- Jail list: apache-tcpwrapper, webmin-iptables, ssh-iptables, apache-badbots, vsftpd-iptables, ssh-tcpwrapper
All the directories are correct, itś the latest version, yet it just doesn't work, some clown tried over 200 times last night to get the vsftpd password for Administrator.
The first suggestion I have is to look in your fail2ban log and see if you are getting any successful blocks at all. This will tell you if it was something specific with this signature or if you have a general problem with fail2ban. The second thing to note is the time frame associated with these 200 entries. One of the weaknesses of fail2ban is that it is based upon log monitoring and sometimes it takes it a solid few seconds to catch up. Some scripted 'attacks' can fire off several hundred attempts in a matter of seconds and fail2ban doesn't even have a chance to catch the process.
If the timing is such that fail2ban should have caught the attempts, but didn't, check your syslog for error messages associated with iptables that could indicate why the attempt failed. Lastly, fail2ban pattern matches on regular expressions and there is a diagnostic tool that is predominately meant to help write new rules, but you can use it to verify that it will trigger on the entries in question. Sometimes, each distribution has slight variations on messages and the rules need to be tweaked at bit.
/var/log/fail2ban.log shows that everything started and is OK, nothing else at all. Here's a few entires from secure
May 3 01:34:07 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:07 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:07 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:12 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:12 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:12 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:15 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:15 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:15 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:19 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:19 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:19 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:38 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:38 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:38 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:44 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:44 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:44 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:48 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:48 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:48 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:52 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:52 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:52 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:55 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:55 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:55 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:34:59 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:34:59 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:34:59 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:35:02 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:35:02 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
May 3 01:35:02 CentOS55 vsftpd: pam_succeed_if(vsftpd:auth): error retrieving information about user Administrator
May 3 01:35:05 CentOS55 vsftpd: pam_unix(vsftpd:auth): check pass; user unknown
May 3 01:35:05 CentOS55 vsftpd: pam_unix(vsftpd:auth): authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=195.90.163.98
It used to catch this type of attempt on the 5.4 box. Could it be something to do with this new nss thing. On boot, I naw have to enter the root password or it just hangs there waiting. How can I disable this nss
It looks like the application is running. I wish I had a magic bullet type answer of "set this in a config file and it will work", but unfortunately I don't. The good news is that with the application running, I think you will be able to get these messages caught. Here is a link to a discussion document on a tool called fail2ban-regex. This will allow you to test error messages, like the one you received, to determine if fail2ban thinks that it needs to trigger on them. Working with regex can be fun and frustrating and you want to keep in mind that they are very, very, literal and don't always do what you think they should. Use the test tool and start with a very small expression, like 'authentication failure;' and build the capture string from there.
Now for some strange reason, I tried to access the internet with Firefox from the same CentOS box and to my horror it won't connect to the Internet, can't even get www.google.com. I have a couple of Virtual name-based webservers on that box as well, but I can connect to those without a problem.
Bottom line is that vsftpd for fail2ban is a dead loss. I have NO idea why I suddenly lost outgoing internet connectivity.
The pattern matching in fail2ban has always given me trouble, yet I admit that I never took time to try to thoroughly understand it. I found this link this morning and it is helpful. Look at the bottom of the section title Filters. There are 4 example lines that can be used in fail2ban-regex, showing working and non working examples. The section on filters has some important information such as pointing out that you need to match a time stamp as well as the failure regex.
As far as your network not working, there are a few things to check. Chances are you have a mundane problem that is not related. The first of which would be to look at the output of iptables -L (run as root). If there is any question here, run iptables -F to flush the list (policy must not be drop or else you'll shut things down). See if you have a rule that is blocking your outbound connections. Secondly, do you have any sort of proxy that may not have been configured correctly to get an outbound connection? You say you have inbound connections on v-hosts (assume port 80) which works as do the related-established outbound connections. Are they on a different interface or network segment perchance? Look at the output of ifconfig and see if anything is odd. Also try running ping and traceroute to see what an outbound connection looks like (assuming your not blocking icmp). If ping/traceroute work, try telnet. Also, can you access a local page like one of your vhosts from a local address? How about from your public IP?
Finally, if you are having SSH attack troubles be sure you are not allowing password authentication (go key based only) and don't allow direct root login. This should keep this from becoming a compromise situation. You might also want to look at rate limiting your SSH port, which will stop the floods and may make them go away.
Tracert
[root@CentOS55 ~]# tracert google.co.uk
google.co.uk: Temporary failure in name resolution
Cannot handle "host" cmdline arg `google.co.uk' on position 1 (argc 1)
/etc/sysconfig/network-scripts/ifcfg-eth0
# Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]
DEVICE=eth0
BOOTPROTO=none
BROADCAST=192.168.0.255
HWADDR=00:50:56:B8:77:08
IPADDR=192.168.0.203
NETMASK=255.255.255.0
NETWORK=192.168.0.0
ONBOOT=yes
GATEWAY=192.168.0.254 ## This is the smoothwall firewall
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
PEERDNS=yes
It has a fixed IP address and I checked the primary and secondary dns servers, both are correct and both working. I don't have this problem on any other machine
EUREKA! I found it. If I go to Administration --> Network, the DNS is configured correctly, so I thought "that's OK". I was sniffing around checking everything and I looked in /etc/resolv.conf
# generated by /sbin/dhclient-script
# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
DNS1=192.168.0.240
DNS2=192.168.0.242
DOMAIN=xxxxx.com
It was as above. I deleted all except the 1st line and now it's
# generated by /sbin/dhclient-script
search xxxxx.com
nameserver 192.168.0.240
Nameserver 192.168.0.242
I deactivated and activated the eth0 interface and it started to work again.
Who, how, why and what did this, I have NO idea, but now it's started to work again. I can't believe that anyone ever hacked this server, so something changed this. I did install the latest CentOS patches not too long ago, but I can't remember if I tried to use outgoing, I suppose I must have done because the mail was working until today.
BTW - I THINK I found a cure for the vsftpd problem. I highlighted the changes I made
dual_log_enable=YES
#
# The target log file can be vsftpd_log_file or xferlog_file.
# This depends on setting xferlog_std_format parameter xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# The name of log file when xferlog_enable=YES and xferlog_std_format=YES
# WARNING - changing this filename affects /etc/logrotate.d/vsftpd.log xferlog_file=/var/log/vsftpd.log
#
# Switches between logging into vsftpd_log_file and xferlog_file files.
# NO writes to vsftpd_log_file, YES to xferlog_file xferlog_std_format=NO
#
I am glad that you have the fail2ban working as well as your network connection. As I was reading through the information you posted, I saw a problem with this:
Code:
Tracert
[root@CentOS55 ~]# tracert google.co.uk
google.co.uk: Temporary failure in name resolution
Cannot handle "host" cmdline arg `google.co.uk' on position 1 (argc 1)
without DNS resolution, you won't be able to browse. As far as why that changed, normally, resolve.conf is automatically updated with settings received from a DHCP server. It looks like your configuration is for a static IP, but you might want to check any DHCP settings to be sure as it looks like there was an attempt to set the nameservers, but something isn't quite right. The fact that it says DNS1= and DNS2= makes me suspect that it is sending part of the configuration that it isn't supposed to, like the name of the variable that defines the servers.
Also, I usually recommend using programs like Aide, Samhain, or Ossec that will monitor the configuration files and send you an alert email if anything changes.
Last edited by Noway2; 05-09-2011 at 07:45 AM.
Reason: fixed /code tag
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
