NMAP Scanning and PortSentry Evasion
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: NMAP Scanning and PortSentry Evasion

  1. #1
    Senior Member
    Join Date
    Oct 2002
    Posts
    1,130

    NMAP Scanning and PortSentry Evasion

    Intrusion Detection
    NMAP scanning and PortSentry Evasion

    This paper will discuss the methods used to circumvent intrusion detection technology employed by Psionic's PortSentry software. It will look at normal modes of operation where PortSentry binds itself to monitored ports at a userland level, and stealth modes, where it operates with raw sockets at a kernel level. The discussion of advanced stealth scan detection and the implications, pros and cons of auto-blocking portscanning attackers, as well as more advanced IDS systems, are beyond the scope of this paper. A basic undertanding of the OSI model and the TCP/IP suite of protocols, including UDP, is assumed, as well as the ability to effectively read tcdump output and syslog generated messages. Scans have been conducted using nmap 3.50 against Portsentry version is 1.2. Scanning machine is a P166 64 MB RAM, 1GB HD running Slackware 9.1 (kernel version 2.6.7) without X windows, at IP address 10.0.0.15. The victim machine is a P2.4Ghz 512 MB RAM 80 GB HD running Slackware 10.0 (kernel version 2.6.8.1) with X windows, at 10.0.0.10. Neither the attacker nor victim have the iptables (or any other firewall, stateful or not) service running. This paper may contain facutal errors to a minor degree. I welcome any corrections and/or criticisms you may deem relevant.

    Our first scan will be a normal TCP connect() scan against the default range of ports. We will be scanning a machine which is currently unprotected by PortSentry. The TCP connect() scan simply attempts to connect to a number of predetermined ports. If a connection is made, the port is listening. If no connection is made, that port is closed. The connection is then terminated to avoid SYN flooding the machine we are attempting to scan.

    Given the command:nmap -sT 10.0.0.10

    We see the following output:
    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
    Interesting ports on 10.0.0.10:
    (The 1656 ports scanned but not shown below are in state: closed)
    PORT STATE SERVICE
    22/tcp open ssh
    631/tcp open ipp
    6000/tcp open X11
    Nmap run completed -- 1 IP address (1 host up) scanned in 2.909 seconds
    Three ports are open. This is provided only as a refence so we may better understand the operation of PortSentry.
    We will now activate PortSentry in its most basic mode, TCP detection only and no stealth capabilities yet. We will also turn off the auto-blocking feature. After activating PortSentry on the victim machine and running the same scan, we arrive at the following output:

    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 17:54 EDT
    Interesting ports on 10.0.0.10:
    (The 1634 ports scanned but not shown below are in state: closed)
    PORT STATE SERVICE
    1/tcp open tcpmux
    11/tcp open systat
    15/tcp open netstat
    22/tcp open ssh
    79/tcp open finger
    111/tcp open rpcbind
    119/tcp open nntp
    143/tcp open imap
    540/tcp open uucp
    631/tcp open ipp
    635/tcp open unknown
    1080/tcp open socks
    1524/tcp open ingreslock
    2000/tcp open callbook
    6000/tcp open X11
    6667/tcp open irc
    12345/tcp open NetBus
    12346/tcp open NetBus
    27665/tcp open Trinoo_Master
    31337/tcp open Elite
    32771/tcp open sometimes-rpc5
    32772/tcp open sometimes-rpc7
    32773/tcp open sometimes-rpc9
    32774/tcp open sometimes-rpc11
    54320/tcp open bo2k

    Nmap run completed -- 1 IP address (1 host up) scanned in 2.960 seconds
    Well isn't that strange? There are actually more open ports with our shiny new PortSentry IDS running than there are without it. This is because portsentry binds itself to every port which it monitors instead of running raw sockets, which do not need to be bound to a specific port. When PortSentry starts, it informs the TCP/IP stack on the host machine that is wants to listen on the list of ports it has been given. Now when a connection request arrives on that port, the stack will complete the request and forward the data for PortSentry. This method, as opposed to using raw sockets, has two major drawbacks:
    PortSentry gives an attacker that there is a plethora of open ports available for exploitation on the victim machine. While this is not true, it will certainly pique interests and make the machine a more tempting target. The attacker may also realize that this machine is being guarded by PortSentry by noticing which ports are open; this is far more than most machines on the Internet today. This will tell the attacker which ports are tripwired. By using more advanced scanning techniques which could circumvent the PortSentry IDS, the attacker could determine exactly which ports to avoid scanning with 'louder' techniques, choosing instead to probe ports which he/she knows PortSentry is not guarding.
    If other services are already bound to these ports, PortSentry is unable to monitor them. This can be seen in the following excerpt from my /var/log/messages file:


    Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 15
    Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 22
    Oct 8 00:14:22 picard portsentry[4094]: adminalert: ERROR: could not bind TCP socket: 22. Attempting to continue
    Oct 8 00:14:22 picard portsentry[4094]: adminalert: Going into listen mode on TCP port: 79
    As you can see, PortSentry is unable to monitor port 22 because the ssh service is already listening on that port. A machine with a large number of available services could render PortSentry useless. Also, If we cannot detect port scans against open ports, we are missing the whole point of having an IDS in the first place. PortSentry is therefore much more valuable on a machine with no services running such as a border router or a firewall, and not on a webserver or mailserver.

    However, all is not lost. On a machine running PortSentry, I am unaware of any known scanning method which could be used to differentiate between the zombie ports opened by PortSentry and real ports opened by a legitamite service -- at least not without triggering an alert. This will at least slow down most attacks, since PortSentry can be set with a hair trigger which will log an alert when someone attempts to connect to any port on its watch list, even once. This is another excerpt from my /var/log/messages file showing the log entries during the time of the scan:

    Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 40421
    Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 49724
    Oct 8 00:47:28 picard portsentry[4240]: adminalert: Going into listen mode on TCP port: 54320
    Oct 8 00:47:28 picard portsentry[4240]: adminalert: PortSentry is now active and listening.
    Oct 8 00:47:29 picard sshd[4241]: Did not receive identification string from 10.0.0.15
    Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 49724
    Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 79
    Oct 8 00:47:30 picard portsentry[4240]: attackalert: Host: 10.0.0.15 is already blocked. Ignoring

    Oct 8 00:47:30 picard portsentry[4240]: attackalert: Connect from host: 10.0.0.15/10.0.0.15 to TCP port: 143
    As you can see, PortSentry reacts rather quickly to this portscan. Only two ports have been probed before PortSentry logs it as an attack. As we discussed previously, when PortSentry establishes a connection with a remote host, it immediately tears it down. Most legitamite services will wait for some kind of input from you before doing so. In this manner, an attacker could telnet to ports reported open by his/her scanner and see if they have services running behind them. In this case, PortSentry recognizes even one attempt to connect to a tripwired port as an attack and reacts accordingly. By the second attempt, PortSentry logs a notice saying action has already been taken and it is now ignoring this activity. This kind of aggressive reporting may generate a lot of false positives, but it will also keep a lot of attackers away from you.
    We will now attempt a SYN stealth scan against the victim computer. A SYN stealth scan sends an initial SYN packet to the victim machine, but does not respond to the SYN,ACK packet, instead sending a REST packet, terminating the connection attempt. This can be seen in the following tcpdump output on the victim machine:

    01:12:49.885153 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: S 3369530623:3369530623(0) win 2048
    01:12:49.885179 IP picard.sympatico.ca.ssh > 10.0.0.15.55064: S 3492815075:3492815075(0) ack 3369530624 win 5840 <mss 1460>
    01:12:49.885405 IP 10.0.0.15.55064 > picard.sympatico.ca.ssh: R 3369530624:3369530624(0) win 0
    We can see the SYN packet from the attacker, and send the usual SYN,ACK packet back. However, the attacker then sends a REST packet, and never completes the connection. Since PortSentry is currently monitoring for connections on its watch list, it ignores these attempts since no connection is actually made. The attacker, however, receives a SYN,ACK packet, showing him/her that there is a service responding on this port. While the presence of PortSentry, as previously deterrmined, will give the appearance of services where none exist, PortSentry will not detect this scan. Based on the specific set of responses received, a set that is unique to the default installation of PortSentry, this will alert the attacker to the presence of our IDS on this machine without revealing him/herself. The command nmap -sS 10.0.0.10, issued from the attacking machine, will generate the same results as nmap -sT 10.0.0.10, but will remain undetected.
    An attacker could also choose to use UDP scans agains a victim machine. With PortSentry currently monitoring only for TCP activity, this type of scan will pass through undetected. Several vulnerable services operate on UDP, such as snmp, tftp, NFS, and others. Because UDP communication is connectionless, no reply can be solicited from the victim. Another technique must be employed. Null UDP packets (0 byte packets) are sent to the victim machine. A host receiving a UDP packet destined for a closed port should issue an ICMP port unreachable message, as seen in the following tcpdump output:

    02:47:31.374353 IP 10.0.0.15.47613 > picard.sympatico.ca.ariel3: UDP, length: 0
    02:47:31.374414 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port ariel3 unreachable
    02:47:32.176119 IP 10.0.0.15.47613 > picard.sympatico.ca.671: UDP, length: 0
    02:47:32.176180 IP picard.sympatico.ca > 10.0.0.15: icmp 36: picard.sympatico.ca udp port 671 unreachable
    If no response is received, the port is assumed to be open. Unfortunately, without stealth mode activated, PortSentry binds to the ports it is monitoring and they appear open when scanned. The pros and cons of UDP scans against PortSentry protected hosts are remarkably similar, therfore, to those of TCP connect() scans. Quite often, ICMP port unreachable messages are blocked from leaving a local network. UDP scans can also become excruciatingly slow, due to a suggestion in RFC 1812 (4.3.2.8) which limits the rate of ICMP error message generation, upon which these scans rely. For this reason, and the lack of documentation in RFC 768, UDP scans can be quite slow and inaccurate, and are not generally used by attackers. However, once a host has been compromised, it can be used to launch effective UDP scans from within a local network, since no error messages ever leave and latency is quite low. PortSentry will therefore be more effective when UDP scan detection is used as a means to detect compromised hosts or with internal attacks. At the network perimiter, although PortSentry does a fine job of detecting UDP scans (when told to with the command portsentry -udp), implement a firewall rule preventing ICMP port unreachable messages from leaving, thereby rendering external UDP scans useless.
    We will now place PortSentry in stealth mode. In this mode, PortSentry operates using raw sockets. This does not require the binding of PortSentry to individual ports to see traffic coming in on them. It does, however, require root (or administrator) privileges, because we are now operating at a kernel level, examining packets before TCP does. The following is the output of the command nmap -sT 10.0.0.10 agains a PortSentry protected machine running in stealth mode:

    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 18:14 EDT
    Interesting ports on 10.0.0.10:
    (The 1656 ports scanned but not shown below are in state: closed)
    PORT STATE SERVICE
    22/tcp open ssh
    631/tcp open ipp
    6000/tcp open X11

    Nmap run completed -- 1 IP address (1 host up) scanned in 4.381 seconds
    Because PortSentry does not complete the connection when the request is made, only ports with actual services running behind them are shown as open (that's because they are open). PortSentry is also able to detect SYN stealth scans in stealth mode, since it is now monitoring for connections requests at a kernel level and not connection establishments at a userland level. A SYN scan will reveal the same information as a connect() scan, and although it is harder to detect, PortSentry does its job here quite admirably, as shown in the following /var/log/messages excerpt:

    Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 32774
    Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 40421
    Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 49724
    Oct 8 03:30:10 picard portsentry[4569]: adminalert: Going into stealth listen mode on TCP port: 54320
    Oct 8 03:30:10 picard portsentry[4569]: adminalert: PortSentry is now active and listening.
    Oct 8 03:30:24 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32772
    Oct 8 03:30:29 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 32774
    Oct 8 03:30:29 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
    Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 143
    Oct 8 03:31:46 picard portsentry[4569]: attackalert: TCP SYN/Normal scan from host: 10.0.0.15/10.0.0.15 to TCP port: 27665
    Oct 8 03:31:46 picard portsentry[4569]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
    PortSentry detects the SYN scan, and differentiates it from a normal connect() scan. This type of scan is more indicative of malicious intent, as a normal service request nearly always completes a connection. This scan does not.
    When placed into UDP stealth mode, PortSentry does much the same thing as above, although it does not add any detection capabilities. In this mode, it is much more difficult for the attacker to realize that PortSentry is running on the victim machine. See the output below:

    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-07 23:44 EDT
    All 15 scanned ports on 10.0.0.10 are: closed

    Nmap run completed -- 1 IP address (1 host up) scanned in 9.989 seconds
    Although PortSentry is listening on a set number of ports, no indication of this is given in the scan output. It does, however, detect and log the scan:


    Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 32774
    Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 31337
    Oct 8 03:44:41 picard portsentry[4662]: adminalert: Going into stealth listen mode on UDP port: 54321
    Oct 8 03:44:41 picard portsentry[4662]: adminalert: PortSentry is now active and listening.
    Oct 8 03:44:43 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 161
    Oct 8 03:44:44 picard portsentry[4662]: attackalert: UDP scan from host: 10.0.0.15/10.0.0.15 to UDP port: 31335
    Oct 8 03:44:44 picard portsentry[4662]: attackalert: Host: 10.0.0.15/10.0.0.15 is already blocked Ignoring
    Here PortSentry picks up the UDP scan on the first packet and reacts accordingly. We have successfully detected the attack from the attacker's machine and given no indication that PortSentry even exists here.

    We will now initiate some more advanced scans. We will start with the ACK scan. In this scan, an arbitrary packet is sent to the victim with the ACK flag set. In all cases, the victim host should respond with a RST packet, unless of course the ACK packet never reaches the host due to a firewall. If we solicit a response with an ACK packet that we cannot achieve with a SYN packet, we know that there is a firewall between us and the host which is dropping SYN packets. If we know the target host exists and neither packet gets through, we are dealing with a stateful firewall. If only the ACK packet gets through, we are dealing with a simpler packet-filtering device. This is the output from a TCP ACK scan against the victim machine:

    Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-10-08 00:01 EDT
    All 1659 scanned ports on 10.0.0.10 are: UNfiltered

    Nmap run completed -- 1 IP address (1 host up) scanned in 8.914 seconds
    And the responsible TCP traffic looks like this:

    04:01:31.871139 IP picard.sympatico.ca.sfs-config > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
    04:01:31.871494 IP 10.0.0.15.62029 > picard.sympatico.ca.nced: . ack 2844304146 win 4096
    04:01:31.871543 IP picard.sympatico.ca.nced > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
    04:01:31.871899 IP 10.0.0.15.62029 > picard.sympatico.ca.9992: . ack 2844304146 win 4096
    04:01:31.871937 IP picard.sympatico.ca.9992 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
    04:01:31.872270 IP 10.0.0.15.62029 > picard.sympatico.ca.pdap: . ack 2844304146 win 3072
    04:01:31.872309 IP picard.sympatico.ca.pdap > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
    04:01:31.872636 IP 10.0.0.15.62029 > picard.sympatico.ca.724: . ack 2844304146 win 2048
    04:01:31.872684 IP picard.sympatico.ca.724 > 10.0.0.15.62029: R 2844304146:2844304146(0) win 0
    This is not surprising, as I do not have a firewall running on this victim machine. We can see here the RST packets being sent in reply to the unexpected ACK packets the victim is receiving. If the victim here had never received these ACK packets, he/she would not be able to send an RST in reply. This would indicate a firewall dropping the packets somewhere along the way.
    Note, however, that PortSentry did not pick up this scan. This scan could be used to determine firewall rulesets against a PortSentry protected firewall bastion host, if one only knows the address of the firewall or any machine behind it. While not revealing any open ports on any hosts, we can determine which packets to send through later to make our scans more effective.
    XMAS, NULL, and FIN scans work by sending illegal flag combinations. According to RFC 793 (page 64),

    "If the state is CLOSED (i.e., TCB does not exist) then

    all data in the incoming segment is discarded. An incoming
    segment containing a RST is discarded. An incoming segment not
    containing a RST causes a RST to be sent in response. The
    acknowledgment and sequence field values are selected to make the
    reset sequence acceptable to the TCP that sent the offending
    segment."

    <snip>

    " If the state is LISTEN then

    first check for an RST

    An incoming RST should be ignored. Return."
    Open ports are required to ignore these packets, while closed ports must respond with an RST packet. With a FIN scan, only the FIN bit is set. With the XMAS scan, the FIN, URG, and PUSH flags are all activated. In a normal communication exchange, no packet will ever have these three flags on simultaneously. Therefore, the host should respond with an RST packet, signalling its intention to immediately terminate this connection, which it believes to be fubared. A NULL scan turns off all flags; either the SYN or the ACK flag is always set during normal communications. The victim then responds with an RST flag.
    The previous three scans (ACK, XMAS, and NULL) were not detected by PortSentry. This is because PortSentry is monitoring for half-finished connection attempts, in which an SYN,ACK was sent in reply to a SYN packet but an RST was received in place of an ACK packet. Since these three scans never send a SYN packet through, no connection is ever half-open and therefore we pass by PortSentry like reality passes by George Bush.
    As a final note, if PortSentry is left in non-stealth mode, we will present an attacker with a multitde of supposedly open ports. We still have not found a way to differentiate between PortSentry zombie ports and ports with actual services running behind them without triggering an alarm.


    References:

    nmap 3.5 manpages Insecure.Com LLC
    RFC 768 - User Datagram Protocol J. Postel
    RFC 793 - Transmission Control Protocol prepared for the Defense Advanced Research Projects Agency
    by the Information Sciences Institute, University of Southern California
    RFC 791 - Internet Protocol prepared for the Defense Advanced Research Projects Agency
    by the Information Sciences Institute, University of Southern California

    This paper is licensed under the GNU Free Documentation License, available at http://www.gnu.org/copyleft/fdl.html
    Government is like fire - a handy servant, but a dangerous master - George Washington
    Government is not reason, it is not eloquence - it is force. - George Washington.

    Join the UnError community!

  2. #2
    Wow... That's all I can say. wow.

  3. #3
    Senior Member
    Join Date
    Nov 2003
    Posts
    247
    This is one of the rare tutorials that I have to download to my PDA or print out, I want to read it that much, but can't have it on my screen because I want to test it out and interact with it as much as possible, no Alt-Tabbing.

    Very fine.
    www.ADigitalPimp.com
    There is a ghost in the machine, and he is my friend.

  4. #4
    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>nmap
    -sT 10.0.0.10

    Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-26 12:40
    Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

    Nmap finished: 1 IP address (0 hosts up) scanned in 4.375 seconds

    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>
    hmm i am kinda new to nmap but could any one tell me whar does this mean??

  5. #5

    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>nmap
    -P0 10.0.0.10

    Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-26 12:47

    Interesting ports on 10.0.0.10:
    (The 1662 ports scanned but not shown below are in state: filtered)
    PORT STATE SERVICE
    21/tcp open ftp

    Nmap finished: 1 IP address (1 host up) scanned in 27.094 seconds

    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>
    well one port open it seems!

  6. #6
    Banned
    Join Date
    Apr 2004
    Posts
    843
    I've already said it once or twice to another member about ummm... yesterday actually. Stop makeing multiple posts for your lame-ass comments. Either delete 'em or edit and copy/paste them together. This is also an old thread anyways.

    ;Edited

    Oh, and don't send me personal messages. I've heard it all before, man. If you suddenly have a problem with how things went down then report me in and explain why I should be banned. Everyone else has...

  7. #7
    well i seem to get the hang of it now
    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>nmap
    -O 10.0.0.10

    Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-26 12:56 India St
    andard Time
    Note: Host seems down. If it is really up, but blocking our ping probes, try -P0

    Nmap finished: 1 IP address (0 hosts up) scanned in 4.687 seconds

    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>nmap
    -P0 -O 10.0.0.10

    Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-26 12:56
    Warning: OS detection will be MUCH less reliable because we did not find at lea
    st 1 open and 1 closed TCP port
    Insufficient responses for TCP sequencing (1), OS detection may be less accurate

    Interesting ports on 10.0.0.10:
    (The 1662 ports scanned but not shown below are in state: filtered)
    PORT STATE SERVICE
    21/tcp open ftp
    Device type: general purpose|firewall
    Running: Microsoft Windows NT/2K/XP, Symantec Windows NT/2K/XP
    OS details: Microsoft Windows XP Pro RC1+ through final release, Microsoft Windo
    ws XP Pro SP1, Microsoft Windows XP SP1, Symantec Enterprise Firewall 7.0 runnin
    g on Windows 2000 SP2

    Nmap finished: 1 IP address (1 host up) scanned in 28.531 seconds

    C:\Documents and Settings\xxx\Desktop\nmap-3.81-win32\nmap-3.81>

  8. #8
    Senior Member IKnowNot's Avatar
    Join Date
    Jan 2003
    Posts
    792
    Damn, even though Striek hasnít been around for a while ( before last Christmas as I can tell ), I am glad that the Newbie brought this tut, because I missed it.

    First: to white_pawn: You performed a scan on a class A network.
    1) 1 host up means it is active, 0 hosts up means it was either not there or stealthed.
    2)Where are you going with this?

    I am concerned. I see that a lot of work went into this, but questions arose.

    Although old, a Google search revealed the following article PortSentry and Snort Compared

    Not saying another evaluation wasnít due, but an explanation may be helpful. Did you do it for a class or school project?

    In any case, when reading this, questions came to mind.
    Why choose PortSentry ?
    How does PortSentry handle IPV6?
    What would happen if the scanned machine only used IPV6 ( thatís coming ) ?
    How does it react with a stateful, or any firewall in place ?
    " And maddest of all, to see life as it is and not as it should be" --Miguel Cervantes

  9. #9
    Junior Member
    Join Date
    Jun 2003
    Posts
    2
    Simply Great .... u should be an author ... seriouly give it a try ...
    sattaru

  10. #10
    In And Above Man Black Cluster's Avatar
    Join Date
    Feb 2005
    Posts
    912
    sattaru,

    First off, welcome to AO ...
    Secondly, please DO NOT pop up an old thread, UNLESS you have something to add or ask the author about ....

    I would suggest to visit AO FAQ .

    Just thought to let you know.. before it is too late ....

    cheers
    \"The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts\".....Spaf
    Everytime I learn a new thing, I discover how ignorant I am.- ... Black Cluster

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides