ip..firewall

[hotdeath]

How would someone be able to get through a firewall ??
How would you find holes in a firewall I guess would be more specific?

[Guus]

Hmm, I guess your first question should be, what is TCP/IP and how does it work? You'll need to know how computers communicate over the internet before you can understand how to protect them from malicious communication.

There's tons of information about TCP/IP. try this link: http://www.google.com/search?q=tcp%2Fip

[|The|Specialist]

These 'holes' im assumeing you mean ports and you want to know how to find them? Use a port scanner...
Each port is kinda like a service that waits for commands to tell a program or (ect) what to do. In order for someone to get past a FW they'd need to trick the FW into thinking that its getting normal traffic and from a trusted IP.

Someone could also get trojans that can mail you the port/ip then listen on a port and wait for connections and commands and if needed it can sometimes even dissable some of the common FW.

[cbo]

well... when you first set up a firewall, i reconmend you set it up with a deny all filter on both inbound and outbound trafic. Your connection is now completely useless and 100% safe, provided you didn't make any backdoors for yourself in case of emergency. then gradually open the ports you need. This way your firewall will not have any open ports that hackers can exploid.

If you have already set up a firewall and want to check it download a port sniffer and bombard your firewall. Remember to do this from the outside of the net and not from the inside since internal ip's usually have more access than unknown ip... While portscanning expect the performance drop quite a bit.

To answer your questions bypassing a firewall that has a bad setup/standard passwords is quite easy.. if you can enter the configuration you can allow your own ip addresses to access all netword components and bam your in. The trick is to set it up the right way to begin with.

ip firewalls use accesslists, passwords and ports.. accesslists provides some of the best security as the completely deny or allow speciffic ip nets and ports. ports is always a small risk, you need to have some open in order to communicate, ports usually point to a machine or server on the internal network... In order to make ip ports safe you need to secure the final destination and the firewall itself. passwords use good passwords that are not easily broken.

[g00n]

a common method of today's youth is to find a target, scan the target and determine the services runing.. then search the net for an exploit for those services and see if they might be running a version that has a security hole.. the exploit they find will probably open an unpassworded shell that they can connect to on a port they have determined is unprotected (admin didn't close the port because nothing's running there).. then connect to the port they specified and they are in.. from there they can redefine the firewall rules, and take or alter information on the server..

which is why it's very important to keep your web services up to date and close every port regardless of if a service is running there or not.

[Networker]

Hey, hey,
that's an interesting subject!
I wrote a tut about it few weeks ago
http://www.antionline.com/showthread...ht=Firewalking

That aims to highlight some technics to detect what rules are running on a firewall.

more info:
When a firewall is protecting a port (e.g. FTP port ) the firewall will drop any related frames. That's what we are expected from the firewall!

Now, in the case there is no firewall & If you start a scan using TCP with ACK flag your are expecting the target to answer you with a TCP packet with the RST flag (read the TCP rfc for more details!).
The trick is that when a firewall is in the middle, it will simply drop the packet and you'll never get the TCP RST packet back.
That's a simple way to detect what port is protected or not. (Nmap will do it for you, have a look in the manpage!)
Of course some constructors knows about it and implement counter measure:
- A simple one is to answer a TCP RST from the firewall, but you can still detect the firewall action thanx to the IP source (the one of the firewall)
- The ultimate mitigation is when the firewall is able to spoof the target IP for answering the RST packet. (I don't know any commercial product that do it!)

I hope it help,

Extract from the FYODOR man page:
-sA
ACK scan: This advanced method is usually used to map out firewall rulesets. In particular, it can help determine whether a firewall is stateful or just a simple packet filter that blocks incoming SYN packets.
This scan type sends an ACK packet (with random looking acknowledgement/sequence numbers) to the ports specified. If a RST comes back, the ports is classified as "unfiltered". If nothing comes back (or if an ICMP unreachable is returned), the port is classified as "filtered". Note that nmap usu- ally doesn't print "unfiltered" ports, so getting no ports shown in the output is usually a sign that all the probes got through (and returned RSTs). This scan will obviously never show ports in the "open" state.

[g00n]

if you happen to use a linujx system to serve and take the time to configure iptables.. even if there is a perimeter firewall, it's always a good idea to firewall the server itself..

you can use the REJECT action in iptables to respond is such a way that it appears that a service isn't even available.. however, some people refrain from REJECT because it can help a DoS attack, by clogging the outbound bandwidth, adding to the total effect.

[SirDice]

Originally posted here by g00n
if you happen to use a linujx system to serve and take the time to configure iptables.. even if there is a perimeter firewall, it's always a good idea to firewall the server itself..

you can use the REJECT action in iptables to respond is such a way that it appears that a service isn't even available.. however, some people refrain from REJECT because it can help a DoS attack, by clogging the outbound bandwidth, adding to the total effect.

You're better off just DROPping the packet. That way 'they' won't even know there's something there (no reply, nothing). If you REJECT it you will send back an RST packet showing something's there.

Another plus on just dropping the packet would be that portscanners will take forever to complete. Lacking any responses the scanner will timeout and maybe try a few times before moving on to the next port. If you send back a RST the scanner immediately knows the port is closed and will try the next one.

[Networker]

Hum, hum, SirDice
despite the fact you're a folk I enjoy to chat with (I remember april the 1st), I have to say I quite disagree!
maybe my previous post in that thread is invisible somehow or my english is to poor, I'll try to clarify my point of view.

SirDice wrote:
You're better off just DROPping the packet. That way 'they' won't even know there's something there (no reply, nothing). If you REJECT it you will send back an RST packet showing something's there.

Yes exactly and that's the trick. The RST scan is not use for scanning an IP range a simple connect() scan is more efficient!
If you do not REJECT you'll give more info, the attacker will easily detect that a firewall is protecting the target and will be able to determine the firewall ruleset.

SirDice wrote:
Another plus on just dropping the packet would be that portscanners will take forever to complete. Lacking any responses the scanner will timeout and maybe try a few times before moving on to the next port. If you send back a RST the scanner immediately knows the port is closed and will try the next one..

Yes the scan will be slow but what is the point? The black hat doesn't care about time, that's its strengh! He launches a scan, go to sleep... and know everything about the system when awake.

[SirDice]

Originally posted here by Networker
Yes the scan will be slow but what is the point? The black hat doesn't care about time, that's its strengh! He launches a scan, go to sleep... and know everything about the system when awake.

You're right. I must have misread your post and I will be looking at your tut this weekend