Is my box under attack?
-
I am not able to browse to the Web UI and doing an SSH and running option 10 for filter log I get an ongoing list like this (what is that?):
837564 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1945: [|tcp]
245299 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.47.8945: [|tcp]
526464 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.40.2848: [|tcp]
264062 rule 67/0(match): block in on vr1: 77.45.47.100.1566 > 69.90.78.51.445: [|tcp]
039828 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4050: [|tcp]
575435 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8754: [|tcp]
058998 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8334: [|tcp]
050791 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8365: [|tcp]
445554 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.56.4318: [|tcp]
474822 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4433: [|tcp]
320764 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1945: [|tcp]
770380 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.40.2848: [|tcp]
208833 rule 67/0(match): block in on vr1: 77.45.47.100.1566 > 69.90.78.51.445: [|tcp]
053612 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4050: [|tcp]
288301 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8754: [|tcp]
048797 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8365: [|tcp]
325424 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.8334: [|tcp]
303677 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.3075: [|tcp]
047703 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.52.1516: [|tcp]
143923 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.56.4318: [|tcp]
010042 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.2958: tcp 8 [bad hdr length 12 - too short, < 20]
164676 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.7298: [|tcp]
299079 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4433: [|tcp]
1. 566615 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.9967: [|tcp]
039454 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.2192: [|tcp]
336019 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1837: [|tcp]
266683 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.6661: [|tcp]
692474 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.7298: [|tcp]
1. 245589 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.9967: [|tcp]
030862 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.2192: [|tcp]
268598 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1837: [|tcp]
1. 136974 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.10681: [|tcp]
689209 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1053: [|tcp]
075564 rule 67/0(match): block in on vr1: 87.120.253.49.1716 > 69.90.78.55.445: [|tcp]
1. 216628 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4409: [|tcp]
225510 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4211: [|tcp]
505316 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.37.9063: [|tcp]
294532 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.10681: [|tcp]
683705 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.1053: [|tcp]
020823 rule 67/0(match): block in on vr1: 87.120.253.49.1716 > 69.90.78.55.445: [|tcp]
206808 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.10351: [|tcp]
1. 318308 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4409: [|tcp]
223214 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.4211: [|tcp]
235061 rule 67/0(match): block in on vr1: 2.94.88.87.1980 > 69.90.78.33.445: [|tcp]
724958 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.10443: [|tcp]
069480 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 69.90.78.50.6442: [|tcp]
416155 rule 67/0(match): block in on vr1: 194.28.157.50.80 > 90.90.90.90.10351: [|tcp]Thanks
-
just little bit this host is hot dshield block list ::)
http://www.dshield.org/ipinfo.html?ip=194.28.157.50
-
Thanks. Good to know.
Can you or someone please explain what is happening really? Is he (for some reason I feel all bad hackers are guys :-) doing a port scan? and what really happens after when they see an open port? try to brute force the password?
Is there anything built into pfSense to actively block such attempts after 3 attempts on bad ports or 3 bad password attempts for example? This would be something compared to Fail2ban. Basically an adaptive ban program.
P.S. I am guessing there is something that makes pfSense attractive to such attacks. Maybe it's really not dropping packets as they hit firewall or identifies itself as pfSense when scanned. Otherwise, I don't see why someone would try a 65000+ port search on a pfSense router unless they know a vulnerability.
Thanks
-
Can you or someone please explain what is happening really? Is he (for some reason I feel all bad hackers are guys :-) doing a port scan? and what really happens after when they see an open port? try to brute force the password?
Chances are that this is a port scan. The fact that its sourced from TCP 80 is likely an attempt to bypass badly configured IDS. Depending on what open ports are found, the next steps are myriad. If an open SSH port is found, then yes, brute forcing is an option. If its an open webserver, a more sophisiticated scan of web vulnerabilities may happen. Its hard to know the motivation of a particularly loud scan like this one.
Is there anything built into pfSense to actively block such attempts after 3 attempts on bad ports or 3 bad password attempts for example? This would be something compared to Fail2ban. Basically an adaptive ban program.
Not by default. You can limit the number of firewall states or connection attempts a host can make using some of the advanced options in your firewall rules. Something like Fail2Ban would have to be a package someone writes and so far there hasn't been enough interest to get someone motivated to write one.
P.S. I am guessing there is something that makes pfSense attractive to such attacks. Maybe it's really not dropping packets as they hit firewall or identifies itself as pfSense when scanned. Otherwise, I don't see why someone would try a 65000+ port search on a pfSense router unless they know a vulnerability.
Who says the attacker knows you're running pfSense? This appears to be a non-targeted scan and an exceptionally loud one. Figuring out that someone is running pfSense specifically instead of stock FreeBSD is not especially easy and there are no currently known remote exploits for pfSense. Unless you've done something grotesquely stupid like leaving SSH or the webGUI port open to the world and used a stupid password, pfSense isn't the chink in your armor.
-
If your still unable to get in…
Just for kicks, console in and use option 11...