Hi all, I need a little help from you guys. Does someone have a dedicatet internetserver and is running a iptables based firewall? regars Patrik Breitenmoser
Am 21.05.2002 10:14:28, schrieb Patrik Breitenmoser
Hi all, I need a little help from you guys. Does someone have a dedicatet internetserver and is running a iptables based firewall?
Why ? Do you've got a new xploit to play with ? :O) Michael
Hi.. Patrik Breitenmoser wrote:
Hi all, I need a little help from you guys. Does someone have a dedicatet internetserver and is running a iptables based firewall?
Internetserver is - for my understanding - a bit inacurate. I have servers on the internet that are for - mail handling (smpt, pop3 and imap protocal) - webserver (http and https + database (mysql) + php - ftp servers (ftp protocol) - backup servers (scp + ssh only) - application servers (apache running for serving webpages that are generated by applications that run in the background) Some of them are behind a firewall, others are not. So my answer to your question is yes and no. I have dedicated servers and mixed-purpose servers. But I dont quite understand your question still ;-)
regars Patrik Breitenmoser
Ciao, Erwin -- Erwin Zierler | web- / host- / postmaster - stubainet.at | erwin.zierler@stubainet.at / webmaster@stubainet.at | Tel.: 0 5225 - 64325 Fax 99 Mobil: 0664 - 130 67 91
* Erwin Zierler - stubainet.at wrote on Tue, May 21, 2002 at 12:09 +0200:
Patrik Breitenmoser wrote:
I need a little help from you guys. Does someone have a dedicatet internetserver and is running a iptables based firewall?
Let's say so: of course there are servers connected to the internet that are dedicated to something. Usually you won't have the onliest firewall on the same host, and a packet filter is not a real great security enhancement, since you block ports that are closed anyway (in ingress filtering), at least you shouldn't run unwanted services, and egress filtering isn't effective since it's possible to use DNS, HTTP, ICMP PING or whatever payload to transmit information. But AFAIK most trojans use direct connections but not payload other protocols. So it prevents maybe some script kiddies.
- mail handling (smpt, pop3 and imap protocal) - webserver (http and https + database (mysql) + php
Well, and if for instance PHP comes with another flaw, it may be easily possible to break in here, since php usually is used for "active pages" which are accessible by HTTP any by that not packet filtered. Well, and since most webserver local SQL server installations are accessible from PHP, they are accessible from the attacker usually also, after breaking the web server. Maybe you have set up a clear and restrictive database access if this is possible with mySQL, but usually an attacker can do harm here. Additionally, many PHP scripts don't validate input correctly, and most databases also (theoretically, it's possible to make databases more secure by the usage of stored procedures that verify their input - by that, it's possible to have the DBMS validating the requests, hum, and AFAIK that is a point what DBMS are for, but it's rarely used I think). So don't think you secured anything when you set up a firewall. Usually anthing it's gone if you have a bad coded, insecure PHP script running that can be exploited in some way. So you need to keep up to date with packages and so on, but even if you do, you may have a PHP insecure script, and since PHP usually isn't configurated to be executed via SuEXEC, the www server account is broken. Hum, and www server accounts can often read plain (SSL/TLS) RSA keys, so make sure to configure it correctly!
- application servers (apache running for serving webpages that are generated by applications that run in the background)
Same here; if you're running complex applications or such, chances are given that somewhere is a bug that could be exploited...
I have dedicated servers and mixed-purpose servers. But I dont quite understand your question still ;-)
:) I think you understood his question, but no why he need help. As least I do not understand :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
participants (4)
-
Erwin Zierler - stubainet.at
-
Michael Appeldorn
-
Patrik Breitenmoser
-
Steffen Dettmer