similar to: follow-up on ISA intrusion detection

Good point Stijn, I am sorry to post without subject and such it must be the early morning. The relevant entries in my rules file: ACCEPT net fw tcp 25 ACCEPT net fw tcp 80 ACCEPT net fw tcp 22 ACCEPT net fw tcp 21 ACCEPT net fw udp 21 REJECT loc

Hi, I am trying to redirect my subnet thru squid and it seems to be working. However I decided tu exclude two hosts from the redirect (ie acces the net directly) and can''t manage to achieve that. I am using the following rule: REDIRECT loc:!192.168.13.48,!192.168.13.200 3128 tcp 80 - With this rule everything gets redirected thru squid. I also tried:

I have some hosts in a DMZ zone with proxyarp. In my local zone I have a host to which I DNAT. I have discovered that I can reach the host in the local zone by attempting to connect to the fw (As expected) or ANY proxyarped host in my dmz zone (as not expected). Is this normal ? (I''ve just discovered that actually the dnated host answers to requests sent to any IP routed to my host!)

Hi, I have shorewall 2.0.8 installed on a linux box. Recently I moved to a setup with a front/back firewall With shorewall acting as a front firewall and M$ ISA Server 2004 acting as a back firewall. I turned all ''intrusion alerts'' On at the ISA server expecting not to get any since shorewall should block everything. Now to the problem: I am getting quite a few alerts

Ok this is admittedly OT, but when you want network advice you go to where network gurus hang... When popping mail from my primary mail server (Linux) from my linux laptop a simple mail check takes 15 seconds to connect when using a wireless nic (802.11g) and 1 second using the hardwired nic. Popping my backup mailserver (also linux) which is sitting RIGHT BESIDE the primary takes one second

D'Arcy Cain <darcy at VybeNetworks.com> writes: > I have a script that checks for things like this and adds them to my > packet filter (pf). Everything seems to work up to a point. The IP > address gets added to my AUTOBLOCK table. The second rule, right after > the friends whitelist, blocks any IP in that table. If I try to ping or > traceroute to it I can't get

D'Arcy Cain <darcy at VybeNetworks.com> writes: > Here is the first four lines from "pfctl -sr": > > pass in quick on bge0 from <FRIENDS> to any flags S/SA keep state > block drop in log quick on bge0 from <ENEMIES> to any > block drop in log quick on bge0 from <AUTOBLOCK> to any > block drop out log quick on bge0 from any to

On 2/04/2020 5:28 AM, Mark Boyce wrote: > On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com > <mailto:gdt at lexort.com>> wrote: >> >> I think you need to use tcpdump and turn up firewall debugging. > > sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) > > Mark Or the stateful entry still exists when the table entry is updated.

On 2020-04-01 16:28, Mark Boyce wrote: > On 1 Apr 2020, at 22:14, Greg Troxel <gdt at lexort.com > <mailto:gdt at lexort.com>> wrote: >> >> I think you need to use tcpdump and turn up firewall debugging. > > sngrep is your friend …My bet is UDP vs TCP on firewall rules :-) block drop in log quick on bge0 from <AUTOBLOCK> to any block drop out log quick

On 2020-04-02 08:01, Larry Moore wrote: > I suspect you have a good understanding of pf. Pretty good I think. As with everything I am always willing to learn more. > Have you included in your script running 'pfctl -k <ip_address>' to kill > any states that may exists after you update your <AUTOBLOCK> table? I haven't yet because I want to watch the effect of

Can anyone recommend an opensource package (preferably something centos 4X compatible) that can be used on a (iptables) firewall to block virus/trojan, etc? And maybe something for intrusion detection? Thanks! Dnk

On 2020-04-22 18:45, Sami Ketola wrote: > Actually by far the biggest source of stolen credentials is > viruses/trojans harvesting them. i tryed blacklist all ips that got passwords errors, but that ends in big shorewall blrules so i turn it over to just add whitelist into blrules where ips is known custommers that dont abuse server, that way my shorewall got alot smaller config files

<!doctype html> <html> <head> <meta charset="UTF-8"> </head> <body> <div> <br> </div> <blockquote type="cite"> <div> On 22/04/2020 19:56 Benny Pedersen < <a href="mailto:me@junc.eu">me@junc.eu</a>> wrote: </div> <div> <br>

On 2020-04-22 5:29 a.m., Johannes Rohr wrote: > Dear all, > > what are the key strategies for intrusion prevention and detection with > dovecot, apart from installing fail2ban? > It is a pity that the IMAP protocol does not support 2 factor > authentication, which seems to stop 90% of intrusion attempts in their > tracks. Without it, if someone has obtained your password and

JohnG <mcsjgs@cox.net> wrote: > I run OS X 10.3.7 on a PowerMac MDD G4 on a cable broadband connection. > I have reason to think my system has been tampered with. Security > features in Mac OS X have been left unlocked (Preference Pane - Users) OSX is substantially different from FreeBSD (even without netinfo) despite having some of the same source code. I doubt you'll find

I'm looking for some beta testers to provide feedback on an Asterisk intrusion detection & prevention program we're releasing soon. As a quick overview, the program provides: - banning based on geographic location of source IP (Continent, country, region, city, etc) - detection and banning based on channels in use by a user - detection and banning based on rate of dialing - detection

On 2020-04-01 15:12, Greg Troxel wrote: > D'Arcy Cain <darcy at VybeNetworks.com> writes: > But yet, new packets from that IP address reach asterisk. It seems > almost entirely clear to me that you have a firewall problem, not an > asterisk problem. This could well be but Asterisk is the only thing that continues to communicate. > I would test this out with a remote

Earlier in the day today Red Hat made an announcement [1] that there had been an intrusion into some of their computer systems last week. In the same announcement they mention that some of the packages for OpenSSH on RHEL-4 ( i386 and x86_64 ) as well as RHEL-5 ( x86_64 ) were signed by the intruder. In their announcement they also clarified that they were confident that none of these, potentially

Earlier in the day today Red Hat made an announcement [1] that there had been an intrusion into some of their computer systems last week. In the same announcement they mention that some of the packages for OpenSSH on RHEL-4 ( i386 and x86_64 ) as well as RHEL-5 ( x86_64 ) were signed by the intruder. In their announcement they also clarified that they were confident that none of these, potentially

> On 22. Apr 2020, at 19.14, Michael Peddemors <michael at linuxmagic.com> wrote: > The three most common attack vectors, (and attack volumes have never been higher) are: > > * Sniffed unencrypted credentials > (Assume every home wifi router and CPE equipment are compromised ;) > * Re-used passwords where data is exposed from another site's breach > (Users WANT to