Oh, so we gonna be like that are we. Well, I can nit pick with the best of them... > Actually, the blocking of inbound ports should have no effect on > outbound connections whatsoever. I was talking about "blanket blocking" meaning any packets on those ports are assumed to be bad and then are dropped. If this rule comes before the state rules it WILL have an effect on outbound traffic. > Assuming he has no servers running that he wants the outside world to > access, a good stateful inspection ruleset would look something like > this: Ok, now why would you go and assume he has no servers/services running? His original email said "I was doing some port forwarding last night." Now, why do you think he would be doing port forwarding? Huh? Thought so. > (in psuedo/fw speak) > > pass ip from me to any setup > pass ip from any to me established > drop ip from any to me (explicit deny) That's good? I call it bare minimum. > > .. Note that this would block incoming icmp stuff that was not already > established by the host (ie, outbound pings would work, but incoming > echo requests, redirects, and all other icmp types would be dropped) > > > Kevin Hodle > CCNA, Network+, A+ Hrrmm... People who include their alphabet soup after their names think they need to prove something or are extremely egotistical. A+? Sh*t my grandma got A+. Your kung-fu is weak and your dojo smell of trench ass. > Alexander Open Systems > Network Operations Center > (913)-307-2367 > kevinh@aos5.com > > > -----Original Message----- > From: Jeremy Fowler [mailto:jfowler@westrope.com] > Sent: Friday, April 04, 2003 12:02 PM > To: Matt Luettgen; kclug@kclug.org > Subject: RE: Blame it all on the firewall! > > > Well, it's not an end-all solution. I know that you can configure bo2k > to run on any port you choose and it can use either TCP or UDP. So > limiting those ports only stop the lazy script kiddies. Just blanket > blocking packets that *might* come from a nefarious application might > actually stop valid traffic. Most internet applications choose an > outgoing port at random from the upper range (1024-65536). If by chance > it chooses a blocked port the connection will obviously fail. That's why > Statefull firewalls are so wonderful. However, you have to setup your > rules to make sure that valid Statefull packets are accepted - which > just might be the case in Matt's situation. Also, a good IDS like snort > can dismantle the packets and look for patterns/fingerprints in the data > that match patterns from those apps no matter what port they come in on. > So there is no one solution to network security. It usually requires > multiple solutions - with back-up solutions for those solutions. > > > -----Original Message----- > > From: owner-kclug@marauder.illiana.net > > [mailto:owner-kclug@marauder.illiana.net]On Behalf Of Matt Luettgen > > Sent: Friday, April 04, 2003 9:52 AM > > To: kclug@kclug.org > > Subject: Re: Blame it all on the firewall! > > > > > > I know what they are, I'm wondering why smoothwall doesnt have them > > closed instead of filtered > > > > On Fri, 04 Apr 2003 09:22:32 -0600 > > Jason Clinton wrote: > > > > > Matt Luettgen wrote: > > > > I was doing some port forwarding last night with smoothwall and > > > > when I was done I had someone nmap me from the outside world, > > > > everything looked normal but two ports which concern me because of > > > > > the windows boxes on the network. > > > > > > > > 31337/tcp filtered Elite > > > > 54320/tcp filtered bo2k > > > > > > > > Any ideas of why Smoothwall wouldnt be blocking these? > > > > > > The second one is Back Orifice 2000. Back in my script kiddie days, > > > this handy little tool would allow you to completely control a > > > remote computer. It's quite dated, now. > > > > > > I don't know about the first one. I assume both of these are to > > > block standard trojan traffic. > > > > > > -- > > > Jason Clinton > > > I don't believe in witty sigs. > > > > > > > > > majordomo@kclug.org Enter without the quotes in body of message > > > > > >