Trinoo_Master
Hello,
Ive just done a port scan on my self and found some interesting things, i used nmap and it came up with these . Code:
Port State Service last night , and since then all these extra ports are open. Code:
540/tcp open uucp im still :study: as i type this , but if someone could have a look at these ports and tell me whats what , and any ports i should close ,keeping in mind that im just learning about ports , and portsentry,any feed back i will greatfully accept. Regards AXO |
As root:
1) run "netstat -anp", and 2) correllate PID with process from running "ps", and 3) validate listening apps (md5sum, pkg manager, integrity checkers like Aide, Samhain or tripwire), and 4) download chkrootkit(.org) and scan (just in case). I bet it's just a portsentry and firewall configuration issue. |
G'day unSpawn , thanks for your quick reply .
i ran netstat -anp it showed nothing out of the ordinary from what i can tell anyway .(i could copy/paste it all here , but their's a hell of a lot ) Next i tried ps-A ,looked at all the PID's seamed ok. As for the md5sum ,this is where im finding a conflict of interest. Code:
AXO:/etc/portsentry# md5sum /usr/sbin/portsentry taken from here So has the download been tampered with ? I'm in the process of downloading chkrootkit now ,i'll be checking the md5sum before installing ,(if i can figure out how, some of those download without options) Regards AXO BTW is the tutorial still underway , the mailing list has been very quiet the last few weeks? |
ok after a little playing ,i found that i was using md5sum wrong.
Also i found that if i turn portsentry off , those ports are closed . So i gather that portsentry only has those ports open to for listen for trouble. I also tried chkrootkit , i did have a moment when i saw : Checking `bindshell'... INFECTED (PORTS: 1524 31337) but that was fine when portsentry was turned off. All in all i think its fine ,if someone has anything to add im all ears. Thanks Regards AXO |
i ran netstat -anp it showed nothing out of the ordinary from what
i can tell anyway . SOP would be to verify the "fingerprint" of the binaries showing, preferably using an integrity detection checker like Aide, Samhain or tripwire with the databases on ro media. This way you don't have to be able to "tell" if something is OK, but the integrity checker will be able to. Next i tried ps-A ,looked at all the PID's seamed ok. Uhhh. See above. BTW is the tutorial still underway , the mailing list has been very quiet the last few weeks? As far as I'm concerned, yes. Also i found that if i turn portsentry off , those ports are closed . So i gather that portsentry only has those ports open to for listen for trouble. If you *must* use Portsentry, check the different modes it can run with. I also tried chkrootkit , i did have a moment when i saw : Checking `bindshell'... INFECTED (PORTS: 1524 31337) but that was fine when portsentry was turned off. Yes, unfortunately wrt to that detection is not that strong. If you check the Bash script (or run inexpert mode "-x") you see it'll just grep the netstat-provided list of open ports in listening state for "31337". You should be aware you should not trust (the output of) tools on a running system too much w/o being able to verify the tool you are running actually *is* the tool you installed. *Everyone* should install and an integrity checker like Aide, Samhain or tripwire after installing the OS, and save the databases (and a copy of the binary) on ro media. That way you can achieve a higher level of trust wrt the ability to discover system anomalies. I know you're relatively new to Linux, and if you would be willing to answer, I'd like to ask you how/why you choose Portsentry over other portscan detectors? Features? Read article? Recommendation? Nothing serious, just curious why. |
Quote:
To cut a long story short , after fiddling around i thought it was time to have have a look at what ports i had open , so i had a trusted friend( who is a linux user ) do a port scan on me . after some help from him , i closed what ports (we) thought needed closing. He mentioned to me that i should have something like portsentry , he didn't mention any others , he also mentioned to have a look at /etc/hosts.allow and /etc/hosts.deny . which i havn't yet . I'm still trying to get my head around portsentry. So i guess i really i didn't really know about any others, and it was a spur of the moment thing to get portsentry . After reading your post , i will look at the others, except i'm not looking forward to setting up my tri-boot (Debian,RH,Windoze) system again. I understand now that i should have implemented something from the start, live and learn i guess . Thanks for your reply unSpawn . Regards AXO |
Quote:
All I've done is uncomment from the default settings. Code:
# These port bindings are *ignored* for Advanced Stealth Scan Detection Mode AXO |
Ok, cool. I deleted my portsentry configs a few yrs ago, but I vaguely remember something about some "advanced TCP/UDP stealth mode". There you wouldn't select specific ports to monitor but a range (or even all ports, can't remember). Dunno if this changed in the new release of Portsentry.
Also I think it would be best to turn off resolving hosts, it'll cost too much time. Resolve hosts manually later when you scan the logs and want to investigate certain "incidents". A twofold problem. The first "real" problem with portscan detectors like Portsentry that monitor specific ports is they open ports to listen on. This means the port is in use and can't be used by other applications, and besides that having something bound to and listening on a port you want closed is somewhat of a contradiction. The second "problem" is the "value" of a scan alert. If nothing is listening on the port, then what do you need to be alerted for? Portsentry doesn't scrub packets for malicious contents like Snort does. This means tripping a port is just that. OTOH take this off-site example of a possibly bad configured Apache proxy. Apart from the need to properly set up Apache with ACL's, Portsentry would only be able to detect someone triggering a connection, but would *never* be able to filter and alert on a packets contents to block CONNECT type. |
All times are GMT -5. The time now is 03:44 AM. |