I agree, and apologize for the annoyed tone I had earlier. Got my featheres ruffled over the issue of 'trust', and need to lighten up on the way it's handled on AO.
When in rome... lol
Printable View
I agree, and apologize for the annoyed tone I had earlier. Got my featheres ruffled over the issue of 'trust', and need to lighten up on the way it's handled on AO.
When in rome... lol
ok so here's the lowdown
GA put up an PGP encrypted message between myself and him with a disclaimer on the server.
Personally I only have the time and will to investigate what it's running. I'll post the results and let anyone involved figure it out.Quote:
*** PGP SIGNATURE VERIFICATION ***
*** Status: Good Signature from Invalid Key
*** Alert: Please verify signer's key before trusting signature.
*** Signer: guardian alpha <guardianalpha@gmail.com> (0x28399EAB)
*** Signed: 2/26/2005 4:38:51 PM
*** Verified: 2/26/2005 4:41:15 PM
*** BEGIN PGP DECRYPTED/VERIFIED MESSAGE ***
Welcome. The wargaming that I am hosting is not a true wargame, as we are not going for points or awards. This entire project is so I can relearn the basics of linux security and get the methodology back into memory. What does this mean from you all? You need to attack the server. root it. Exploit it. The only thing you can not do is DoS or DDoS it, due to how uncomfortable it seems to make the other members of AntiOnline ;) There are no other rules of "what you can not do" because I need you to preform every exploit in the book.
The ONE rule is this:
Report everything you are doing to the forum thread found here:
http://www.antionline.com/showthread...hreadid=266400
Report information you find, even if it is just what OS I'm running. Report what attacks worked, and how you did them. Report what attacks didn't work. The more information you post, the more other people can use it to springboard from there. IF someone has already posted an exploit method or discovered information about the server, then obviously you don't need to repeat them. The more you show what you are doing, the more I can relearn the security of a linux server (versus a workstation).
I give permission to preform exploits and root tactics, as well as information gathering upon my linux server. This is being read and approved by edited! for verification.
Server IP: http://edited!/
* IP may change since it's hosted on a pseudo dynamic ISP, but the change is very rare. Just a heads up. Look back here in case you get connection problems for the new IP.
*** END PGP DECRYPTED/VERIFIED MESSAGE ***
GA... I'm not sure how you plan on adding attackers to the game, this process would mean that members would have to trust me. And I'm under investigation :D
Also, to what extent will you be securing this server? Will it be just a one service wonder or are you going to make it a challenge for yourself?
As a side question, is this strictly a remote thing (checking remote/network connectivity security), a website security issue (remote with script issues) or are you giving the "attackers" local accounts?
Quote:
Also, to what extent will you be securing this server? Will it be just a one service wonder or are you going to make it a challenge for yourself?
The services that are running will be the services that I typically use to access my servers: ssh, ftp, and apache. No extra accounts for shits and giggles, so that means one normal account and one root (obviously so I won't have to log directly into root). The current setup it has is a stock version of the OS, unmodified from origonal installation content. What I plan on doing is just letting you all take potshots at the services, ip stack, user account/passwords, and so forth. Each step, report what you did, what information you found, and then we discuss how I can prevent/protect against that.Quote:
As a side question, is this strictly a remote thing (checking remote/network connectivity security), a website security issue (remote with script issues) or are you giving the "attackers" local accounts?
Webserver attacks, user attacks, even brute force. I have been away from linux too long and want to relearn it based upon what you all can do against it. It's not a wargame in the sense of "OMFG you won!", just similar in terms of letting people have a fun/legal time by attempting variou exploits against a remote server. In the process, I get to improve my defensive security skills :)
As for those who wish to join, they will each have to go through the same process as Soda. Let me know you want to join, you need a PGP or GNuPG key of your own, and then I will ask for your current IP and send the release(what soda quoted) form to you in it's encrypted format. I don't keep track of IP's, merely because I don't expect people to do anything directly, just through proxies instead. So the basis for the verification is just to prove to each person that I do own the server and grant them full permission of usage.
Some nmap and fingerprinting
Quote:
22/tcp open ssh
25/tcp open smtp
37/tcp open time
80/tcp open http
113/tcp open auth
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
587/tcp open submission
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
It's running:Quote:
PORT STATE SERVICE
37/udp open time
135/udp filtered msrpc
138/udp filtered netbios-dgm
1400/udp closed cadkey-tablet
OpenSSH 3.9p1 which is the latest release
Sendmail 8.13.3 also latest //tutorial.localhost.org, on 2 ports, doesn't allow relaying
Time on 37 tcp udp
Apache/1.3.33 alsot latest //Latest, won't give away much on OS
Anyone have any tools or techniques for 113/tcp auth? nmap -I isn't supported anymore. Also, nmap -O wasn't much help.
Remember, all of this is the defafult configuration setups so I have not begun secure the box.
What did nmap -O return?
Also looks like I need to start closing up those services. Wasn't aware of them some of them running, like time. Also how does it know that those services ARE running, but are in filtered mode?
I know that most senior members know their sh*t. I just believe that this may be a good learning tool for us who may not know their stuff so well. I (personally) trust Soda. I will ask to be a part of this, because I am always willing to learn a thing or two. I know that http://www.rootthisbox.org or http://www.hackthissite.org can be good resources for this type of learning, but the problem with those sites is that they give you no explination as to how they exploited/defended a given attack. It's just attack and see who can do it. I believe in the principle that if you exploit or gain access, you should disclose it for the good of the (responsible) community. In order to defend against an attack, you must first know how it works. To be a white hat, know how blackhats think. These are just one man's (kinda drunk) ramblings. :D
dmorgan, all you need now is a PGP or GnuPG account. If you need help getting one, say the word.
Would love to have you on board :)
I learned something about nmap today- Don't do -O unless you are scanning all ports... it's not accurate.Quote:
Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-26 23:22 Central
Standard Time
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
(The 1649 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
37/tcp open time
80/tcp open http
113/tcp open auth
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
587/tcp open submission
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
Uptime 1.116 days (since Fri Feb 25 20:49:25 2005)
Odd, all it really needs is one guarenteed blocked port and one guarenteed open port. Granted, maybe the more comparisons it has the better. Side note, I wonder which ports (stupid me) are from the one other computer behind the router? No one is running any sort of servers/services besides my singular linux server, but that may explain the filtered 139-443?Quote:
I learned something about nmap today- Don't do -O unless you are scanning all ports... it's not accurate.
Remember, this server is on the DMZ. So anything not valid is passed to it, and thus the windows machine (roommates) that is not on the DMZ and completely behind the router.. may be the one with those ports being filtered. I'll do a check on the server tonight, as I have no idea if linux could even be bothered with the NetBIOS ports.
And do you think that nmap is reporting errors because of router delay, even though the server is on DMZ?