Murph wrote: > not sure how you figure that running a port scanner is more likely to > get you fired than manually testing the same thing one port at a time. >
You have a point. In this case trying two ports won't cause problems. But running nmap against your own IP might wake up some intrusion detection stuff and get you into trouble Blocking outgoing ports is completely useless anyway IMHO (I make an exception for 25). Bad stuff could be running on any port and most of the bad stuff on the 'net is behin d port 80 which is passed on anyway. The magic word port scanner has a much higher probability of getting you into trouble than a few simple telnet commands. > Not likely either will get you fired, I would hope. It's totally > passive. The more 'intense' scanners also look for any software or > possible exploits on any open port that could be used for unfriendly > purposes. It's a little harder to explain to your IT Security folk why > your running something like this on your network. > I wouldn't count on it. Installing any port scanner on you work system would be not be looked upon favourably in most companies and in most professions. > Also, If you port scan from the outside and you can get in on a port, > you can be almost 100% sure you will also get out on it. However, when > you scan from the inside, you might find a way out but depending how the > packets get wrapped up, your application might still need a swinging > door back in and sometimes a firewall blocks incoming only. If it gets > treated as a return packet from an internal request, it won't matter > much and it will be allowed back in. Some server apps on the outside > though need to be able to establish a session from thier end. IN this > case, your firewall has to let 'strange' packets in on that port. > In modern office environments no tcp ports are open to incoming traffic on the office LAN. If outgoing traffic is allowed the returning packets are allowed too (established connections). Otherwise you can't even set up a tcp connection, the setup handshake requires two way traffic. > > Sorry, I got wrapped up in the argument but that doesn't help you at > all. Sounds like you are ready to roll anyways. > > Some places even frown against streaming audio as it chews up bandwidth > when half the staff are listening to news or music all day. Many places > have a policy but few actually enforce it when it comes down to it. > However, you know much better than we do what your particular comany > will let you get away with. > > To answer your question, although you don't need it anymore, I usually > recommend "Advanced Port Scanner" to network newbs who just want to > find a free port to make something work. It's not near as advanced as > it says but it's easy to use and describes some of the more common port > uses which helps you to understand what else is going on on a given > port. > > For instance, someone mentioned just map your server to use port 80 > because it's used for web and it's always open. However, your PC is > already being slowed down when you browse the web but do you also want > your SW server and client to have to deal with all your web traffic > directly pumped into it too? > Huh? What are you saying here? Regards, Peter _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
