Hi,
I thought someone might be familiar with apache and expected behavior to know whether the access_log entries below are attack attempts, or something less alarming. I'm seeing repeated entries like these from a handful of IP addresses at a time, all with 404 errors using "POST /index.php":
222.186.24.108 - - [01/Nov/2011:16:56:29 -0400] "POST /index.php HTTP/1.1" 404 7168 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 31508 7609 222.186.24.108 - - [01/Nov/2011:16:56:46 -0400] "POST /index.php HTTP/1.1" 404 7169 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 85912 7610
Is this a known exploit attempt? The server has been responding slowly, and I believe this is partly the cause.
How can I troubleshoot this further?
Thanks, Alex
On 11/01/2011 10:06 PM, Alex wrote: [snip]
222.186.24.108 - - [01/Nov/2011:16:56:46 -0400] "POST /index.php HTTP/1.1" 404 7169 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 85912 7610
Don't know if it's an exploit. They are probably scanning web hosts for certain behavior/software. The originating IP is from China Telecom. I see a lot of probing and hacking attempts coming from that region. Quick and dirty solution if the website(s) on that server do not serve the Asian market: just block the offending IP ranges in your firewall and be done with it. Harsh but effective. You can find the IP ranges at ipdeny.com. Alternatively you could install something like fail2ban and make it detect these attempts in Apache logs and block the originating IP.
Regards, Patrick
On 11/01/2011 04:06 PM, Alex wrote:
Hi,
I thought someone might be familiar with apache and expected behavior to know whether the access_log entries below are attack attempts, or something less alarming. I'm seeing repeated entries like these from a handful of IP addresses at a time, all with 404 errors using "POST /index.php":
222.186.24.108 - - [01/Nov/2011:16:56:29 -0400] "POST /index.php HTTP/1.1" 404 7168 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 31508 7609 222.186.24.108 - - [01/Nov/2011:16:56:46 -0400] "POST /index.php HTTP/1.1" 404 7169 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 85912 7610
Is this a known exploit attempt? The server has been responding slowly, and I believe this is partly the cause.
How can I troubleshoot this further?
Thanks, Alex
I've installed OSSEC and set a rule that drops an IP address for 30 minutes after 10 404s in a reasonably short time.
Hi,
I thought someone might be familiar with apache and expected behavior to know whether the access_log entries below are attack attempts, or something less alarming. I'm seeing repeated entries like these from a handful of IP addresses at a time, all with 404 errors using "POST /index.php":
222.186.24.108 - - [01/Nov/2011:16:56:29 -0400] "POST /index.php HTTP/1.1" 404 7168 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 31508 7609 222.186.24.108 - - [01/Nov/2011:16:56:46 -0400] "POST /index.php HTTP/1.1" 404 7169 "http://www.example.com/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20100101 Firefox/6.0.2" 85912 7610
Is this a known exploit attempt? The server has been responding slowly, and I believe this is partly the cause.
I've installed OSSEC and set a rule that drops an IP address for 30 minutes after 10 404s in a reasonably short time.
Yes, I've implemented iptables to drop the attempts. I was really just curious if it was a specific attack with a known pattern so I could investigate further. fail2ban is great for things like this.
Thanks, Alex
On 11/1/2011 3:59 PM, Alex wrote:
Yes, I've implemented iptables to drop the attempts. I was really just curious if it was a specific attack with a known pattern so I could investigate further. fail2ban is great for things like this.
Thanks, Alex
Alex:
Do you have an example of the iptables entry which does the block?
Thanks in advance, Paul
Hi,
Yes, I've implemented iptables to drop the attempts. I was really just curious if it was a specific attack with a known pattern so I could investigate further. fail2ban is great for things like this.
Do you have an example of the iptables entry which does the block?
Yes, quite easy. Just doing it manually for now:
# Create the LOGDROP chain iptables -N LOGDROP iptables -F LOGDROP iptables -A LOGDROP -j LOG --log-prefix "LOGDROP " iptables -A LOGDROP -j DROP
iptables -j LOGDROP -I INPUT -s <offending_ip> -d <my_ip> -p tcp --dport 80
This will log each attempt to syslog, or just replace the LOGDROP in the last rule with DROP to avoid the logging.
Best regards, Alex
On 11/1/2011 5:07 PM, Alex wrote:
Yes, quite easy. Just doing it manually for now:
# Create the LOGDROP chain iptables -N LOGDROP iptables -F LOGDROP iptables -A LOGDROP -j LOG --log-prefix "LOGDROP " iptables -A LOGDROP -j DROP
iptables -j LOGDROP -I INPUT -s<offending_ip> -d<my_ip> -p tcp --dport 80
This will log each attempt to syslog, or just replace the LOGDROP in the last rule with DROP to avoid the logging.
Best regards, Alex
Alex:
Thanks. If you bear with a couple "hopefully-not-too-naive" questions ...
I seems to me that you are saying the actions you wish to stop are from "s <offending_ip>" using "-p tcp" ... why the need to specify the destination of "-d <my_ip>" (since if this iptables rule is called, it must have reached me regardless of my_ip) and "--dport 80" (would there be any destination port that I would allow such action from this offending_ip to occur on?).
I am seeing in the default F14 iptables:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
This looks to me like tcp on dport 22 is allowed and there I would think that the minimal change would be to insert a rule before this which says "anything from offending_ip via tcp should be rejected".
I'm still trying to get comfortable with iptables and, even though there is alot of stuff out there, I'm still working to get the necessary critical mass of understanding so it all falls into place. This thread looked like a good chance to see if I'm closer to understanding.
Appreciate in advance, Paul
Hi,
Thanks. If you bear with a couple "hopefully-not-too-naive" questions ...
I seems to me that you are saying the actions you wish to stop are from "s <offending_ip>" using "-p tcp" ... why the need to specify the destination of "-d <my_ip>" (since if this iptables rule is called, it must have reached me regardless of my_ip) and "--dport 80" (would there be any destination port that I would allow such action from this offending_ip to occur on?).
Yes, that's correct. You don't need to include the destination if you only have one IP address on that host.
I am seeing in the default F14 iptables:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
This looks to me like tcp on dport 22 is allowed and there I would think that the minimal change would be to insert a rule before this which says "anything from offending_ip via tcp should be rejected".
I'm still trying to get comfortable with iptables and, even though there is alot of stuff out there, I'm still working to get the necessary critical mass of understanding so it all falls into place. This thread looked like a good chance to see if I'm closer to understanding.
Yes, that's a good approach too. If you are editing the existing iptables config script from /etc/sysconfig/iptables, then that's exactly what you would do. Something like this should work:
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j DROP -s <offending_ip/range> -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
the "<offending_ip/range>" might be something like 1.2.3.0/24 to block the entire 256 addresses on that network.
HTH, Alex
On 11/1/2011 5:42 PM, Alex wrote:
Hi,
Thanks. If you bear with a couple "hopefully-not-too-naive" questions ...
I seems to me that you are saying the actions you wish to stop are from "s<offending_ip>" using "-p tcp" ... why the need to specify the destination of "-d<my_ip>" (since if this iptables rule is called, it must have reached me regardless of my_ip) and "--dport 80" (would there be any destination port that I would allow such action from this offending_ip to occur on?).
Yes, that's correct. You don't need to include the destination if you only have one IP address on that host.
I am seeing in the default F14 iptables:
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
This looks to me like tcp on dport 22 is allowed and there I would think that the minimal change would be to insert a rule before this which says "anything from offending_ip via tcp should be rejected".
I'm still trying to get comfortable with iptables and, even though there is alot of stuff out there, I'm still working to get the necessary critical mass of understanding so it all falls into place. This thread looked like a good chance to see if I'm closer to understanding.
Yes, that's a good approach too. If you are editing the existing iptables config script from /etc/sysconfig/iptables, then that's exactly what you would do. Something like this should work:
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j DROP -s <offending_ip/range> -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
the "<offending_ip/range>" might be something like 1.2.3.0/24 to block the entire 256 addresses on that network.
HTH, Alex
Alex:
Thanks ... it does help to get a confirm that my understanding your example is at least in the general right direction.
Just to check to make sure I got the last bit of info right ...
In your particular example of what appears to be China Telecom, are you assuming that they are using the ip 1.2.3.0/24 and that translates to 1.2.3.[0-255]?
I have a LAN which assumes router connecting to outside world is 192.168.1.1 and my network is 192.168.2.* (wireless only engaged when necessary for both 192.168.1.1 and one Linksys at 192.168.2.2). To me, this means that I "only have one IP address on that host" per your email. If I am correct, I don't need to worry about a generalized 192.168.2.0/24 rule on each machine to prevent something I don't know about.
The addition of 25, 80, and 443 ports are your suggestions for what to allow as opposed to manditories (everything is working nicely on my system with the default and the only other port access I need to do is in sendmail.mc).
Thanks, Paul
Hi,
This looks to me like tcp on dport 22 is allowed and there I would think that the minimal change would be to insert a rule before this which says "anything from offending_ip via tcp should be rejected".
I'm still trying to get comfortable with iptables and, even though there is alot of stuff out there, I'm still working to get the necessary critical mass of understanding so it all falls into place. This thread looked like a good chance to see if I'm closer to understanding.
Yes, that's a good approach too. If you are editing the existing iptables config script from /etc/sysconfig/iptables, then that's exactly what you would do. Something like this should work:
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j DROP -s <offending_ip/range> -A INPUT -m state --state NEW -m tcp -p tcp --dport 25 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
the "<offending_ip/range>" might be something like 1.2.3.0/24 to block the entire 256 addresses on that network.
HTH, Alex
Alex:
Thanks ... it does help to get a confirm that my understanding your example is at least in the general right direction.
Just to check to make sure I got the last bit of info right ...
In your particular example of what appears to be China Telecom, are you assuming that they are using the ip 1.2.3.0/24 and that translates to 1.2.3.[0-255]?
Yes, that's correct. Search for CIDR notation.
I have a LAN which assumes router connecting to outside world is 192.168.1.1 and my network is 192.168.2.* (wireless only engaged when necessary for both 192.168.1.1 and one Linksys at 192.168.2.2). To me, this means that I "only have one IP address on that host" per your email. If I am correct, I don't need to worry about a generalized 192.168.2.0/24 rule on each machine to prevent something I don't know about.
Yes, that's correct, but I was really referring to the destination -- if you wanted to block more than one host at a time, such as for an entire ISP in China, for example. So from my original log entry example of 222.186.24.108, you might do:
# iptables -j DROP -I INPUT -s 222.186.24.0/24
This would block all access from that host to your network.
The addition of 25, 80, and 443 ports are your suggestions for what to allow as opposed to manditories (everything is working nicely on my system with the default and the only other port access I need to do is in sendmail.mc).
I wasn't sure if that was from the original rulebase or if it was something I added :-)
The default is to allow everything, but there is a ICMP reject rule at the bottom of the rulebase that rejects everything else for which there is no rule such as those for port 25 and 80.
Best, Alex
-
Alex -
Patrick Lists -
Paul Allen Newell -
SternData