Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Linux server monitoring web dashboard

github.com

Post reply on HN
Print view View original

51–60 of 70 posts

Re: Show HN: Linux server monitoring web dashboard

#51

Post by SnacksOnAPlane »

jdiez17 wrote: post #39
deanclatworthy wrote: post #36

Earlier quoted context omitted.

Unless the script accepts parameters, which it doesn't, there's nothing to worry about.

Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…

But you can totally audit the PHP code. There honestly isn't that much of it, and absolutely none of it takes user input. I'd be way more concerned if this was a Rails or Django app, because then there would be lots of library code to worry about.

Re: Show HN: Linux server monitoring web dashboard

#52

Post by jdost »

jdost wrote: post #44
k0 wrote: post #9

Not much different than conky...except the web service part. http://conky.sourceforge.net/

You could use the conky-cli build (without the X dependency). You could then run it and pipe the output into some file that you serve statically. Hmmm may spend some time investigating.

To follow up with this. You could add `conky -c json.conky | while read json; do echo $json > /opt/http/monitor/info.json; done` to your start. Then just static serve the `info.json` file and it should update at whatever interval you set for conky. No dynamic execution though (hard part is that lack of interaction).

Re: Show HN: Linux server monitoring web dashboard

#53

Post by kodablah »

jdiez17 wrote: post #37
kodablah wrote: post #32

Earlier quoted context omitted.

Some server side code is required to obtain the data. Out of curiosity, what would it have to be written in to make you feel safe?

In anything that is not PHP. Bash would have been perfect for this use case, for example. The correct way to do this is to obtain the data separately and merely show it on the interface. I haven't audited the code, so I don't know what's being passed to the shell commands, but the fact that an attacker MIGHT be able to influence the commands being executed (see register_globals, etc (yes, I know this has been disable…

First you say anything not PHP then you don't mention one. While I agree that off-request collection may be wiser, I fail to see anything mentioned better than PHP unless you're seriously mentioning Bash to write a webapp like this. Mentioning an old security concern that is no longer an issue seems like an easy way to discount every possible language.

Re: Show HN: Linux server monitoring web dashboard

#54

Post by jdiez17 »

kodablah wrote: post #53
jdiez17 wrote: post #37

Earlier quoted context omitted.

In anything that is not PHP. Bash would have been perfect for this use case, for example. The correct way to do this is to obtain the data separately and merely show it on the interface. I haven't audited the code, so I don't know what's being passed to the shell commands, but the fact that an attacker MIGHT be able to influence the commands being executed (see register_globals, etc (yes, I know this has been disable…

First you say anything not PHP then you don't mention one. While I agree that off-request collection may be wiser, I fail to see anything mentioned better than PHP unless you're seriously mentioning Bash to write a webapp like this. Mentioning an old security concern that is no longer an issue seems like an easy way to discount every possible language.

I said that a bash script would be perfect for collecting data periodically and saving it to a file, I wasn't suggesting that you use it to write a web app. I thought that was clear; apologies if it wasn't.

However, you say that this is an easy way to discount every possible language: can you point me to a vulnerability on the same level as register_globals in any other language?

Re: Show HN: Linux server monitoring web dashboard

#55

Post by e12e »

condiment wrote: post #34
jdiez17 wrote: post #31

The interface looks very nice but no thanks, I'm not going to install PHP on my servers to have it. I'd totally set it up if it weren't for PHP. The risk is just too great to ignore.

I had the same attitude, so I forked it and rewrote the PHP endpoints as a Python script, which I execute outside of the context of the application via a cronjob. https://github.com/arbuckle/linux-dash

Thanks, this architecture makes more sense imnho. Between this and the other thread on monitoring solutions, I wonder if it would be worth it to write a snippet that takes data from sar [ed:sar/sysstat or perhaps conky] and dumps out json that works with this dash...

Re: Show HN: Linux server monitoring web dashboard

#56

Post by anglebracket »

jdiez17 wrote: post #39
deanclatworthy wrote: post #36

Earlier quoted context omitted.

Unless the script accepts parameters, which it doesn't, there's nothing to worry about.

Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…

> WRONG. Because you have to use mysql_REAL_escape_string.

Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli.

> The point is that I can't audit (and would rather not waste my time doing so) this PHP code.

I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the Content-Type header isn't set to 'application/json' so PHP decides to set it to 'text/html'. Now anyone that controls ipecho.net[0] or can execute commands as any user on the server[1] can XSS users of the panel.

If you'd like to confirm, go to /sh/ps.php and notice where the page breaks due to strings in the JSON being interpreted as HTML.

[0] https://github.com/afaqurk/linux-dash/blob/master/sh/ip.php#...

[1] https://github.com/afaqurk/linux-dash/blob/master/sh/ps.php#...

Re: Show HN: Linux server monitoring web dashboard

#57

Post by anglebracket »

SnacksOnAPlane wrote: post #51
jdiez17 wrote: post #39

Earlier quoted context omitted.

Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…

But you can totally audit the PHP code. There honestly isn't that much of it, and absolutely none of it takes user input. I'd be way more concerned if this was a Rails or Django app, because then there would be lots of library code to worry about.

It doesn't take input from the user, but it does use untrusted input in a way that allows XSS. See https://news.ycombinator.com/item?id=7128442 .

Re: Show HN: Linux server monitoring web dashboard

#58

Post by gprasanth »

carbocation wrote: post #12

I believe the memory assessment will always show basically no free memory due to Linux's memory management and caching. It would make more sense to subtract out the cache to see what's really used and what's just being (smartly) cached.

Just linking for anyone wondering. http://www.linuxatemyram.com

Re: Show HN: Linux server monitoring web dashboard

#59

Post by deanclatworthy »

jdiez17 wrote: post #39
deanclatworthy wrote: post #36

Earlier quoted context omitted.

Unless the script accepts parameters, which it doesn't, there's nothing to worry about.

Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…

What you are talking about are core language decisions. Good developers have known how to work around register globals for years now, and it's not been a problem in any modern web app I've touched for the last 8 years (off the top of my head).

The language being used here has absolutely nothing to do with the output. You could substitute the PHP shell_exec calls for something similar in python, ruby or any other language. You should audit anything that hits your server. Using PHP doesn't meant it's more susceptible to vulnerabilities.

Re: Show HN: Linux server monitoring web dashboard

#60

Post by deanclatworthy »

anglebracket wrote: post #56
jdiez17 wrote: post #39

Earlier quoted context omitted.

Like I said in a previous reply, see register_globals and company. Sure, that was some time ago. Sure, the defaults are better now. But at some point in time the people in charge of PHP thought "yes, this is a good idea, let's do it". ... It's not like the attitude has changed, though. There are many, many things deeply wrong with PHP when it comes to security. PHP is supposed to cater to unexperienced programmers. A…

> WRONG. Because you have to use mysql_REAL_escape_string. Using mysql_real_escape_string is almost a sign you're doing something wrong. You should be using prepared statements with PDO or mysqli. > The point is that I can't audit (and would rather not waste my time doing so) this PHP code. I wasn't going to bother, but this post is pretty high up on the front page. There's some XSS issues with the JSON output, the C…

But the XSS issues have nothing to do with the language choice. Python, ruby and any other langauge do nothing by default to protect you against such things either.

I agree this is a poor choice of code, and an attack vector, but the language used here is not to blame.

Post reply on HN