linux security wargame testing. interested?

I've just setup a server behind my router that I intend to spend quite a bit of time on, relearning the linux configurations. Took too long of a break and need to get back into the swing of things.

This is where you all come in. Right now, I have it up and running on the DMZ of my network and awaiting people to crack it. DoS it, DDoS it, root it, disable services. Anything basically. The more attacks you preform, the better I can learn how to defend against them in the future. The more attacks you succeed in, the better I can understand how you accomplished the exploit.

So, if you are interested in helping me relearn linux-based security, post here so I can invite you to join the private conference room here at AO. In that conference room we will keep everyone updated on what exploits you are running, methods you are using, and information you've discovered that will help others in their attempts. The more you tell everyone on that board, the better we can understand how you did it, and the better chance you have of helping me learn hoow to circumvent the attack you preformed.

Any further questions or interest in joining, comment here :)

Depending on the setup, sure. With some details and a way to prove you have permission and own the box, of course.

yeh im in but as soda said you will have to prove that you have permision

I will have to see his posting providing he has ownership and permission of the Ethernet connection, the box, and has legal access to this location mundanely and or over the internet. I have seen challenges like this before, but still await a public anouncement of actual proof.

Without Sin

Christ, if this isn't annoying to hear. Much less have two people repeat it.

I will be pming Soda after I edit the index.html to show I have complete ownership of the server, by giving him the IP to request modifications to the index.html. No way in hell I'm going to give the IP to people who have a stick up their ass, just for proof.

Of course, logically done, if this was an attempt to make people attack an innocent server, why on earth would I create a thread about it in AO? To trick you? Pfft.. seriously guys.

Quote:

---

Of course, logically done, if this was an attempt to make people attack an innocent server, why on earth would I create a thread about it in AO? To trick you? Pfft.. seriously guys.

---

But that the art of deception, build trust and then trick people into doing something that you want and they may get into trouble for. IMO, I don't think it's an unreasonable request since many people can't meet with you in person and get a written, signed document that says people can attempt to break in. You may be very trusting and honest but not everyone that visits here is.

Just a thought.

Yeah. That, and you may also need to notify your ISP, and chances they may forbid you to do that. They may do casual traffic monitoring, and a sudden high and suspicious traffic may trigger an alert. Remove DoS/DDoS from your "list" and you'll be safer. Wargame is supposed to be played on isolated private LAN.

Just another thought.

Peace always,
<jdenny>

Quote:

---

Originally posted here by guardian alpha
Christ, if this isn't annoying to hear. Much less have two people repeat it.

I will be pming Soda after I edit the index.html to show I have complete ownership of the server, by giving him the IP to request modifications to the index.html. No way in hell I'm going to give the IP to people who have a stick up their ass, just for proof.

Of course, logically done, if this was an attempt to make people attack an innocent server, why on earth would I create a thread about it in AO? To trick you? Pfft.. seriously guys.

---

Guardian, don't take it personally, but really...we don't know you from Adam. I'm going to go out on a limb here and assume you aren't a professional Security Engineer/Analyst/Administrator. You have to realize that those of us who perform vulnerability assessments and penetration tests for a living have a strict guideline on what must be procured from the owner of the system before ANYTHING is done. A lot of legal mumbo jumbo, basically, that says "you may do whatever to my system to try and break in and I won't sue you or call the cops". It's our version of the get out of jail free card from Monopoly.

THAT's why it's coming up repeatedly. Those of us who may NOT do this for a living, but know how and are willing to help, those guys and gals MUST be assured that they aren't being duped into attacking a system under the guise of 'helping someone learn'. This is a much more common request than one would think, and the folks who are wanting to help can easily be portrayed as malicious by the wrong people. It's a defense mechanism.

Quote:

---

Hats are obvious, behavior isn't. And what is white to one person may be gray to another.
[i]--Gene Spafford, 2002

---

/* edit */

I'd be very happy to help as well, pending the considerations mentioned by others.

MsMittens, zencoder. I do understand where you are coming from, please know that. But I'm coming from such a close-knit community of network security operatives that something as childish as "fooling" people into attacking a server they don't own, isn't going to cross our minds. We just have better things to do than fake out members we help every day.

I've sent a GnuPG encrypted index.html file to the server, which Soda Pop has the ability to decrypt once he has obtained the public key of mine, which is in his PM box.

After he registers my gnupg key and decrypts the file on the webserver, he should AFAIK be coming back to let everone know the coast is clear.

Quote:

---

MsMittens, zencoder. I do understand where you are coming from, please know that. But I'm coming from such a close-knit community of network security operatives that something as childish as "fooling" people into attacking a server they don't own, isn't going to cross our minds. We just have better things to do than fake out members we help every day.

---

