Hi all,
I have a small server that I have recently upgraded to fedora 18. After a while, I got notified by the provider that their firewall catches thousands of requests, with the following error message:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything strange.
It is strange that the machine is trying to contact a server in USA, isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server, so I have a few hours to debug this...)
George
On 03/15/13 17:05, Georgios Petasis wrote:
Hi all,
I have a small server that I have recently upgraded to fedora 18. After a while, I got notified by the provider that their firewall catches thousands of requests, with the following error message:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything strange.
It is strange that the machine is trying to contact a server in USA, isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server, so I have a few hours to debug this...)
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Στις 15/3/2013 11:46 πμ, ο/η Ed Greshko έγραψε:
On 03/15/13 17:05, Georgios Petasis wrote:
Hi all,
I have a small server that I have recently upgraded to fedora 18. After a while, I got notified by the provider that their firewall catches thousands of requests, with the following error message:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything strange.
It is strange that the machine is trying to contact a server in USA, isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server, so I have a few hours to debug this...)
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
No, it is always the same IP. I don't know if a DNS server is running. How can I check this?
(There used to be a system-config-services, but I don't know if it exists anymore, with this new "sytstemctl" stuff)
Thanks,
George
On 03/15/13 17:55, Georgios Petasis wrote:
No, it is always the same IP. I don't know if a DNS server is running. How can I check this?
(There used to be a system-config-services, but I don't know if it exists anymore, with this new "sytstemctl" stuff)
Well, if you didn't install and configure it....it won't be running. In any case, see my other message which discounts my initial thinking.
Is it always the same source port?
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
Στις 15/3/2013 11:57 πμ, ο/η Ed Greshko έγραψε:
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
I have used nslookup with the local machine as server, and I was not able to resolve anything. Also, the dnsmasq configuration is empty. I think I am not running a dns server...
Thanks,
George
W dniu 15.03.2013 11:09, Georgios Petasis pisze:
Στις 15/3/2013 11:57 πμ, ο/η Ed Greshko έγραψε:
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
I have used nslookup with the local machine as server, and I was not able to resolve anything. Also, the dnsmasq configuration is empty. I think I am not running a dns server...
Thanks,
George
Sorry, but can't you just type netstat -aptul as root to see what connections are active? Status of services can be checked using systemctl tool: systemctl status named.service
Mateusz Marzantowicz
Am 15.03.2013 14:03, schrieb Mateusz Marzantowicz:
W dniu 15.03.2013 11:09, Georgios Petasis pisze:
Στις 15/3/2013 11:57 πμ, ο/η Ed Greshko έγραψε:
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
I have used nslookup with the local machine as server, and I was not able to resolve anything. Also, the dnsmasq configuration is empty. I think I am not running a dns server...
Sorry, but can't you just type netstat -aptul as root to see what connections are active? Status of services can be checked using systemctl tool: systemctl status named.service
you can - but after a intrusion you can not trust any output of system-tools because you are not in the position to say 100% if the first intrusion did not use a local root-exploit after it's first run and modified your system in a way making it hard to detect rootkits
Am 15.03.2013 10:57, schrieb Ed Greshko:
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
pretty sure only if your DNS is very outdated http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
http://en.wikipedia.org/wiki/DNS_spoofing As stated above, source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit cryptographic nonce, can greatly reduce the probability of successful DNS race attacks.
On 03/15/13 19:15, Reindl Harald wrote:
Am 15.03.2013 10:57, schrieb Ed Greshko:
On 03/15/13 17:46, Ed Greshko wrote:
Is the destination IP address a single IP address or are there others.
Is your system running a DNS server? If you are running one, is it supposed to be servicing requests from the Internet? If it is supposed to be taking requests from the Internet, have you made sure to configure such that recursion is disabled.
Never mind....
In re-reading the original message I see the "source port" is 35442. I'm pretty sure recursion from a DNS server would show 53 as the source port.
pretty sure only if your DNS is very outdated http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
http://en.wikipedia.org/wiki/DNS_spoofing As stated above, source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit cryptographic nonce, can greatly reduce the probability of successful DNS race attacks.
Good to know. It has been a long time since I've done DNS stuff at the network layer.
It sounded like a DNSSEC and DNS amplification attack with the Bank's network as the target. But, the OP seems not to have a DNS server configured.
First, whois 216.82.176.7
216.82.176.7 belongs to a bank in the US https://www.53.com/
I don't know if it's a real bank or what?
$ whois 216.82.176.7
The last part of your ISPs message is interesting because it says: "packet length 1400 bytes exceeds configured limit of 512 bytes"
So something is sending excessively large UDP packets to the bank via port 53.
This may just be DNSSEC EDNS0 protocol which is being blocked by your ISP's firewall.
But in this case, 53.com does not support DNSSEC (never just a bank!)
It would be good if you could ask your ISP for a packet capture (say in pcap format) which you could analyze off line.
Al.
On 03/15/2013 09:05 AM, Georgios Petasis wrote:
Hi all,
I have a small server that I have recently upgraded to fedora 18. After a while, I got notified by the provider that their firewall catches thousands of requests, with the following error message:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything strange.
It is strange that the machine is trying to contact a server in USA, isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server, so I have a few hours to debug this...)
George
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. (I know this is an old version of joomla, and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
Thus, I have shutdown the web server, and monitor the server for a few days, to see if these firewall complains persist.
Regards,
George
Στις 15/3/2013 12:20 μμ, ο/η agraham έγραψε:
First, whois 216.82.176.7
216.82.176.7 belongs to a bank in the US https://www.53.com/
I don't know if it's a real bank or what?
$ whois 216.82.176.7
The last part of your ISPs message is interesting because it says: "packet length 1400 bytes exceeds configured limit of 512 bytes"
So something is sending excessively large UDP packets to the bank via port 53.
This may just be DNSSEC EDNS0 protocol which is being blocked by your ISP's firewall.
But in this case, 53.com does not support DNSSEC (never just a bank!)
It would be good if you could ask your ISP for a packet capture (say in pcap format) which you could analyze off line.
Al.
On 03/15/2013 09:05 AM, Georgios Petasis wrote:
Hi all,
I have a small server that I have recently upgraded to fedora 18. After a while, I got notified by the provider that their firewall catches thousands of requests, with the following error message:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything strange.
It is strange that the machine is trying to contact a server in USA, isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server, so I have a few hours to debug this...)
George
On 03/15/2013 11:16 AM, Georgios Petasis wrote:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. (I know this is an old version of joomla, and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
Thus, I have shutdown the web server, and monitor the server for a few days, to see if these firewall complains persist.
The only way to be sure the machine is clean is to re-install Fedora (and re-format) from scratch and probably and older version like F17 as F18 is very new.
This will also reassure your ISP that the issue is being addressed.
On Fri, 15 Mar 2013 11:53:12 +0000, agraham wrote:
On 03/15/2013 11:16 AM, Georgios Petasis wrote:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. (I know this is an old version of joomla, and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
Thus, I have shutdown the web server, and monitor the server for a few days, to see if these firewall complains persist.
The only way to be sure the machine is clean is to re-install Fedora (and re-format) from scratch and
Certainly not "the only way", but it might be more easy than failing to detect how the system has been modified. Simply running "rpm -Va" is insufficient. Running an intrusion detector such as AIDE would have been necessary to cover many more (if not all) installed files.
probably and older version like F17 as F18 is very new.
That won't change a thing when installing an out-of-date Joomla that is not included within the Fedora package collection.
Am 15.03.2013 12:16, schrieb Georgios Petasis:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. I know this is an old version of joomla
this is the main problem
what your machine does / did is attack 3rd parties and this is the most common what happens after intrusion and without your ISP having open yes you would still not know that it happened
and this is the reason why my reaction on malinglists to posts starzign with "i installed Fedora 14" is pure anger because it is unacceptable and i was there on the other side of a DDOS-Attack from many thousand ip's for nights and can tell anybody that it is no fun try to hold the business alive in such situations - you can be sure ALL of this thousands attackers where hijacked servers / clients with whatever OS
and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
the writeable is not the problem, how should they work readonly but make them accessable AND executeable from the web is a big mistake for several reasons:
* log: you do not want access to logfiles from outside * cache: you do not want get applications cache readed from outside * tmp: you do not want get temp-fiels of the application readed from outside
for any folder: you do not want to get executed code from outside which can be injected this affects also the log-file, i have seen attacks where php-code was in the requests and someone found a small injection leak and used the log file to prepare his whole script and execute it with the injection leak _________________________________________
i generally protect any log/temp/cache AND all folders where from users uploaded files (miages, pdf...) are stored with disable the php-engine and fro tmp/log deny access at all
"IfVersion" needs "mod_version.so" loaded and is used here to prepare a smooth upgrade to Apache 2.4 after mod_security acts correct with "mod_remoteip" behind a proxy
[harry@srv-rhsoft:~]$ cat /www/www.rhsoft.net/temp/.htaccess <IfModule mod_php5.c> php_flag engine off </IfModule> <IfModule mod_php6.c> php_flag engine off </IfModule> <IfVersion < 2.4> Order deny,allow Deny from all </IfVersion> <IfVersion >= 2.4> Require all denied </IfVersion>
Dear Reindl,
I am sorry if I gave a wrong impression, but I was reffering to the tmp, cache and tmp folders inside the joomla installation, not the OS or apache ones. The whole apache document root is owned by root and has a read-only selinux policy (apache cannot write anything in there). The only folders owned by apache and had rw selinux permissions, where the cache, log & tmp folder of the joomla installation (i.e. /var/www/html/joomla/tmp). This was the folder I found two php files that were executed by calling them though a POST http request.
Regards,
George
Στις 15/3/2013 2:30 μμ, ο/η Reindl Harald έγραψε:
Am 15.03.2013 12:16, schrieb Georgios Petasis:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. I know this is an old version of joomla
this is the main problem
what your machine does / did is attack 3rd parties and this is the most common what happens after intrusion and without your ISP having open yes you would still not know that it happened
and this is the reason why my reaction on malinglists to posts starzign with "i installed Fedora 14" is pure anger because it is unacceptable and i was there on the other side of a DDOS-Attack from many thousand ip's for nights and can tell anybody that it is no fun try to hold the business alive in such situations - you can be sure ALL of this thousands attackers where hijacked servers / clients with whatever OS
and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
the writeable is not the problem, how should they work readonly but make them accessable AND executeable from the web is a big mistake for several reasons:
- log: you do not want access to logfiles from outside
- cache: you do not want get applications cache readed from outside
- tmp: you do not want get temp-fiels of the application readed from outside
for any folder: you do not want to get executed code from outside which can be injected this affects also the log-file, i have seen attacks where php-code was in the requests and someone found a small injection leak and used the log file to prepare his whole script and execute it with the injection leak _________________________________________
i generally protect any log/temp/cache AND all folders where from users uploaded files (miages, pdf...) are stored with disable the php-engine and fro tmp/log deny access at all
"IfVersion" needs "mod_version.so" loaded and is used here to prepare a smooth upgrade to Apache 2.4 after mod_security acts correct with "mod_remoteip" behind a proxy
[harry@srv-rhsoft:~]$ cat /www/www.rhsoft.net/temp/.htaccess
<IfModule mod_php5.c> php_flag engine off </IfModule> <IfModule mod_php6.c> php_flag engine off </IfModule> <IfVersion < 2.4> Order deny,allow Deny from all </IfVersion> <IfVersion >= 2.4> Require all denied </IfVersion>
Am 15.03.2013 13:56, schrieb Georgios Petasis:
Dear Reindl,
I am sorry if I gave a wrong impression, but I was reffering to the tmp, cache and tmp folders inside the joomla installation, not the OS or apache ones
i am too
in your case this would even not had happend if it would have been /tmp of the OS beause it is not rechable from outside, not that i would let a web-app use /tmp which is shared with other apps and services
on the other hand with "PrivateTmp=yes" in the systemd-unit it would be pretty safe and NOT shared, but better have each docroot it's own temp-folders to isolate them with open_basedir
The whole apache document root is owned by root and has a read-only
which is good
selinux policy (apache cannot write anything in there) The only folders owned by apache and had rw selinux permissions, where the cache, log & tmp folder of the joomla installation (i.e. /var/www/html/joomla/tmp)
which is correct and needed the application needs write permissions there
This was the folder I found two php files that were executed by calling them though a POST http request.
i understood this well, but read my post again
i explained how to prevent POST and excute to such folders which should be done in any context to secure a web-app
the best location for such things is in reality OUTSIDE the docroot at all and have open_basedir contain the docroot and this folders outside and if possible put includes also outside the docroot
and if you would like get open_basedir really usable you should disable ANY function which can execute applications in the "php.ini" -> this DOES NOT work with "php_admin_value" perdir even if it is wrongly shown in phpinfo() as working
disable_functions = "popen, pclose, exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink, link"
with suhosin you have the possibility to work perdir but you can NOT allow a function which is contained in "disable_functions", i use all three everywhere php_admin_value suhosin.executor.func.blacklist ".........." php_admin_value suhosin.executor.eval.blacklist ".........."
Regards, George
Στις 15/3/2013 2:30 μμ, ο/η Reindl Harald έγραψε:
Am 15.03.2013 12:16, schrieb Georgios Petasis:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. I know this is an old version of joomla
this is the main problem
what your machine does / did is attack 3rd parties and this is the most common what happens after intrusion and without your ISP having open yes you would still not know that it happened
and this is the reason why my reaction on malinglists to posts starzign with "i installed Fedora 14" is pure anger because it is unacceptable and i was there on the other side of a DDOS-Attack from many thousand ip's for nights and can tell anybody that it is no fun try to hold the business alive in such situations - you can be sure ALL of this thousands attackers where hijacked servers / clients with whatever OS
and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
the writeable is not the problem, how should they work readonly but make them accessable AND executeable from the web is a big mistake for several reasons:
- log: you do not want access to logfiles from outside
- cache: you do not want get applications cache readed from outside
- tmp: you do not want get temp-fiels of the application readed from outside
for any folder: you do not want to get executed code from outside which can be injected this affects also the log-file, i have seen attacks where php-code was in the requests and someone found a small injection leak and used the log file to prepare his whole script and execute it with the injection leak _________________________________________
i generally protect any log/temp/cache AND all folders where from users uploaded files (miages, pdf...) are stored with disable the php-engine and fro tmp/log deny access at all
"IfVersion" needs "mod_version.so" loaded and is used here to prepare a smooth upgrade to Apache 2.4 after mod_security acts correct with "mod_remoteip" behind a proxy
[harry@srv-rhsoft:~]$ cat /www/www.rhsoft.net/temp/.htaccess
<IfModule mod_php5.c> php_flag engine off </IfModule> <IfModule mod_php6.c> php_flag engine off </IfModule> <IfVersion < 2.4> Order deny,allow Deny from all </IfVersion> <IfVersion >= 2.4> Require all denied </IfVersion>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/15/2013 09:18 AM, Reindl Harald wrote:
Am 15.03.2013 13:56, schrieb Georgios Petasis:
Dear Reindl,
I am sorry if I gave a wrong impression, but I was reffering to the tmp, cache and tmp folders inside the joomla installation, not the OS or apache ones
i am too
in your case this would even not had happend if it would have been /tmp of the OS beause it is not rechable from outside, not that i would let a web-app use /tmp which is shared with other apps and services
on the other hand with "PrivateTmp=yes" in the systemd-unit it would be pretty safe and NOT shared, but better have each docroot it's own temp-folders to isolate them with open_basedir
The whole apache document root is owned by root and has a read-only
which is good
selinux policy (apache cannot write anything in there) The only folders owned by apache and had rw selinux permissions, where the cache, log & tmp folder of the joomla installation (i.e. /var/www/html/joomla/tmp)
which is correct and needed the application needs write permissions there
This was the folder I found two php files that were executed by calling them though a POST http request.
i understood this well, but read my post again
i explained how to prevent POST and excute to such folders which should be done in any context to secure a web-app
the best location for such things is in reality OUTSIDE the docroot at all and have open_basedir contain the docroot and this folders outside and if possible put includes also outside the docroot
and if you would like get open_basedir really usable you should disable ANY function which can execute applications in the "php.ini" -> this DOES NOT work with "php_admin_value" perdir even if it is wrongly shown in phpinfo() as working
disable_functions = "popen, pclose, exec, passthru, shell_exec, system, proc_open, proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink, link"
with suhosin you have the possibility to work perdir but you can NOT allow a function which is contained in "disable_functions", i use all three everywhere php_admin_value suhosin.executor.func.blacklist ".........." php_admin_value suhosin.executor.eval.blacklist ".........."
Regards, George
Στις 15/3/2013 2:30 μμ, ο/η Reindl Harald έγραψε:
Am 15.03.2013 12:16, schrieb Georgios Petasis:
I suspect that it is a joomla 1.5.26 exploit. I have found two php files in the tmp folder of one web site, and POSTs to them in the apache access log file. I know this is an old version of joomla
this is the main problem
what your machine does / did is attack 3rd parties and this is the most common what happens after intrusion and without your ISP having open yes you would still not know that it happened
and this is the reason why my reaction on malinglists to posts starzign with "i installed Fedora 14" is pure anger because it is unacceptable and i was there on the other side of a DDOS-Attack from many thousand ip's for nights and can tell anybody that it is no fun try to hold the business alive in such situations - you can be sure ALL of this thousands attackers where hijacked servers / clients with whatever OS
and I have made the mistake to make the folders tmp, cache & log writtable by the apache in selinux...)
the writeable is not the problem, how should they work readonly but make them accessable AND executeable from the web is a big mistake for several reasons:
- log: you do not want access to logfiles from outside * cache: you do
not want get applications cache readed from outside * tmp: you do not want get temp-fiels of the application readed from outside
for any folder: you do not want to get executed code from outside which can be injected this affects also the log-file, i have seen attacks where php-code was in the requests and someone found a small injection leak and used the log file to prepare his whole script and execute it with the injection leak _________________________________________
i generally protect any log/temp/cache AND all folders where from users uploaded files (miages, pdf...) are stored with disable the php-engine and fro tmp/log deny access at all
"IfVersion" needs "mod_version.so" loaded and is used here to prepare a smooth upgrade to Apache 2.4 after mod_security acts correct with "mod_remoteip" behind a proxy
[harry@srv-rhsoft:~]$ cat /www/www.rhsoft.net/temp/.htaccess <IfModule mod_php5.c> php_flag engine off </IfModule> <IfModule mod_php6.c> php_flag engine off </IfModule> <IfVersion < 2.4> Order deny,allow Deny from all </IfVersion> <IfVersion >= 2.4> Require all denied
</IfVersion>
Do you have your SELinux logs. AVC? What ports were they able to connect to?
On Fedora 19 the only labels apache process is able to both write and execute is
sesearch -A -s httpd_t -p execute -c file -C | grep write DT allow httpd_t httpdcontent : file { ioctl read write create getattr setattr lock append unlink link rename execute open } ; [ httpd_enable_cgi httpd_unified && httpd_builtin_scripting && ]
So you would have to have httpd_unified boolean turned on?
getsebool httpd_unified httpd_unified --> off
It is off by default, and for most systems should probably be turned off, going forward.
On Mar 15, 2013 2:05 AM, "Georgios Petasis" petasisg@yahoo.gr wrote:
Hi all,
I have a small server that I have recently upgraded to fedora 18. After a
while, I got notified by
the provider that their firewall catches thousands of requests, with the
following error message:
Source IP: ellogon-SKEL Source Port: 35442 Destination IP: 216.82.176.7 Destination Port: 53 Description: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to
outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
I have verified all packages (with rpm -Va), and didn't see anything
strange.
It is strange that the machine is trying to contact a server in USA,
isn't it?
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they
remove the network cord from the server, so I have a few hours to debug this...)
George
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Let's clean up the language, shall we. It is not really my intent to be rude, but each of us "hack" out own systems and the kernel all the time. It might be much more helpful totitle this "My system has been invaded" because we all hack, but we do not crack note invade other systems; we are all "hackers", and none of us - hopefully - are criminals nor online-computer-invaders.
Please, and thank you,
Richard
Am 15.03.2013 16:25, schrieb Richard Vickery:
Is there anything else to do, than re-installing the machine?
(Unfortunately, due to the huge load it creates to their firewall, they remove the network cord from the server,
so I have a few hours to debug this...)
George
-- users mailing list users@lists.fedoraproject.org mailto:users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Let's clean up the language, shall we. It is not really my intent to be rude, but each of us "hack" out own systems and the kernel all the time. It might be much more helpful totitle this "My system has been invaded" because we all hack, but we do not crack note invade other systems; we are all "hackers", and none of us - hopefully - are criminals nor online-computer-invaders.
Please, and thank you
before you get pedantic please strip the next time your quotes and removed unneded lines, especially signatures and footers
On Fri, 2013-03-15 at 08:25 -0700, Richard Vickery wrote:
It is not really my intent to be rude, but each of us "hack" out own systems and the kernel all the time.
Unfortunately, this battle over the word "hack" and "hacker" has already been fought and lost. The media, and just about everyone other than hard-core geeks, uses the word "hack" to mean breaking into systems. So it is not realistic to try and get people to stop using it that way, even though us old geeks can remember when a "hacker" was someone worthy of respect rather than someone worthy of a jail cell.
Heck, that's why we co-opted the word "geek", which not that long ago was a very insulting term, and is now used as a term for people worthy of respect, similar to how "hacker" was used in the old days.
I suppose it is confusing that the meanings of these words have changed, but unfortunately the real meaning of a word is going to be defined by how it is most commonly used.
--Greg
On Mar 15, 2013 9:39 AM, "Greg Woods" woods@ucar.edu wrote:
On Fri, 2013-03-15 at 08:25 -0700, Richard Vickery wrote:
It is not really my intent to be rude, but each of us "hack" out own systems and the kernel all the time.
Unfortunately, this battle over the word "hack" and "hacker" has already been fought and lost. The media, and just about everyone other than hard-core geeks, uses the word "hack" to mean breaking into systems.
Not in my circles; I refuse to let people alternate the term.
Heck, that's why we co-opted the word "geek", which not that long ago was a very insulting term, and is now used as a term for people worthy of respect, similar to how "hacker" was used in the old days.
I suppose it is confusing that the meanings of these words have changed, but unfortunately the real meaning of a word is going to be defined by how it is most commonly used.
So change it!!! Don't let them beat you into the ground; correct them!
On 03/15/2013 02:05 AM, Georgios Petasis wrote:
*Source IP*: ellogon-SKEL *Source Port*: 35442 *Destination IP*: 216.82.176.7 *Destination Port*: 53 *Description*: Dropped UDP DNS request from dmz:ellogon-SKEL/35442 to outside:216.82.176.7/53; packet length 1400 bytes exceeds configured limit of 512 bytes
The first thing you want to do is block all outgoing traffic on that port. Second, search /etc for references to that port and/or IP address. I doubt that you'll find anything, but that's no reason not to try.
-
agraham -
Daniel J Walsh -
Ed Greshko -
Georgios Petasis -
Greg Woods -
Joe Zeff -
Mateusz Marzantowicz -
Michael Schwendt -
Reindl Harald -
Richard Vickery