Re: portsentry
Hi,
On Wed, 2003-01-29 at 19:03, Phillip Smith wrote:
> Quick question...
>
> What's the best way to start portsentry on reboot?
>
> Many thanks,
>
You can write a simple start-up script that does that for you. Here's
what I have in /usr/local/etc/rc.d:
#!/bin/sh
PORTSENTRY="/usr/local/bin/portsentry"
case "$1" in
start)
${PORTSENTRY} -tcp && echo " PortSentry starting in TCP
mode..."
${PORTSENTRY} -udp && echo " PortSentry starting in UDP
mode..."
;;
stop)
killall `basename ${PORTSENTRY}`
;;
*)
echo ""
echo "Usage: `basename $0` { start | stop }"
echo ""
;;
esac
As far as I know, portsentry doesn't come with one, so you can just
write a nice short script like the one above, if you like. Make sure
though, to make it executable before rebooting.
Hope this helps.
Regards,
Stacey
> phillip.
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-questions" in the body of the message
--
Stacey Roberts
B.Sc (HONS) Computer Science
Web: www.vickiandstacey.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
Re: portsentry
Hi Phillip. On Wed, Jan 29, 2003 at 02:03:03PM -0500, Phillip Smith wrote: > > What's the best way to start portsentry on reboot? There doesn't seem to be one build by the port, so I wrote a /usr/local/etc/rc.d/portsentry.sh that looks someting like this: #!/bin/sh case "$1" in start) [ -x /usr/local/bin/portsentry ] && /usr/local/bin/portsentry -tcp echo -n " portsentry" ;; stop) killall portsentry ;; esac I've seen others punt and simply add "/usr/local/bin/portsentry -tcp" to their /etc/rc.local. It's not as SysV-compliant, but it works. -- Paul Chvostek <[EMAIL PROTECTED]> Operations / Abuse / Whatever it.canada, hosting and development http://www.it.ca/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: portsentry
Wednesday, January 29, 2003, 2:03:03 PM, you wrote: PS> Quick question... PS> What's the best way to start portsentry on reboot? PS> Many thanks, PS> phillip. I use a script in /usr/local/etc/rc.d -- Benmailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: portsentry - flushing hosts.deny
On Mon, Sep 29, 2003 at 08:10:22AM -0800, Noah wrote: > > FreeBSD 4.8 - stable > > > can somebody tell me how to get portsentry to flush the hosts.deny file? or > do I just need to remove the contents manually and restart portsentry? You don't need to do that for two reasons: i) tcp_wrappers re-reads it's configuration file automatically whenever a new connection gets made to a wrapped service: any changes will be picked up instantaneously. ii) Under FreeBSD the default is to compile tcp_wrappers using the optional host_options(5) style. That means that only /etc/hosts.allow is consulted, and each rule in that file contains an extra final field (compared to the hosts_access(5) style) which says whether the rule is an ALLOW or DENY rule. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portsentry in combination with ipfilter
> 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? > 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) portsentry - nope (see above) 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
Re: portsentry in combination with ipfilter
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/pgp0.pgp Description: PGP signature
Re: portsentry in combination with ipfilter
> 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 [EMAIL PROTECTED] 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
Re: portsentry in combination with ipfilter
On Tue, 11 Feb 2003 23:05:09 -0600 Redmond Militante <[EMAIL PROTECTED]> wrote: > 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 Redmond, There is a good article regrading using portsentry @ http://www.sans.org/rr/intrusion/portsentry.php They talk about version 1 on Linux being able to monitor ports using a socket instead of binding to a port, so this should look different to an nmap scan. As to wheather or not FreeBSD supports this feature, I do not know, Anyone out there chime in? >From the SANS article snip- Example One ? Default configuration By default, the portsentry.conf is designed to listen and block attacking hosts using TCP Wrappers. The default configuration is set up to bind with some of the most commonly probed TCP ports and UDP ports on a Unix system. If any attacking host scans or makes an attempt to attach to one of the PortSentry bound ports, PortSentry will instantly drop the attacking host into the hosts.deny file, thus blocking _ALL_ traffic from the attacking IP address. snip- What bothers me about this method of defense is the possibilty of an attacker causing a DOS by spoofing their source scan IP and causing your system to deny traffic from a vaild host like your upstream DNS server. I have not worked with portsentry at all so, this default behavior is probably not the optimum way to use this tool. Scanning is so common on the net that the gain from this seems minimal on a gateway firewall, inside your LAN is another story ;-) As to system integrity checking, I like to use Aide, found in /usr/ports/security/aide but tripwire is probably a more commonly used tool. Using a tight ipf firewall in conjunction with snort on a gateway firewall is a common and well liked setup. Regards, Stephen Hilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
Re: portsentry in combination with ipfilter
hi thanks again. i think i'm going to move portsentry to hosts behind the gateway - makes more sense considering the info you sent, and then look into snort/tripwire on the gateway (i actually have tripwire installed, i just haven't generated a new config db lately, since i've been messing around with my configs so much). redmond > Redmond Militante <[EMAIL PROTECTED]> wrote: > > > 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 > > Redmond, > > There is a good article regrading using portsentry @ > > http://www.sans.org/rr/intrusion/portsentry.php > > They talk about version 1 on Linux being able to monitor ports > using a socket instead of binding to a port, so this should > look different to an nmap scan. As to wheather or not FreeBSD > supports this feature, I do not know, Anyone out there chime in? > > > >From the SANS article > snip- > Example One ? Default configuration > > By default, the portsentry.conf is designed to listen and block > attacking hosts using TCP Wrappers. The default configuration > is set up to bind with some of the most commonly probed TCP ports > and UDP ports on a Unix system. If any attacking host scans or > makes an attempt to attach to one of the PortSentry bound ports, > PortSentry will instantly drop the attacking host into the > hosts.deny file, thus blocking _ALL_ traffic from the attacking > IP address. > snip- > > What bothers me about this method of defense is the possibilty > of an attacker causing a DOS by spoofing their source scan IP > and causing your system to deny traffic from a vaild host like > your upstream DNS server. > > I have not worked with portsentry at all so, this default > behavior is probably not the optimum way to use this tool. > > Scanning is so common on the net that the gain from this > seems minimal on a gateway firewall, inside your LAN is > another story ;-) > > As to system integrity checking, I like to use Aide, > found in /usr/ports/security/aide but tripwire is > probably a more commonly used tool. > > Using a tight ipf firewall in conjunction with snort on > a gateway firewall is a common and well liked setup. > > Regards, > > Stephen Hilton > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-questions" in the body of the message > msg18977/pgp0.pgp Description: PGP signature
Re: portsentry in combination with ipfilter
On Wed, 2003-02-12 at 05:55, Stephen Hilton wrote: > What bothers me about this method of defense is the possibilty > of an attacker causing a DOS by spoofing their source scan IP > and causing your system to deny traffic from a vaild host like > your upstream DNS server. You can add your DNS server to the portsentry.ignore configuration file so that it never get's blocked. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message