That's fine. But this is a 60,000+ member forum. While there are some closer ties with some, it's not always the case and there are no guarantees. As the saying goes, caveat emptor ;)

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.

Quote:

---

*** PGP SIGNATURE VERIFICATION ***
*** Status: Good Signature from Invalid Key
*** Alert: Please verify signer's key before trusting signature.
*** Signer: guardian alpha <[email protected]> (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 ***

---

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.

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?

---

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?

---

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.

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

---

Quote:

---

PORT STATE SERVICE
37/udp open time
135/udp filtered msrpc
138/udp filtered netbios-dgm
1400/udp closed cadkey-tablet

---

It's running:
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 :)

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)

---

I learned something about nmap today- Don't do -O unless you are scanning all ports... it's not accurate.

Quote:

---

I learned something about nmap today- Don't do -O unless you are scanning all ports... it's not accurate.

---

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?

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?

Soda, do me a favor? Paste the command you used when scanning my server with Nmap, but omit the IP. That way people can see what you did to gather that information.

Closed a few unneeded services that you found via nmap, by editing a few lines in /etc/inetd.conf. Now, correct me if I'm wrong, but the inetd is considered the "super daemon" in that it handles the loading and controls towards the majority of all system daemons running on the system? Regardless, it's configuration on which services to load (or which services are loaded by inetd at least) is the /etc/inetd.conf

Changed:

Quote:

---

# chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#

---

To comment-out the time service from loading. Ended up like this.

Quote:

---

# chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal
#

---

To the uninitiated, a # in a configuration file usually means that it is a 'comment line'.

Example:
# The code below preforms a binary cmd5 checksum
code code code
blah blah

So basically we just commented out the time service from loading, both on tcp and udp. Also disabled the 'comsat' service, which seems to report the logged in user of incoming mail. Looks like it means incoming system mail versus IMAP or pop, per say. Also, reports are that it is very insecure, so I've disabled it from /etc/inetd.conf by commenting out it's UDP line, like I did with the time service. AFAIK, the 'time' service itself is not exploitable due to it's limited nature. Can anyone confirm this or find documentation (couldn't find it on a brief google) of the time service being a security hazard? Granted, even if it isn't I don't want to run services I won't need.

Also can't find much about the comsat service being insecure, besides people just saying that it is insecure. Any past history you guys have of it's insecurities?

A question for everyone though, I left the auth service enabled in inetd.conf because I can't seem to find a straight answer on what it does. It is based on TCP, and the config file says it is a n ident service used for net authentication. Authentication for what though? SMTP? Htto? SSHd? Anyone know what it's for, and if it is something I should disable or not? I won't be disabling it until I know for sure what it does, and what danger it poses to me. I've read a few places that servers like an IRC server would require it for user authentication. Possible that ftp and ssh would require it as well?

Also rebooted the server to reflect inetd configuration changes. Not sure how to restart the inetd daemon safely without just rebooting.

edit: found out how to restart inetd without a complete machine reboot:

1. Find the process number: ps -e | grep inetd

Quote:

---

root@tutorial:/etc# ps -e | grep inetd
873 ? 00:00:00 inetd

---

2. Kill the process number with a HUD signal: kill -HUP 873

Definition: -HUP signal The HUP syntax for the kill command will tell the process you identified (in this case, process 873) to murder all of it's children processes (the processes and services that it created/started). This means it will terminate time, comsat, and everything else it started, but the process you identified will remain intact. After it's killed all the children processes, it re-reads its configuration files and re-opens any log files. Then it spawns a new set of children and continues serving merrily on it's way.

nmap targetIP -O -P0

auth is to provide a degree of authentication through mapping local usernames to TCP network ports in use. Example is when a user logs into IRC, a request is sent to auth to retrieve the users current login name. Got that from an O'Reilly.

Nmap used to be able to enumerate services better with auth by showing you the owner of a service from a port scan. However it doesn't support -I anymore, like my other post.

So why were / are there 2 ports with sendmail?

results again

Quote:

