hi i've used portsentry on standalone workstations before with ipfilter setup as a +firewall, and for some reason, now when i'm trying to use it on a ipf/ipnat +gateway box, it's being really verbose about the ports it's binding to. if i +nmap a standalone workstation i have configured ipfilter/portsentry on, i don't +get the huge list of ports that it's binding to... i thought perhaps there was +a config option to hide this information
> > > hi all > > > > i have an ipf/ipnat gateway machine protecting an internal network of - > > so far one, hopefully 2 or more - computers. the first thing i did > > after i observed that i have my setup successfully nat'ing, was to try > > to portscan myself from an outside machine, using nmap. at first i > > thought something was up, and that my ipf.rules were being ignored, > > because when i ran > > > > nmap -sS -v -O > > > > on my the public ip of my internal host - which was aliased to the > > external nic of my gateway box - it showed that a huge amount of tcp > > and udp ports were open. i could copy the nmap results, but they're > > long, and suffice it to say ports i thought were closed or inactive > > were shown as open. > > > > after discussing it with the -security listserv, and running a > > 'sockstat' on the gateway box, it turns out that portsentry was indeed > > listening on the great majority of ports that the nmap showed to be > > open. when i turn portsentry off and run nmap again on my setup, it > > only shows ports that i specially allow open in my ipf/ipnat rules like > > 80,22, etc. > > > > my question is: first if anyone knows how to get portsentry to not > > broadcast the fact that it's listening on a wide variety ports when the > > host is being portscanned. i checked the portsentry.conf file, there > > didn't seem to be an option for this. also - i have > > This is exactly what portsentry is designed to do. Can't tell if a port > is hit without first binding to it. I have placed portsentry on other > machines than the firewall for just this sort of information. A better > solution on a firewall is to turn on logging for specific ports or rules > that you are interested in. > > > block return-rst in log quick on xl0 proto tcp from any to any > > > > in my ipf.rules, so i thought that any ports not be nat'd would show up > > in portscans as not listening. not sure why this isn't working. > > What ports exactly are still listening that aren't getting allowed through? > > when i turn portsentry off and nmap again, all appears as i expected it to - only 80 22 and 21 are listed as open - as i defined it in my ipf.rules > also, i had wanted to run logcheck, portsentry, and snort or tripwire > > on my ipf/ipnat gateway box. is this a good combination of apps? as of > > now, i have portsentry turned off, but would like to use it or an app > > that performs the same function. > > logcheck - not really syslog should be sent inside either via syslog or > msyslog (in ports) > logcheck is not a good idea? could you elaborate on this point please? portsentry - nope (see above) > would you recommend running portsentry on an internal host behind the gateway machine? thanks redmond snort - i 'spose (no harm per say) > tripwire - definately > > > any thoughts? > > > > thanks again > > > > redmond > > Hope this helps. > > -- > Scott A. Moberly > [EMAIL PROTECTED] > > "BASIC is the Computer Science equivalent of `Scientific Creationism'." > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message >
msg18969/pgp00000.pgp
Description: PGP signature
