> This is whats called a 'work signature'.. You encounter them someday > when some unfortunate company makes the mistake of hiring you into an IT > position. lol > And wtf are you talking about 'blanket blocking'... Do you > usually block outbound connections on certain ports? The only times > that is really nessecary is in a production enviroment (ie, production > servers that should never make outbound connections), or a corporate > network that wants to restrict outbound activity and direct all outbound > traffic through a proxy server. You call it bare minimum, but that is > all he would need if he had no servers, if he had servers he needed open > to the world, afew simple modifications would do just fine. It's always a good idea to limit what goes out your network. > I don't know where this flame came from, but you should know that my > kung-foo and technique are most certainly the greatest. > > Maybe you should try 'blanket blocking' outbound port 25 from now on, > since you seem to be so familiar with firewalling. I got your blocked port right here! > I know openssl master key overflow technique, I know WebDav return > address discovery technique, not to mention tiger claw and lotus. That's funny. Good one. > > See you at the next meeting bitch. Bring it! ;-) > > > Kevin Hodle > CCNA, Network+, A+ > 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 1:21 PM > To: kclug@kclug.org > Subject: RE: Blame it all on the firewall! > > > 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 > > > > > > > > majordomo@kclug.org Enter without the quotes in body of message > > > > > > > > majordomo@kclug.org Enter without the quotes in body of message > > >