---

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 03:10 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
Interesting ports on
(The 1650 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
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

---

Thanks for the rescan and information on auth. Sounds like it might be required for sshd and ftpd after all.

Sendmail? Sendmail is running yes but I only see SMTP running. What is the second one you are speaking of? And to answer your question, sendmail was running because I did not turn it off during the default installation. I'll worry about turning off sendmail and SMTP tomorrow though. Things to get done today.

Anything you feel is exploitable so far? Comsat and time are the only two things I've changed from the default installation.

C:\>nc target 25
220 tutorial.localhost.org ESMTP Sendmail 8.13.3/8.13.3; Sat, 2 Jan 1999 07:47:2
8 -0700
^C
C:\>nc target 587
220 tutorial.localhost.org ESMTP Sendmail 8.13.3/8.13.3; Sat, 2 Jan 1999 07:47:4
2 -0700
^C

As far as being exploited, jidentd and cidentd have a reputation of vulnerability. I put a huge string into it, and it didn't throw any errors. However, when I put a small string into it, it throws an error:

C:\>nc target 113
asdf
0 , 0 : ERROR : UNKNOWN-ERROR

C:\>nc target 113
really long string
C:\>

########EDIT

Hello again

I found a vuln test for identd, and it's saying you're vulnerable! It's nothing major except private info though.

Quote:

---

Plugin ID: 152
Plugin name: identd detection
Plugin protocol: tcp
Plugin port: 113
Bug severity: Low
Bug affected: identd service
Bug not affected: Other services
Bug vulnerability class: Configuration

Bug description: The remote host is running an ident (also known as 'auth') daemon. The 'ident' service provides sensitive information to potential attackers. It mainly says which accounts are running which services. This helps attackers to focus on valuable services (thoseowned by root).

Bug response:

0 , 0 : ERROR : INVALID-PORT



Bug solution: The server should be deactivated or de-installed if not necessary. Under Unix systems, comment out the 'echo' line in /etc/inetd.conf and restart the inetd process. Try to prevent unwanted connection attempts by filtering traffic with firewalling.

Source CVE: CAN-1999-0629
Source Nessus ID: 10021


I doubt it was a buffer overflow but it could be if the service is old.

---

Tool I used was called attack tool kit.

Before you do anything about it, let me try to work with auth a little bit. I can't get what's outlined in the RFC's to work.
http://www.faqs.org/rfcs/rfc1413.html

Soda, very very interesting. Keep pecking away at auth and tell me what you get. Also, I need you to actuall try and exploit that identd bug. Because if it's a false positive then that isn't going to help us.

Looks like you're running a silc server now...

And why are you running mail on 2 ports!?!? Or am I missing something really stupid.

As for the identd testing... if I had time and a good lead on where to start, I'd go for it. There are nix tools for scanning it, identfp is one, but I don't have the means of running it right now. I'll see if it runs on cygwin later.

Is this OpenBSD Mr. Guardian? :)
Don't quote me on that, your identd service appears to be from OpenBSD?

nmap target -sV -sR -P0 -vv -O

Quote:

---

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 14:47 Central
Standard Time
Initiating SYN Stealth Scan against target () [1663 ports] at 14:47
Discovered open port 113/tcp on target
Discovered open port 25/tcp on target
Discovered open port 22/tcp on target
Discovered open port 80/tcp on target
Discovered open port 706/tcp on target
Discovered open port 587/tcp on target
The SYN Stealth Scan took 11.63s to scan 1663 total ports.
Initiating service scan against 6 services on target
(target) at 14:47
The service scan took 101.16s to scan 6 services on 1 host.
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Host target (target) appears to be up ... goo
d.
Interesting ports on target (target):
(The 1649 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.3/8.13.3
80/tcp open http Apache httpd 1.3.33 ((Unix))
113/tcp open ident OpenBSD identd
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 smtp Sendmail 8.13.3/8.13.3
706/tcp open silc
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
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=29F236%IPID=Z%TS=100HZ)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)

Uptime 0.442 days (since Sun Feb 27 04:12:52 2005)
TCP Sequence Prediction: Class=random positive increments
Difficulty=2748982 (Good luck!)
TCP ISN Seq. Numbers: 7CE2B3FE 7C594659 7D09673B 7CBB987A 7CFD07AE 7C6CD364
IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 114.984 seconds
Raw packets sent: 1738 (69.8KB) | Rcvd: 1682 (77.8KB)

C:\nmap>

---

A couple of questions for everyone. How does nmap get uptime, and how did it determine that identd was from OpenBSD? The RFC's don't talk about getting a banner of any kind.

Quote:

---

Looks like you're running a silc server now...

---

Correct, wanted to learn how to operate a SILC server and am loving it :)

Quote:

---

And why are you running mail on 2 ports!?!? Or am I missing something really stupid.

---

I don't think it's actually running on two ports. I think you have normal SMTP and them a subsystem of sendmail for some reason. I'll look more into it.

Quote:

---

Is this OpenBSD Mr. Guardian? :)
Don't quote me on that, your identd service appears to be from OpenBSD?

---

Nope, it is not OBSD.

Quote:

---

A couple of questions for everyone. How does nmap get uptime, and how did it determine that identd was from OpenBSD? The RFC's don't talk about getting a banner of any kind.

---

There is a option field in the tcp header. There are lots of different options you can choose between, (these you can read about in for example RFC 1323). One of these options are Timestamp. There is no what I know of "must" how to implement the timestamp option, but to citate Richard Stevens:

"4.4BSD increments (and linux similar) the timestamp clock once every 500 ms and this timestamp clock is reset to 0 on a reboot"

