First and foremost, the TCP Prediction Sequence rating has nothing to do
with the difficulty determining what O/S you are running. The way nmap's o/s
fingerprinting works is by probing a systems tcp/ip stack and watching how
it responds. For example, one probe nmap uses is the finnish (FIN) probe.
Nmap will send a a FIN packet to the target machine without ever sending a
synchronize (SYN) or acknowledge (ACK) packet. According to the RFCs, The
correct way to respond to this is simply drop the packet. However many
implementations such as windows, bsdi, cisco, hpux, and irix will send a
RESET back. Nmap can also check how the system responds to bogus flags,
fragmentation, tcp options, etc,etc. Combining several of the probes
together and you get a good idea of what the system is most likely running.
Now one of the probes is TCP/IP Sequence prediction sampling. However, its
difficulty rating is not showing the difficulty of determining what O/S is
runnig, but how difficult it is to guess the next sequence number. Old
systems used to increment by 64k and 128k per connection. Some systems like
windows increment based on time intervals. And some systems like linux use
random sequence numbers. Initial random sequence numbers makes it extremely
difficult (impossible) to determine the next sequence number and perform an
ip spoofing/hijacking attack. For a while some friends and I were debating
whether or not you could deplenish the pool of random numbers down to a
certain number (x) low enough to then have many connections each with a
possible sequence number left in the pool and hope one gets lucky and gets
the right number. We ran into some problems with this though and never
implemented the idea.
anyway,
rather than running nmap to determine what ports are actively open, just
issue a netstat -a and look for listen states in the last field on the
right.
The inetd superserver allows one daemon to invoke other daemons to reduce
system load. That doesnt mean however that it governs all remote services.
Killing inetd does not guarantee you've killed all remote services. check to
see if you are running portmap(rpc.bind) which governs all rpc services. to
do this issue rpcinfo -p localhost and see if anything is running. I cant
see any reason you would need to be running this, so if it is, kill it. Many
services are also usually running as standalone such as httpd, sendmail.
Again the easiest way to determine what daemons are listening for
connections on your machine is to issue a netstat.
Portsentry is a very cool program. But you should always assume everything
is vulnerable. Just because a program is a security package, does not mean
the package has no problems of its own. We've seen problems with portsentry
in past versions such as dos vulnerabilities and the recent remote root
compromises in other security packages such as big brother.
----- Original Message -----
From: "Nolan Darilek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 02, 2000 2:07 PM
Subject: More security questions
> Since I've moved back onto campus and left my nice cozy firewall
> behind, I'm paranoid about security again. :)
>
> First I ran nmap on my host, checking all open ports and making sure
> no sneaky root access daemons were running. Looks like I'm safe; most
> of my open ports seem to be owned by portsentry. I decided to try -O
> out of curiosity, and here's what I received:
>
> TCP Sequence Prediction: Class=random positive increments
> Difficulty=443419 (Good luck!)
> Remote operating system guess: Linux 2.1.122 - 2.2.14
>
> I'm curious about the difficulty rating. What exactly is that? Should
> I use that as a basis to be somewhat more confident about my security,
> or is that something else?
>
> I'm also mucking around with /etc/hosts.deny. Ideally I'd like to
> block access to all services from all outside hosts, since I'm no longer
> using my box to host my website and really don't need to offer
> access. (I know that services like auth may occasionally be needed,
> but I'll worry about that when it becomes a problem. :) I'd like to
> give VMWare VM's access to my box though. So, I've added the following
> to /etc/hosts.deny:
>
> ALL: ALL EXCEPT 127.0.0.1 172.16.136.2 # win98 VM's IP
>
> I'd like to use 172.16.136.* as the network address for any VM's that
> I add; I may set up the Hurd in a VM sometime soon, and would like to
> network it. Is it somehow possible to use a wildcard instead of the 2?
>
> And, despite this line, I still receive portsentry attackalerts, even
> after SIGHUP'ing inetd. So, am I smoking something here? :) I thought
> that ALL was a wildcard, and that I could use it to block all
> services. But is this wrong?
> --------------------------------------------------------------------------
-
> Send administrative requests to [EMAIL PROTECTED]
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
