> 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

You can certainly tweak which ports it is bound to and the interface. 
Otherwise I'm not really sure what sort of information you are getting
that is unusual.  The only thing I can think of is you don't have a
default deny ruleset.

>> > 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

Again point to an open firewall, otherwise it wouldn't get to portsentry.

>  >  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?

If the machine is connected to the internet it is usually a good idea to
send all syslog information to another server either via /etc/syslog.conf
or msyslog (encypted transport, database, etc.)  Since the reason you want
the logs is to find 'unusual activity'  it shouldn't be on the machine
that may be experiencing this activity.

>  portsentry - nope (see above)
> would you recommend running portsentry on an internal host behind the
> gateway machine?

Sure - good way to check for leaks.

> thanks
> redmond
>  snort - i 'spose (no harm per say)
>> tripwire - definately
>> >  any thoughts?
>> >
>> >  thanks again
>> >
>> > redmond

Scott A. Moberly

UNIX IS user friendly, it's just very choosy about who it calls a friend!

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to