"The timestamp is a monotonically increasing value. Since the receiver echoes what it receives, the receiver doesn't care what the timestamp units are. This option does not require any form of clock synchronization between the two hosts. RFC 1323 recommends that the timestamp value increment by one between 1 ms and 1 second."


I have completely disabled my server from reporting uptime by running the command:

Code:

---

echo 0 >> /proc/sys/net/ipv4/tcp_timestamps

---

This will set the variable in tcp_timestamps to 0, effectively turning off the RFC 1323 TCP uptime reporting. Scan me again and see if uptime is still reported.

edit: I also added that echo command to /etc/rc.d/rc.local so that it will automagically tell the kernel to not report it if/when the server needs to reboot, since the setting isn't saved upon reboot. Granted, this feels like a horrible hack, but I bet the true setting is within the kernel configuration. I'll look into that later

Quote:

---

C:\nmap>nmap target -sV -sR -P0 -vv -O

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 15:28 Central
Standard Time
Initiating SYN Stealth Scan against target [1663 ports] at 15:28
Discovered open port 22/tcp on target
Discovered open port 80/tcp on target
Discovered open port 25/tcp on target
Discovered open port 113/tcp on target
Discovered open port 587/tcp on target
The SYN Stealth Scan took 15.64s to scan 1663 total ports.
Initiating service scan against 5 services on target) at 15:28
The service scan took 5.22s to scan 5 services on 1 host.
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Insufficient responses for TCP sequencing (0), OS detection may be less accurate

For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Insufficient responses for TCP sequencing (3), OS detection may be less accurate

Host target appears to be up ... good.
Interesting ports on target:
(The 1650 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.3/8.13.3
80/tcp open http Apache httpd 1.3.33 ((Unix))
113/tcp open ident OpenBSD identd
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 smtp Sendmail 8.13.3/8.13.3
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
No exact OS matches for host (If you know what OS is running on it, see http://w
ww.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.81%P=i686-pc-windows-windows%D=2/27%Tm=42223B8B%O=22%C=1)
TSeq(Class=RI%gcd=1%SI=2649B3%IPID=Z%TS=U)
T1(Resp=Y%DF=Y%W=16D0%ACK=O%Flags=A%Ops=)
T1(Resp=Y%DF=Y%W=16D0%ACK=S++%Flags=AS%Ops=MNW)
T2(Resp=N)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16D0%ACK=O%Flags=A%Ops=)
T3(Resp=Y%DF=Y%W=16D0%ACK=S++%Flags=AS%Ops=MNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)


IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 34.625 seconds
Raw packets sent: 1766 (71.5KB) | Rcvd: 1738 (83.6KB)

C:\nmap>

---

Good! No more uptime reporting :)

Now, I'm disabling the sendmail daemon since I will not be hosting a mail server. Went into /etc/rc.d/rc.M and checked to see how it loaded up sendmail.

Code:

---

# Start the sendmail daemon:
if [ -x /etc/rc.d/rc.sendmail ]; then
  . /etc/rc.d/rc.sendmail start
fi

---

What this means, is if rc.sendmail is set with permissions to be executable, then run the rc.sendmail daemon script. So, all I had to do was turn off executable permissions on the rc.sendmail script. But before that, let's turn off the sendmail daemon.

I also shut off the sendmail service manually, so I wouldn't need to reboot.

Code:

---

/etc/rc.d/rc.sendmail stop

---

Now with that done, let's make sure sendmail doesn't autoload on next reboot.

Code:

---

chmod 644 /etc/rc.d/rc.sendmail

---

Doing that will turn off executable capability for root, the root group, and everyone else. And will only allow read access to root group and everyone else, but read AND write to root. This will stop the service from autoloading.

GA, based on an experience I did on a linux "abuse" box, you might want to remove sendmail completely. Eventhough they weren't running a SMTP server (it wasn't a running service) it could still be locally vulnerable (not sure to what point your security level/desire is) as it's often used for mail between users locally.

Msmittens I will certainly consider that. I'm not going to do an entire lock down, but it never hurts to secure the box to it's upmost capability. Could you go a bit more in depth on how sendmail could be exploited locally, even if the daemon is not running? Give those other people who may be watching this thread a good idea on what to look for in their own machines.

Hrmm... it was a while ago but I believe it was a prescan() buffer overflow exploit that I ran across. It was a bit funny since it was a demonstration to students (made it a little too easy) and literally gave me root on the box even though the machine wasn't running sendmail officially. Just by virtue of it being used to send mail between users locally meant the system could be compromised. The original C code should be searchable on Packet Storm Security

Server seems to be down for some odd reason. Roommate probably turned it off (sob), and I'm away from my house right now so I'll see what I can do in a few hours.

Server is back up and running. Also completely removed the sendmail package from the system.